For some users, the fastest Ruby is Java. The JRuby project has long made a name for itself as a way to run Ruby applications on the JVM, and an update to that platform will soon bring the project up to par with the rest of the Ruby ecosystem. But first, the JRuby team has finished release candidate 3 of JRuby 1.6, which adds compatibility with Ruby 1.9, and brings the JRuby party to Windows for the first time.

Previous versions of JRuby did work on Windows-based JVMs, but this release marks the first full cycle in which Windows systems were included in the JRuby continuous integration cycle, ensuring Windows-based problems were recognized early and fixed before release.

Charles Nutter, co-creator of the JRuby project, said that version 1.6 was the largest release yet created by the team. He said this version includes thousands of commits, bug fixes and new additions. One of those new additions was further support for integrations with other languages that can run on the JVM.

Nutter said that version 1.6 will allow developers to work with Ruby code in the Lift Scala Web framework. It is going to support JRuby as one of the languages in which you can write Lift applications. “This will make it easier to call into Scala from Ruby code,” he said.

Nutter went on to say that the OpenJDK is currently working on methods that will make it easier for projects like JRuby to be created. Unfortunately, work on JSR 292 (Invoke Dynamic) began well after JRuby was created, and thus the team has had to wire in these new handlers after they’d already created workarounds.

“We’ve had to make Ruby run as well as possible without Invoke Dynamic,” said Nutter. “We will continue to support Java 5. I think we can do a lot to support Invoke Dynamic without Java 7 specifically being done. I’ve been able to get Invoke Dynamic through much of the system without rewriting.”

While the Ruby world has become more competitive recently, JRuby remains a compelling choice for large applications, said Nutter. “We’re generally fairly conservative, and say we’re on par with Ruby 1.9. But for a lot of applications, the fact that the JVM does optimizing and has better garbage collection means that for larger applications, we’re almost always a faster choice than any of the other Rubies.”