|
In their RailsConf tutorial, two of JRuby's core developers discuss building the two-way bridge between Java and Ruby
May 23, 2007
URL:http://drdobbs.com/web-development/jruby-making-the-enterprise-see-red/199701535
Charles Nutter and Thomas Enebo are on the verge of releasing JRuby version 1.0. The pair are the principal developers of the pure Java-based Ruby interpreter, and they took some time out from the final bug fixes to hold a tutorial at RailsConf in Portland, Oregon: "Your First Day with JRuby on Rails." However, their talk was not focused solely on getting started with JRuby. They also reported on the convergence of a lot complementary technologies from Sun that are supporting Ruby, including NetBeans and Glassfish.
Before diving into the "How To" of JRuby, Charles and Thomas addressed the "Why." As in, why would Ruby developers opt for JRuby over the C-based version that already works for them? First, JRuby provides a foot in the door, getting Ruby into Java-centric organizations that otherwise might balk at a new language or platform. Equally important however, JRuby may convince Ruby developers to adopt the Java platform to take advantage of its scalability and to get at the wealth of Java libraries that provide capabilities that Ruby currently lacks.
They also wanted to assure the audience that one could gain the advantages of the Java platform without deviating from the Ruby Way. JRuby is not an attempt to fork Ruby or future versions won't corrupt it with "improvements." To that end, JRuby 0.9.9 is almost identical to Ruby 1.8.5, and the JRuby install includes all of the same standard libraries that ship with Ruby. Charles pointed out, " We've bent over backwards to make sure that JRuby is as compatible as possible." With the addition of just a few import statements, most pure Ruby gems run fine in JRuby. After demonstrating a standard Rails installation operating as expected, Thomas exclaimed, "Isn't it exciting how boring it is?"
Speed is another potential barrier to adoption, but Charles reported that the current version of JRuby is about on par with Ruby. Previously, JRuby has been purely interpreted code. Over the past few months the team has focused on improving the compiler's ability to handle Ruby syntax. Right now, about 25% of the code in a typical Ruby app can compile. In JRuby 1.0, the compiler runs in a JIT mode, so as running code reaches a certain number of invocations, it will get compiled, after which point the compiled version runs. The goal after the 1.0 release is to continue increasing the amount of JIT compiled code.
Despite the pains taken to port Ruby as completely as possible, there are a few important differences with JRuby: database access, native-extension support and anemic command line performance. The database access differences seemed like more pluses than minuses. Although JRuby does not yet support every database as does Ruby, the pure Ruby MySQL and postgreSQL drivers run fine. Other databases are at various stages of support. Oracle support should be in Continuous Integration shortly after the 1.0 launch.
Alternatively, JRuby developers can use JDBC for access. The ActiveRecord-JDBC gem is available as a Ruby extra. Charles noted that "support for databases is a little better than the C implementation at this point, because it's very easy for us to bring up new databases with a common API like the JDBC." Another plus is having JNDI for connection pooling, which lets you avoid dedicating the resources needed for one connection per process. On the down side, JDBC doesn't have any schema management API, similar to Rails migrations.
The second caveat was the lack of support for C-based extensions. A few have been ported to Java, such as Mongrel and Hpricot. Charles and Thomas gave a hat tip to fellow JRuby project member Ona Bini for his porting efforts, which include OpenSSL. They offered four workarounds for native extensions: Don't use them; use a Java equivalent; port the library yourself; or the easiest route--just write Ruby code to wrap a Java library.
The third difference was command line performance, which they cautioned is not stellar. Thomas showed some Fibonacci benchmarks that revealed how Java is particularly slow at startup. But once it optimizes performance, it matches C-based Ruby, and in many cases, JRuby is exceeding Ruby. Thomas mentioned another project in the works to pre-prime a server or JRuby daemon in the background to mitigate the startup lag.
Charles also pointed to Java's superior unicode and threading support. JRuby also provides support for Ruby's 1.8 byte-bag String and the multibyte library that comes with Rails. JRuby offers full support for the Ruby threading API, even the unsafe operations Criticalize, Kill, Raise. But it also lets you take advantage of Java's true concurrent threads. The JVM in JRuby creates one Java thread for each Ruby thread. "This allows you to use multiple cores automatically out of the box," Charles pointed out. "If you run a typical JRuby app you'll see that all of your cores in your system are in use; in Ruby you will only see one." As with Java apps, you can also spin off long-running jobs to avoid bottlenecks.
The Java platform also provides a number of options for avoiding Rails deployment headaches. As with Ruby, you can use Mongrel for JRuby deployment, but it's not advisable because each mongrel process starts up a new JVM. A better option in JRuby is a new Rails plugin for building .war files named "Goldspike" (an allusion to the transcontinental railroad bringing east and west together). The Goldspike-generated .war file lets you deploy a single file archive containing all of the app dependencies static files, rhtml files, the full JRuby implementation and standard libraries. You can deploy to any Java application server--Tomcat , JBoss, WebSphere, WebLogic and, of course, Glassfish. In organizations with an existing app server setup this has an obvious advantage. Charles and Thomas also demonstrated Sun's new project that runs GlassFish V3 as Ruby gem. As evidence of the rapid developments focused on Ruby, Charles joked that the project, "is only two weeks old and it's already at Version 10!"
For skeptics wary of the hassles of using Java2EE, Charles sought to assure them that access to the "good" J2EE features was worth it. "There's a lot bathwater, but a lot of baby too," he noted, pointing to JMS, the Java Persistence and Transaction APIs, and again, the deployment and scalability advantages.
Charles and Thomas also praised Sun's NetBeans 6.0 as the ideal development platform for JRuby. It's due out later this year, but the Milesone 9 version available now already supports developing JRuby, Ruby, and Rails applications. They demonstrated the IDE's ruby-savvy features including code completion, showing available classes and methods for the current expression, along with the associated RDoc documentation, syntax highlighting, and robust debugging (breakpoints, call-stack navigation, and so on.)
To underscore JRuby's ready-for prime-time status, Charles noted that some major projects being written in JRuby, including Mingle 1.0 from ThoughtWorks, Mingle is a collaborative application lifecycle management tool for Agile IT projects.
For more information check out the JRuby home page, as well as Charles' blog, and Thomas' blog.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.