views:

434

answers:

3

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.

+7  A: 

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 to 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 plataform, 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 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).

However, anytime you wanna know if you are using any gem that might not work on jruby, check isitjruby site.

Daniel Ribeiro
Excellent answer, that's exactly what I needed to know. Thanks. :)
musicfreak
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
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
"...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.
Rob
Ok. "Obscure" is quite subjective. Taken off.
Daniel Ribeiro
there are java versions of the database gems so you won't have compatibility issues due to those.
jshen
A: 

Actually, I just realized another benefit of using JRuby instead of MRI/YARV: I can use a Java-based object database such as JODB right inside Ruby. Goodbye, MySQL. :)

musicfreak
True, through JDBC you can access many if not all DB engines. If you need a lightweight DB and want to use C-Ruby, consider sqlitehttp://www.sqlite.org/
Rob
It's not "lightweight" that I need, it's something not relational. :) I'll use CouchDB if I decide to stick to YARV, but a pure object database would be better. But most of them are made for Java or .NET, so using JRuby has a big advantage here that I hadn't realized before. I'm not sure, I'll still need to give it some thought.
musicfreak
+3  A: 

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 dont have root)
  3. Restricted environment (you have ruby installed but dont 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 dont have any of the above reasons.

C-Ruby 1.9 has significant performance improvments 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 dont have a performance problem (yet) so don't worry about it.

The good news is, you cant 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/

Rob
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?
musicfreak
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
Rob
Hmm, BackgroundRb looks interesting, I'll take a look! Thanks!
musicfreak