Charles Nutter gives an update on his JRuby work in a recent blog post. He notes the ability to run JRuby as an applet, and points to ways of executing a Rails application inside the Glassfish application server.
Charles Nutter is a project lead on JRuby, the open-source effort to enable Ruby code to execute inside the Java VM (see Artima's interview with Nutter and Thomas Enebo from earlier this fall on the JRuby project's goals). The project has been making headway towards achieving key milestones, according Nutter's recent update in a blog post, Advanced Rails Deployment with JRuby.
One of the project's key goals is to enable Ruby applications to benefit from the highly scalable nature of Java applications, mainly by taking advantage of existing Java enterprise infrastructure. In his blog, Nutter reports on the ability to run a full Ruby on Rails application in the open-source Java EE server, Glassfish:
The current "best option" for deploying Rails apps into production ... involves the HTTP front-end Mongrel. Although Mongrel is largely written in Ruby, it is very fast ... because of its native C component for HTTP request parsing. It's also considerably more secure than CGI-based options... The typical Rails app will be deployed as a "pack of Mongrels", where the number of desired concurrent requests is multiplied by the number of independent Rails apps to determine a total number of processes. These processes must be managed, monitored, and respawned as appropriate, but the result is a fairly stable and scalable deployment model.
However, with JRuby, there will soon be a better option. I previously reported about Takai Naoto's efforts to deploy Rails behind an AsyncWeb front-end, showing tremendous performance improvements over a WEBrick-based deployment. Naoto-san has now taken things to the next level: Rails deployment under GlassFish.
GlassFish ... is extremely good at scaling up many concurrent requests across many independent applications... That means a single server, a single process to manage. GlassFish also supports clustering, which means you'll be able to hit the deploy button once and have your n-server cluster instantly start serving up Rails... That single app server can handle as many concurrent requests across as many independent Rails apps as you desire, scaling them across all the CPU cores you can throw at it... No more N * M process management, no more zombie processes, no more immature tooling to manage all those servers and all those deployments.
Another interesting JRuby development is the ability to use Ruby to write applets. Nutter reports that JRuby's small size allows download of the JRuby runtime inside a browser so that Ruby-based applets can execute in the client:
The full archive is about 2900kb. That's suitable for embedding in just about any application, and in fact I used a stripped-down 1600kb version for the JRuby Applet.
An example Ruby applet is available on Nutter's web site. Comments to Nutter's JRuby applet post noted that using Pack200 compression, available to Java 5 clients, would reduce the download size to about a fourth of the uncompressed size.
The final bit of news Nutter shares relates to ease-of-development and deployment in the form of a jar-jar—a file that contains code for all dependent jars:
Over the past few days I've made modifications to enable running a Ruby app completely out of a single JRuby JAR file... So by running ant jar-complete you get out a single JAR file that contains a complete, working Ruby interpreter plus stdlib.
While JRuby was a fairly dormant project before Nutter and Enebo took it over, it has enjoyed remarkable progress in the past year. That progress will likely accelerate with Sun's support for the project. Do you see yourself running your Rails applications inside the JVM, or even in Glassfish or some other Java EE server? And do you see yourself coding portions of an enterprise Java application in Ruby to benefit from that language's productivity features?