It's speedy. It's empowering. But it's (stil?) a memory hog. My personal issue with it is the memory consumption. Other than that it's an amazing project.
Why on earth would you choose a Java version of Ruby over a C version of Ruby? It seems to me people only use JRuby if they have a requirement for both Java and Ruby projects...J2EE developers?
It's faster than MRI. It allows you to write Java instead of C extensions. For developers without a C background, but with a Java or c# background that's pretty huge IMO.
Plus instead of running 16 Unicorn workers for an app, eating up over 4GB of memory, I can run one JRuby thread-pooled app, handling many more connections gracefully, with lower memory requirements, fewer database connections and better performance.
You get the whole Java ecosystem at your fingers.
It's faster than MRI (1.8.7ish) and a contender (maybe even faster now) against MRI 1.9.2.
It interops with other JVM languages.
It plays nicely with uptight IT departments (you only need to download the jars).
Not that I've ever seen referenced. You don't really see the YARV name thrown a ton these days either I guess, but MRI means C-Ruby to most I think. YARV is a VM and from what I understand Matz had very little to do with it in the period leading up to 1.9.
Maybe it was behind the scenes, but the original status pages for YARV gave the impression it was a one man job up until it was official.
My personal experience was that after trying to set up a connection to Sql Server 2000 for 2 days I tried to access via JRuby and had everything working in minutes.
I had exactly the same experience while trying to cook up an ad hoc test utility at our startup. I spent two days bumbling around with MRI Ruby and various gems and C libraries -- two days of utter frustration. I eventually realized that I could easily talk to any database with a JDBC library if I switched to JRuby, and that's what I did. Like you, I was up and running in minutes.
Access the many Java libraries available, it's the only Ruby interpretor with true threading (no GIL), integrates in the Java server ecosystem ( say with servlets via java-rack etc), upstream IT management approval (it's enterprise).
Interestingly, because it has true threading, it's actually harder to debug threading problems with JRuby than it is with MRI. MRI will tell you precisely where a deadlock happens, where JRuby just locks up. So it's good to have both.
I can't claim this with authority, but I would imagine that in most cases you would get better garbage collection performance from a JVM than from the MRI runtime, as the various JVMs have almost certainly been subjected to a greater amount of attention and work.
I've heard of at least a few rails deploys where the dev environment is MRI, for fast CI / test suite runs, and production is JRuby, for all the other (numerous) benefits listed here.
19 comments
[ 5.3 ms ] story [ 52.4 ms ] threadWe also set the JVM up to a fairly high maximum heap (500MB) which you can tweak back down a la -J-Xmx200M.
I fail to see how this is a major feature. Maybe it fulfills an enterprise requirement?
Plus instead of running 16 Unicorn workers for an app, eating up over 4GB of memory, I can run one JRuby thread-pooled app, handling many more connections gracefully, with lower memory requirements, fewer database connections and better performance.
You get the whole Java ecosystem at your fingers. It's faster than MRI (1.8.7ish) and a contender (maybe even faster now) against MRI 1.9.2. It interops with other JVM languages. It plays nicely with uptight IT departments (you only need to download the jars).
Maybe it was behind the scenes, but the original status pages for YARV gave the impression it was a one man job up until it was official.
Very pleasant surprise indeed.
(Although i can't google any examples in print)