Mountain West Ruby Conference: JRuby by Charles Nutter and Ted Enebo
16 March 2007
Most of the developers in the auditorium have been Java programmers, and don’t
want to go back. Charles said that they have a hard time getting the message
out that JRuby isn’t about Java, it’s about Ruby, and they’ve aimed to make
JRuby as compatible as possible with Ruby.
Background: They’ve both been Java developers for the past ten years, and
their goal is to make Ruby a first-class language on the Java platform. They
didn’t start the JRuby project — they adopted it.
Ruby 1.8 Design Issues:
- Green Threading doesn’t scale across multiple processors/cores. The
one-size-fits-all scheduler doesn’t fit all platforms where it runs. Although
Ruby 1.9 will use native threads, there’s much work left to make it work on
various platforms. Java/JRuby already uses native threading and scales across multiple processors and cores. - Partial Unicode support. Ruby 1.9 will have Unicode support, but will bring with it other difficult issues (e.g. what happens when you concatenate two strings, each being in a different encoding?). In JRuby, one can use Java Unicode strings, or the Rails Unicode library.
- Slower than most other dynamic languages. Makes it difficult to sell to management. It’s a long term perception problem for the language. JRuby will allow compiling to bytecode, which allows HotSpot to do JIT optimization.
- Garbage collection is simplistic. JRuby uses Java’s best-in-the-world memory management and GC. Scales well to enormous applications and loads, and is battle-tested in deployments worldwide.
- C language extensions can crash the Ruby runtime, don’t necessarily interact well with garbage collection or with threading. JRuby lets you use Java-based extensions, which aren’t going to crash the VM.
Politically, it’s easier to get JRuby into an organization than Ruby, because
organizations have already accepted and deployed Java. JRuby is just a library for Java.
Most “pure” Ruby code runs on JRuby, and Rails mostly runs on it, although
only 90% of ActiveRecord passes unit tests. It’s easier to write JRuby code
than Java code. Perhaps Java is good for implementing libraries, and JRuby is
good for using those libraries for implementing applications.
JRBuilder/Cheri project by Bil Dortch lets you build Swing apps in JRuby much
more easily than writing Java code. Demo shown. Project is still in development.
NetBeans Ruby support is a one-man developer effort by Tor Norbye. His
progress has been impressive. Demo shown. Code completion, syntax
highlighting, built-in ruby documentations, go-to-declaration, auto-indent,
rename support, built-in interactive ruby shell (irb). By the way, Charles
uses vim, and Ted uses emacs. NetBeans Ruby uses the JRuby AST to do its work.
Speed. Interpreted JRuby is currently generally slower than Ruby 1.8.5, although some things are faster. They’re working on making it faster, and should be able to achieve comparable performance to Ruby 1.8.5. Compiled Ruby (bytecode) runs faster on the JVM than it does on Ruby 1.8.5.
Q: How can you make a JRuby app deployable so that people don’t know it’s a Ruby app or a Java app?
A: Make your ruby app into a jar file, and just double-click it.
Q: How easy or hard is it to deploy JRuby apps to servers?
A: Use Sun’s glassfish deployment framework.