15

Background: I'm writing a 'standard' (nothing special) web application in Ruby (not Rails) and I need to start thinking about deployment.

So I've been hearing a lot of recommendations to use JRuby to deploy Ruby web applications, regardless of whether you actually need Java libraries or not. How true is this? Is it worth using the Java implementation just for speed? Would I gain anything else by doing so? Would I run into any issues?

PS: I don't know Java that well, so "you can write parts of it in Java" isn't very helpful.

Sasha Chedygov
  • 127,549
  • 26
  • 102
  • 115

2 Answers2

24

JRuby is one of the most complete ruby implementations (there are a lot other ones out there such as IronRuby, Maglev, Rubinius, XRuby, YARV, MacRuby). It is very comprehensive, therefore, unless you use gems that use native C code, you will very very likely be just fine compatibility-wise.

JRuby is a bit faster than the actual C implementation, but it supports actual threads, whereas the official implementation is struggling a bit into getting it (it still uses Green Threads). Using Java threads from JRuby is quite trivial, even though it will require you to couple your code with Java (with a little DI, this coupling will only happen once, though).

Another benefit: runtime tools. Java, as a platform, instead of a language, has a lot of runtime tools to help you diagnose problems and check the state of the application (profilers, JConsole, and so on).

Twitter engineers also mentioned that the Ruby VM kinda has trouble being an environment for long lived processes, while the JVM is very good at that, because it’s been optimized for that over the last ten years.

Ruby also had a little security issue recently, which did not affect JRuby's implementation.

On the other hand, your project requires more artifacts (JVM, JRuby jars, etc). If you are using an application that will stay alive for long, and you want better runtime support, JRuby can be a great way to go. Otherwise, you can safely wait until you need these things to actually make the move (it is likely to go smoothly).

breandan
  • 1,965
  • 26
  • 45
Daniel Ribeiro
  • 3,110
  • 3
  • 23
  • 49
  • 3
    The Twitter developers' take on Ruby is somewhat specious. If the problem had been what they were saying, the sensible thing would have been to go with JRuby. They didn't move their Ruby code to Java — they rewrote it in Scala. It sounds like their problem was more with their code than with MRI. – Chuck May 30 '09 at 06:39
  • 4
    Note also that the Twitter Ruby-Scala move was mostly in the queueing part of the application, which (a) they admitted was poorly done in Ruby and (b) is welll-suited to a high-performance language anyway. – Mike Woodhouse May 30 '09 at 07:47
  • 2
    "...unless you use some very obscure gems, you will very very likely to be just fine compatibility wise." I disagree, some "common" gems use C extentions, e.g. god, mysql, sqlite3-ruby. – Robert Brown Jun 01 '09 at 03:39
  • 3
    there are java versions of the database gems so you won't have compatibility issues due to those. – jshen Jun 01 '09 at 19:04
  • 1
    What about for 2013? They say Ruby 1.9.3 and above is faster now. – Green Apr 17 '13 at 22:45
6

I use and love JRuby on daily basis, but I suggest you use MRI (a.k.a. C-Ruby) unless you have a actual need for JRuby.

Reasons for using JRuby:

  1. Java integration
  2. Restricted environment (your machine has Java installed by not ruby and you don't have root)
  3. Restricted environment (you have ruby installed but don't have root so can't install gems you need)
  4. You reached the limits of Ruby 1.8 performance and cannot use 1.9

From what you've described, you don't have any of the above reasons.

C-Ruby 1.9 has significant performance improvements over C-Ruby 1.8. I've yet to read (or find out for myself) how C-Ruby 1.9 compares with JRuby 1.8 or JRuby 1.9. In anycase, you don't have a performance problem (yet) so don't worry about it.

The good news is, you can start with either and convert later if needs be. It's all Ruby, and the Webrick and Mongrel gems work with both.

As mentioned above, ruby gems that have C extensions cannot be installed under JRuby. Hopefully this will change in the future if ruby C extensions utilize FFI.

http://kenai.com/projects/ruby-ffi/pages/Home

http://isitjruby.com/

Koen.
  • 25,449
  • 7
  • 83
  • 78
Robert Brown
  • 10,888
  • 7
  • 34
  • 40
  • Well I'm not using any C extensions that don't have Java equivalents, so that's not a problem. I have two incentives for using JRuby at this point: 1) real threads vs. the "fake" threads that MRI and YARV use (although I guess that's not too big a deal), and 2) access to Java libraries (which, as I stated above, means I can use a Java-specific database, or anything like that). Can MRI/YARV match that? – Sasha Chedygov Jun 01 '09 at 04:02
  • If you're thinking of going multi-threaded, then JRuby's real threads I think are a big deal. With an alternative design, for C-Ruby, you could use BackgroundRb http://backgroundrb.rubyforge.org/ or other "offloading" techniques like reliable-msg http://github.com/assaf/reliable-msg/tree/master – Robert Brown Jun 01 '09 at 06:59
  • Hmm, BackgroundRb looks interesting, I'll take a look! Thanks! – Sasha Chedygov Jun 01 '09 at 19:55