Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News JRuby 9000 Released Featuring Ruby 2.2 Compatibility

JRuby 9000 Released Featuring Ruby 2.2 Compatibility

JRuby has released version 9000, the ninth release of the popular implementation of Ruby for the Java Virtual Machine.

Originally released in 2001, this is the first major JRuby release since Oct. 2012 when version 1.7.0 was released. The new version is fully compatible with the Ruby 2.2 specification, making this the first Ruby 2.x compatible release since Ruby 2.0 was first inaugurated in Feb. 2013.

According to the JRuby press release:

JRuby 9000 is the ninth major release of JRuby. We opted to go with 9000 as a code name and as a version number to separate it from Ruby's version numbers (1.8, 1.9, 2.0 etc).

JRuby 9000 represents years of work by dozens of contributors. It is the single largest JRuby release we've ever done.

The new JRuby version requires Java 7 or better. The execution runtime has reportedly been completely rewritten and in addition to Ruby 2.2 compatibility offers improved performance.

Ruby job openings have nearly doubled over the past five years, as measure by job trends. Ruby is particularly attractive to developers because in the words of Ruby creator Yukihiro Matsumoto "Ruby is designed for programmer productivity and fun." Ruby is a pure functional, object oriented programming language, where even primitive structures like numbers and booleans are objects. It is said to follow the "Principle of Least Surprise".

InfoQ spoke to Charles Oliver Nutter co-lead of the JRuby project and senior engineer at Red Hat about the release and about Ruby in general:

InfoQ: JRuby seems to be enjoying some great traction. What's the secret?

Nutter: Patience. We've always believed that as Ruby applications "grow up" they'll hit processing and memory limits running on MRI. When that happens, the answer is almost always to move to JRuby to scale better horizontally and make better use of available hardware.

InfoQ: How do you compete with overlapping languages like JavaScript, Groovy and Clojure?

Nutter: We don't really see it as competing. JavaScript has its place as a language of the front end, and even though Node has made inroads on the server it's a very limited environment. Groovy is like a "dynamic Java" and it fits best as part of a mostly-Java application. Clojure is an excellent data-processing language. But nothing really competes with Rails and the other Ruby web frameworks for ease of use and time to deployment.

InfoQ: Can you talk about plans for JRuby on Rails?

Nutter: JRuby on Rails remains one of our biggest selling points, but with the rise of microservices we're seeing a lot of users push lots of "small" JRuby servers for fast APIs and vertical features. We will continue to support Rails as long as it's the most popular Ruby web framework, and we work with members of the Rails team to make sure JRuby and Rails go well together.

InfoQ: There seems to be a lot going on in the Graal/Truffle area. Can you give us an update on that?

Nutter: We're very excited about the work Oracle labs is doing on Truffle, and we're happy to host and collaborate on the JRuby + Truffle project in our codebase. There's a long road ahead, but the early results are very promising. Once JRuby + Truffle is ready for prime time, you can be sure we'll let the world know.

InfoQ: Would you say JRuby is Ruby on the JVM, or Ruby and more?

Nutter: We always try to emphasize that JRuby is "Just Ruby". We're proud to say that we consider JRuby a Ruby implementation *first* and a JVM language *second*. This doesn't mean we aren't a great JVM language, but we know that Ruby compatibility is the most important of our goals.

InfoQ: Does Ruby author Yukihiro Matsumoto or any of the Ruby MRI team get involved in JRuby?

Nutter: Yes indeed! We are good friends with Matz and Koichi and Nobu and many other core developers from MRI. We exchange optimization strategies, debate new features, and talk about future plans. Our mailing list is even hosted on We value our relationship with the Ruby core team very highly.

InfoQ: Can you talk about some of the new features that would make users want to upgrade?

Nutter: Other than the compatibility bump to 2.2 (the current version of Ruby), we've also made improvements in concurrency, memory efficiency, and native integration -- especially around IO and process management, traditionally difficult areas for JVM languages. And of course our new runtime opens the door to really exciting optimization paths over the coming months.

InfoQ: Who has been your target user and how is that evolving?

Nutter: Our target user has always been the Ruby shops that grow out of MRI. We have never said that JRuby should be the only Ruby implementation, but we realize that eventually applications need what the JVM can provide. That's why we love working on JRuby, and why we've seen adoption increase rapidly over the past few years.

InfoQ: How have the changes in Java 7, in particular invokedynamic & Co, worked out? The initial versions of Java 7 had bugs that prevented JRuby from using it, but what's the experience in Java 8? Have they really brought the expected improvements? 

Nutter: Current versions of Java 7 and Java 8 have resolved all our issues with invokedynamic. The performance gains have been moderate, but as the JVM folks continue to optimize we see steady improvement. As we improve our own compiler optimizations, we'll start to utilize invokedynamic better, along the lines of what the Nashorn folks are doing with type specialization.

InfoQ: Are there still JVM constraints that limit 3rd party languages from being fully ported to the JVM? Eg. lack of value types, native code integration, etc. What other features would help JRuby (lightweight coroutines, etc)?

Nutter: The lack of value types definitely impacts our ability to do fast math operations, which is why we're excited about the new compiler architecture. Native code integration would be nice to have in the JDK, but we already maintain the best external libraries for that (the JNR suite of projects). Coroutines would be fantastic to have; our Fiber implementation is still using fully-native threads, which limits what you can do with Fibers on JRuby. We'd also like to see the escape analysis in Hotspot improved to the point that it is actually useful for us; currently, it doesn't help at all.

InfoQ: What's the reality of 3rd party library support in JRuby, in particular ones using native extensions? Are library creators using more pure Ruby code or are they still using native libraries for speed or system integration?

Nutter: We can tell JRuby has become important to the Ruby community because almost all popular C extensions come with JRuby versions now. We try to work closely with the community to make sure that Ruby users can drop their applications into JRuby without any major modifications, and we're mentoring a Google Summer of Code student working on porting a popular C extension to JRuby this summer.

InfoQ: What's the status of JRuby on systems like Android? How have the improvements of Dalvik & ART impacted the JRuby performance?

Nutter: Sadly, the maintainers of the Ruboto project (JRuby on Android) no longer have time to work on it. We are very interested in looking at RoboVM as a future path to getting JRuby on both Android and iOS, but for the moment it's an open question. Ruboto still works, but there's nobody pushing it forward right now.

InfoQ: What else would you like readers to know or would pique their interests relating to JRuby and this release?

Nutter: This is the first release of JRuby to finally catch up compatibility with MRI. For the first time, we can take a step back from compatibility work and focus on using our new runtime to push Ruby performance closer to Java and C. We'll also be able to keep up with future Ruby versions, so JRuby users can use all the latest features.


Rate this Article