This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Why aren't you using JRuby?

updated over 7 years ago; latest suggestion almost 8 years ago

This proposal has been withdrawn...

It's hard to believe that some people aren't using JRuby.

It's fast, has proper threads, and runs all the stuff you care about.

Perhaps it's because it seems all weird and foreign, and, dare I say it, it's got some Java in it? Don't we use Ruby to avoid things like Java?

But there's no need to be scared. I'll go through the absolute minimum you need to know to use JRuby in development and production, and convince you it's just another Ruby.

But then I'll also tempt you by showing how you can use one of the many mature and feature-packed Java libraries in your Ruby code, and explain why Ruby on the JVM is a great place to be.

I promise there won't be a single line of Java.

My background: I've been running JRuby in production for about 3 years. The project uses many Java libraries and an additional languages interpreter, all in a single JVM.


  • 2940bc7d4506f3e099e3dcc32a412b98 Jon Leighton suggests almost 8 years ago

    If you have experience of using MRI in development and JRuby in production (in order to deal with startup time issues in dev) then I'd like to hear about that. Particularly whether you think it's a good/bad idea.

    Personally I can imagine using JRuby for a small subset of my application where it gave me access to a certain library I really wanted. But I can't imagine ever being persuaded that I should put an entire application on the JVM.

  • 587332bf7906e6f46c05b3b46b885644 Hakan Ensari suggests almost 8 years ago

    There was an interesting talk by one of the GitHub guys in Euruko last year on not wanting to use JRuby. He didn't say it explicitly, but that's what he was basically getting at. It would be interesting if you picked up on some of his arguments.

  • E20fc22ed6d97b618e584b176ad98e20 Fiona Tay suggests almost 8 years ago

    I chanced upon this proposal while considering submitting to RubyManor. I gave a talk at LA Ruby on this topic last weekend, which was pretty well-received.

    The long and the short is, I think there are compelling reasons for using JRuby - Java library access, deployment, and performance - but would stick with MRI unless either of these were important.

    Ping me at, I'm interested in hearing your side of this debate.

  • A6748d9bae5729f00802fd85fc01fd44 Stuart Eccles suggests almost 8 years ago

    It would be good to hear about JRuby infrastructure in production. I've heard good things about Torquebox and it looks appealing. What are the gotchas? (apart from the obvious C extensions in gems)

    Rather than the bare minimum, a more insider look would be better. In 3 years what has been the worst thing about it?

  • Be3698f145a80c1230fd667c87d0f0c8 Tom Stuart suggests almost 8 years ago

    I’m very interested in this talk.

    In JRuby 1.7, C extension support is “disabled and on its way to being removed”. My biggest JRuby question: does removal of C extension support mean we’ll forever need a page like this to help us find Java or pure-Ruby replacements for gems which rely on C extensions, or is there some future path which will allow native gems to run everywhere? How does FFI fit in?

  • 3f8fcabf5960ae755f6e5479e38939c9 Dave suggests almost 8 years ago

    Most of the reasons I've heard for using JRuby are aimed at threading and performance (to quote Joel a 'better' ruby) and while use of Java classes might be interesting I'd rather hear about how to get up and running with JRuby and what gotchas there were, such as issues with gems

    I'd love to come away feeling fairly confident on how to get a production app running on JRuby

  • 6597b956887bfa6066bd08be263a08ca Joel Chippindale suggests almost 8 years ago

    I like the sound of this talk.

    The idea that JRuby is just a 'better' Ruby seems much more interesting than the it's a Ruby that you can easily use Java from.

    If you think you can make that case then I would focus on this rather than demo'ing making use of Java libraries in JRuby.

  • 09d77902a19332185d0629a686a8db0b ianrumford suggests almost 8 years ago

    Although startup time is much better, jRuby still leaves a lot to be desired.

    Headius recently posted some good suggestions - worth covering them imho.

  • Acd62030df551952268e84c8fff26a5b James Adam suggests almost 8 years ago

    I think this presentation has a lot of potential, but I think it would definitely be good to try to address the questions that Paul outlined at the bottom of his suggestion.

    I have heard that JRuby is Fast and Good, but perhaps if someone can show me just how easy it is to get set up with it (both locally and on the server for deployment) I'll be more likely to properly try it out...

  • The proposal author responds almost 8 years ago

    Your reasons are valid, but a little out of date.

    1) Testing -- yes, startup time is an issue, but it's much better now, and there's nailgun, which keeps a process ready in the background.

    2) JRuby supports C extensions. However, they have a global lock around them, so aren't best for performance, and in general, "popular" gems with C exts have a Java version. Rails now uses JDBC connections automatically with nothing else to learn apart from which other gem to install.

    3) "Good enough" is a very good reason.

    4) Yes and no. You can ignore anything you don't want to get involved with.

    I very much like the "bare minimum knowledge" idea. Perhaps go for that, and then show a compelling example of using a best-of-breed Java library?

    An idea might be one of the PDF generation libraries, and showing how to translate a Java example into Ruby code?

  • 2abf5beb51d5d66211d525a72c5cb39d Paul Battley suggests almost 8 years ago

    Here are some reasons why I'm not using JRuby:

    1. Testing is slow, and a slow test feedback cycle is counter-productive at best and miserable at worst. JRuby takes a while to start up, and the optimisations seem not to kick in until code has run a few times, which doesn't happen so much in testing. I've found running a Rails test suite to be between slightly and an order of magnitude slower under JRuby, if it even runs at all (see next point).

    2. Making a large Rails app run on JRuby isn't just a case of changing the interpreter: you'll need a different database interface with a four-letter abbreviation. Gems with C components won't work, so you'll need to find alternatives. Even after all that, I've yet to succeed in getting an existing Rails app to run a test suite from end to end without failing or hanging.

    3. My clients are happy with normal Ruby. Or, at least, they're not annoyed by it enough to want to change.

    4. I understand Unix, but Java has its own vocabulary, infrastructure, and conventions. Never having been a Java programmer, I don't know any of these things, but much JRuby advocacy assumes a working knowledge of the Java ecosystem.

    So some questions I'd like the talk to answer:

    1. How can I make testing less painful?
    2. How do I port a Rails app to JRuby?
    3. What benefits would clients gain from hosting their apps on JRuby?
    4. What's the bare minimum that a Ruby programmer needs to know about Java-world to get started? JDKs, JREs, classpaths, JDBC, WARs, servers, etc. What's a recommended hosting stack?