1. Incomplete integration with postgresql. The ActiveRecord jdbc adapater doesn't have all the features that the standard pg adapter does.
2. Slow startup / test runs. At one point, loading large amounts of files (like during rails bootup) was much slower on jruby than MRI.
You can develop on MRI and deploy on JRuby. Several people, including myself and Square, develop JRuby applications this way, and validate stability across multiple Rubies by doing matrix builds on a CI system.
Check out Xavier Shay's talk on the matter:
http://www.youtube.com/watch?v=hMpd4CzR1f8&t=16m
I know several people balk at this suggestion and claim development should be as close as possible to production... and do that despite the fact they develop on OS X and deploy on Linux, develop with a case insensitive filesystem and deploy to a case sensitive filesystem, develop in an environment without load and deploy to an environment with load, etc...
I'm looking for help filling it out. Here's the mostly stubbed extension:
https://github.com/headius/jruby-pg
And here's the docs for pgsql's hidden interfaces (cast the JDBC objects to these, and you're good to go):
http://jdbc.postgresql.org/documentation/publicapi/index.htm...
I did some basic benchmarking with one of the JRuby 1.7 preview releases and was impressed enough with the speed benefits to want to try it out with a small app on Torquebox when JRuby 1.7 was released.
Thanks to joevandyk and xiljin for pointing out the search_path and datatype support situation before I undoubtedly encountered them myself - and love the fact that headius has immediately leapt in to try and fix things :-)
Interested to do some testing as it comes together and see what I can help with.
I'm planning on using it with postgresql - do you have any links to whats not supported with the JDBC drivers ?
This is the big one, in my opinion. See here[1] for some benchmarks of JRuby + invokedynamic. We're talking orders of magnitude for some benchmarks.
[1] http://blog.headius.com/2011/08/invokedynamic-in-jruby-const...
Previously languages like Ruby suffered on the JVM as the set of JVM instructions available were designed around the Java programming language. This meant that for invoking Ruby methods and other things like accessing instance variables could not take advantage of many of the JVM's features such as method inlining.
Since HotSpot is unaware of Ruby semantics, invoking Ruby methods involved a bunch of custom logic implemented in the form of bytecodes which were completely opaque to HotSpot and thus could not be optimized away.
InvokeDynamic allows JRuby to teach the JVM how to invoke Ruby methods in a way that plays friendly with the HotSpot inliner. Here's a contrived example of HotSpot inlining a Ruby method and optimizing it down to a single assembly instruction:
jruby-1.7.0.RC2 -Xcompile.invokedynamic=true
Anyway Ruby 2.0 is suppose to solve the Ruby is Slow problem. although i have yet to see any evidence that will the case. Sigh.
In the future, even if JRuby team does only bug fixes, JRuby will get faster and faster as JVM's support for dynamic languages improves through InvokedDynamics.
/usr/local/src/jruby-1.7.0/bin/jruby -Xcompile.invokedynamic=trueOn one hand, JRuby is technically a much better Ruby than Ruby, and if you want to improve bulk throughput you'll probably benefit. On the other, if bulk throughput were important, Ruby probably wouldn't be your first choice, and there are some downsides.
The biggest problem, especially for Rails, is the warm-up cost. Rails's start-up time is already painful, and adding to that hardly improves the test-develop cycle. I've not tested this latest release, but in 1.6.8, running a test suite was multiples slower than C Ruby. Test suites, which run a lot of different code, aren't really representative of real-world workloads, but if you're working on an application it really hurts.
You might also have trouble with gems that have compiled extensions. It takes a bit of Gemfile fiddling, but there are alternatives to most of those.
For applications other than Rails (which is really a bit of a pathological case), JRuby seems well worth a look. I've never found C Ruby's threading up to the job of making a responsive GUI application, but JRuby might work a lot better with its JVM-backed threads.
In short, there's potential downsides that may or may not be relevant to your usage. That said, even if you aren't using the Java ecosystem, the garbage collection, performance, and threading in JRuby may be worth your time. It's all up to what you're actually doing.
This solved it: https://github.com/jruby/jruby/issues/346
tl;dr:
rvm get stable
Big thanks to all the contributors!