When I worked on a sizable JRuby/Rails codebase, our team had a hybrid approach: ephemeral jobs (rake tasks, migrations, autospec) all ran under MRI, while long

When I worked on a sizable JRuby/Rails codebase, our team had a hybrid approach: ephemeral jobs (rake tasks, migrations, autospec) all ran under MRI, while long-lived processes (app servers, CI/acceptance test runs) ran in JRuby. That gave us the best of both worlds: quick startup in cases where total runtime was an issue, and better throughput (and more predictable memory usage) for CPU-heavy workloads. In my experience, MRI/REE fits into smaller RAM footprints only in cases where either you start up and shut down runtimes relatively regularly, or you can monitor for runaway leaks and terminate bloated processes. I do agree that switching to a different runtime just to get access to a few libraries is probably the wrong approach, however. The big wins in using JRuby are, to me, twofold: a nice performance boost for general application code, and the availability of robust, battle-tested application servers. Mongrel, Unicorn, and Passenger are fine if you're willing to live on the edge, but if you have a more conservative ops team, or simply don't want to both with rolling your own monitoring and deployment stack, being able to drop a Rails app onto Tomcat or Glassfish as a single WAR file is pretty damn nice.