We use JRuby quite a bit both for Rails applications and also for general Ruby scripts. I do get asked why one would use JRuby instead of Ruby (meaning C Ruby). This short post is an attempt to list out the main reasons we like to use JRuby. As background, I should mention that we are more a Ruby house and do quite a lot of work in Ruby.
A brief background to JRuby
JRuby is a 100% Java implementation of the Ruby programming language. It is Ruby for the JVM.
JRuby provides a complete set of core “builtin” classes and syntax for the Ruby language, as well as most of the Ruby Standard Libraries. The standard libraries are mostly Ruby’s own complement of .rb files, but a few that depend on C language-based extensions have been reimplemented. Some are still missing, but we hope to implement as many as is feasible.
Since it runs on the JVM, it benefits from tooling and optimisations that are built into the Java Virtual Machine; this can lead to better performance. It also provides us a way for us to call Java classes and libraries from our Ruby programs. But we will talk about this in a bit.
So, why JRuby?
For us, these are our main reasons for using JRuby. Of course, as always, the correct answer in your case will depend on what you want to do with it and where.
It’s just Ruby but runs where Java is available
This is really important. JRuby has excellent compatibility with the Ruby specification and the implementation tries to match the behaviour of CRuby. So, most of the time, if you want to use your program with JRuby, you just need to run it with JRuby. It will most likely work with no change needed. There are some cases where you might need to look for an alternative JRuby gem (e.g. native gems to access the database need to be switched to the Java versions).
In addition, if you’re deploying your scripts or your applications to an environment that has not yet agreed to use Ruby (e.g., perhaps an enterprise on-premise data centre or similar), you can deploy your Ruby programs to conveniently run with Java (using JRuby) providing you an easy way to comply with the needs without losing the flexibility, speed and productivity of using Ruby.
It’s faster for long-running applications
In many cases, you will find that switching to using JRuby instead of Ruby will result in faster execution. This is especially so where the application needs to run for some time (e.g., a few minutes or a daemon that runs forever). In a simple case, we got a 7% speed-up simply by changing the exact code we had to run on JRuby. In another case, using xlsxtream on JRuby was almost as fast as using a Java library from JRuby which is quite impressive since it’s a pure Ruby implementation competing with a Java library (with some constraints). Again, we can fight about whether it’s a fair shootout but the point is just that JRuby performance can be quite good without doing much. In addition, if you choose your Java garbage collector carefully, you can reduce the memory the application seems to take. This method allows us to deploy Rails applications for high-load applications using a server running Java.
A note here that JRuby is slower to start up when compared with CRuby. A lot of effort is going into tuning and reducing this, but it is true today that if your application runs for less than a few seconds, the startup time of JRuby would put it at a great disadvantage.
Packaging and distributing JARs
One of the nice things about using JRuby and Warbler together is the ability to produce a JAR file that includes everything you need into a simple, single file. This includes JRuby, the built-in classes, your code and other directories, gems you need and so on – all in a single file. Then, you can just execute the JAR on your target machine. The whole process is quite simple and makes many applications fully self-contained and easy to distribute, and easy to run where you have JAVA available.
Calling Java from Ruby
One of the great advantages of using JRuby is the ability to connect with Java libraries (JARs) and call Java code from Ruby scripts. In some cases, this allows the use of memory-efficient high-performing code such as Apache POI (the Java API for Microsoft Documents) to generate a simple XLSX file where no suitable Ruby alternative existed (for our use case). JRuby takes care of a lot of the plumbing that is required to make this work from your Ruby scripts running on JRuby and it’s quite easy to use Java native JARs when using JRuby allowing you to leverage existing external code from your Ruby scripts.
Other Technical Reasons
There are other technical reasons that we have not used so much yet – Glimmer DSL for GUIs, debugging using JVM-based tools like VisualVM, Ruboto for Android app development, calling Ruby from Java, and so on. Hopefully, as we use these more, you’ll see more posts here.
Finally, the people
The team behind JRuby comprises people like Charles Oliver Nutter and Thomas Enebo and many others who have worked very hard to create a fantastic community. On GitHub, Twitter and Reddit, it’s easy to find @headius constantly helping people with JRuby and asking for any information that could make JRuby better. Above all, this is a great reason for working with JRuby.
So, that’s it for me. If you have other reasons that attract you to JRuby, feel free to comment below.