Is There an Advantage to Running Jruby If You Don't Know Any Java

Is there an advantage to running JRuby if you don't know any Java?

I think you pretty much nailed it.

JRuby is just yet another Ruby execution engine, just like MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun and all the others.

The main differences are:

• portability: for example, YARV is only officially supported on x86 32 Bit Linux. It is not supported on OSX or Windows or 64 Bit Linux. Rubinius only works on Unix, not on Windows. JRuby OTOH runs everywhere: desktops, servers, phones, App Engine, you name it. It runs on the Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea and Oracle JRockit JVMs (and probably a couple of others I forgot about) and also on the Dalvik VM. It runs on Windows, Linux, OSX, Solaris, several BSDs, other proprietary and open Unices, OpenVMS and several mainframe OSs, Android and Google App Engine. In fact, on Windows, JRuby passes more RubySpec tests than "Ruby" (meaning MRI or YARV) itself!

• extensibility: Ruby programs running on JRuby can use any arbitrary Java library. Through JRuby-FFI, they can also use any arbitrary C library. And with the new C extension support in JRuby 1.6, they can even use a large subset of MRI and YARV C extensions, like Mongrel for example. (And note that "Java" or "C" library does not actually mean written in those languages, it only means with a Java or C API. They could be written in Scala or Clojure or C++ or Haskell.)

• tooling: whenever someone writes a new tool for YARV or MRI (like e.g. memprof), it turns out that JRuby already had a tool 5 years ago which does the same thing, only better. The Java ecosystem has some of the best tools for "runtime behavior comprehension" (which is a term I just made up, by which I mean much more than just simple profiling, I mean tools for deeply understanding what exactly your program does at runtime, what its performance characteristics are, where the bottlenecks are, where the memory is going, and most importantly why all of that is happening) and visualization available on the market, and pretty much all of those work with JRuby, at least to some extent.

• deployment: assuming that your target system already has a JVM installed, deploying a JRuby app (and I'm not just talking about Rails, I also mean desktop, mobile, other kinds of servers) is literally just copying one JAR (or WAR) and a double-click.

• performance: JRuby has much higher startup overhead. In return you get much higher throughput. In practice, this means that deploying a Rails app to JRuby is a good idea, as is running your integration tests, but for developer unit tests and scripts, MRI, YARV or Rubinius are better choices. Note that many Rails developers simply develop and unit test on MRI and integration test and deploy on JRuby. There's no need to choose a single execution engine for everything.

• concurrency: JRuby runs Ruby threads concurrently. This means two things: if your locking is correct, your program will run faster, and if your locking is incorrect, your program will break. (Unfortunately, neither MRI nor YARV nor Rubinius run threads concurrently, so there's still some broken multithreaded Ruby code out there that doesn't know it's broken, because obviously concurrency bugs can only show up if there's actual concurrency.)

• platforms (this is somewhat related to portability): there are some amazing Java platforms out there, e.g. the Azul JCA with 768 GiBytes of RAM and 864 CPU cores specifically designed for memory-safe, pointer-safe, garbage-collected, object-oriented languages. Android. Google App Engine. All of those run JRuby.

Advantages of Java over Ruby/JRuby

I don't know Ruby very well, but I can guess the following points:

• Java has more documentation (books, blogs, tutorial, etc.); overall documentation quality is very good
• Java has more tools (IDEs, build tools, compilers, etc.)
• Java has better refactoring capabilities (due to the static type system, I guess)
• Java has more widespread adoption than Ruby
• Java has a well-specified memory model
• As far as I know, Java has better support for threading and unicode (JRuby may help here)
• Java's overall performance is quite good as of late (due to hotspot, G1 new garbage collector, etc.)
• Nowadays, Java has very attractive and cheap server hosting: appengine

java performance within jruby

An algorithm written in Java should be faster than the same algorithm written in JRuby, right?.

It depends on how well you write the Java version. It is also theoretically possible that for certain algorithms the JRuby compiler can emit bytecodes that run faster than the Java compiler would emit for a functionally equivalent Java program.

But generally I would expect a hand-optimized Java algorithm to run faster than a hand-optimized JRuby algorithm because of:

• relative maturity of the Java and JRuby bytecode compilers,
• the JIT compiler being tuned to optimize bytecodes typical of Java programs, and
• the JVM bytecode architecture being better suited for Java.

I don't know how significant the difference is though. And obviously it would depend on the skills of the person / people doing the hand optimization.

However, if I write the algorithm in Java and then call it from JRuby, will I still get the performance advantages of java?

Probably yes, but there are some possible reasons why this might not be the case:

• You might need to convert between equivalent Java and Ruby classes / types at the call boundary, and the cost of the conversions may negate the benefits of recoding in Java.
• The real performance bottleneck may not be in this algorithm at all.

Before you embark on this exercise of recoding JRuby code in Java, you should do some tests to see if this is a worthwhile exercise at all; e.g. does the application already run fast enough? Then you should profile the application to see if the application is really spending all of its time in the algorithm. Finally, you should see if you can optimize the algorithm in JRuby. (For instance if you can replace an O(N**2) JRuby algorithm with an O(N) JRuby algorithm, then that's better than recoding the original algorithm in Java.)

Use JRuby for Ruby web applications? Is it worth it?

JRuby is one of the most complete ruby implementations (there are a lot other ones out there such as IronRuby, Maglev, Rubinius, XRuby, YARV, MacRuby). It is very comprehensive, therefore, unless you use gems that use native C code, you will very very likely be just fine compatibility-wise.

JRuby is a bit faster than the actual C implementation, but it supports actual threads, whereas the official implementation is struggling a bit into getting it (it still uses Green Threads). Using Java threads from JRuby is quite trivial, even though it will require you to couple your code with Java (with a little DI, this coupling will only happen once, though).

Another benefit: runtime tools. Java, as a platform, instead of a language, has a lot of runtime tools to help you diagnose problems and check the state of the application (profilers, JConsole, and so on).

Twitter engineers also mentioned that the Ruby VM kinda has trouble being an environment for long lived processes, while the JVM is very good at that, because it’s been optimized for that over the last ten years.

Ruby also had a little security issue recently, which did not affect JRuby's implementation.

On the other hand, your project requires more artifacts (JVM, JRuby jars, etc). If you are using an application that will stay alive for long, and you want better runtime support, JRuby can be a great way to go. Otherwise, you can safely wait until you need these things to actually make the move (it is likely to go smoothly).

Is JRuby ready for production?

Here is a blog post from a company that created a cross-platform, multithreaded, desktop simulation application with JRuby. I think their success indicates JRuby is ready for enterprise production applications.

http://spin.atomicobject.com/2009/01/30/ruby-for-desktop-applications-yes-we-can

Any advantages when running a Rails application on Tomcat+JRuby instead of Mongrel/Passenger?

I'm not a JRuby expert, but I have used it for a couple things recently, and in my opinion the big win with JRuby is the ability to use Java code (including existing Java libraries) in your Ruby code, and the ability for Java to call and/or embed Ruby. (Most of JRuby's documented success stories involve the ability to access Java from Ruby.) Also, it is possible to run JRuby on systems that may be difficult or impossible to get MRI to run on.

There are some differences between MRI and other C-based rubies and JRuby you should be aware of; they are documented on JRuby's wiki.

In my opinion (and others may disagree), if you're already running MRI-ruby based services, etc. and you don't need to access any Java functionality, I would run my Rails app on MRI.

How reliable is JRuby?

I am doing a lot of jruby work right now and can tell you that rails is certainly a viable option under the jruby interpreter. I've been pretty pleased and in my case have to use many native Java libraries, so jRuby is just such an awesome wrapper around that java code. I will say that I have had some technical challenges some that are worked out, some that are not yet.

1. unit testing: spooling up the jvm and then spooling up rails takes much longer, so your tests take longer to run - solution, potentially something like nailgun that keeps the jvm running
2. deployment: i have not gotten warbler to work for me, with my flavor of tomcat. this is a major issue for us.
3. pick your libraries, while some c extensions work, they are not all equally compatible.

if you are interested I would highly reccomend the jruby book, in beta, from Pragmantic Programmers at http://pragprog.com

---

Related Topics