

JRuby 1.6.0 Released: Now with Ruby 1.9.2 Support - petercooper
http://jruby.org/2011/03/15/jruby-1-6-0.html

======
stephenjudkins
JRuby is pretty unique among non-reference language implementations in that
it's often more performant, powerful, and stable than the standard Ruby
implementations. It's been rock-solid for us recently, and integrates with
Java surprisingly well.

I often think that the Ruby world would be a more productive place if the
original implementation had leveraged the JVM.

~~~
petercooper
Erik DeBill did some interesting benchmarks lately that showed JRuby has a
more linear performance overall when scaled up with heavier loads:

[http://erik.debill.org/2011/02/03/ruby-performance-in-the-
ra...](http://erik.debill.org/2011/02/03/ruby-performance-in-the-rails-
development-environment) <http://erik.debill.org/2011/02/19/ruby-start-up-
times>

And the Torquebox team (Torquebox being a JRuby Rack app server using JBoss)
also did some benchmarks and discovered (surprise, surprise) that Torquebox on
JRuby significantly outperforms the alternatives on 1.9.2:

<http://torquebox.org/news/2011/02/23/benchmarking-torquebox/>
[http://torquebox.org/news/2011/03/14/benchmarking-
torquebox-...](http://torquebox.org/news/2011/03/14/benchmarking-torquebox-
round2/)

(Disclaimer: Of course, benchmarks aren't authority figures so it's always
worth running them for yourself..)

~~~
gnufied
Just a nitpick, I see no comparison against 1.9.2 there in those Benchmarks.
It is either REE or MRI 1.8.7.

------
nwmcsween
I'm shooting in the dark here but does jruby work with the azul jvm? This
could mean quick and easy scalability until rubinius is worked out.

~~~
cschep
Stupid misclick, didn't meant to downvote. Your comment led me to google the
azul JVM so.. I learned something!

------
spaznode
Once method handles come out in java 7 things should get even more exciting.

~~~
ericlavigne
It sounds like you are referring to Project Lambda, which has been pushed back
to at least Java 8.

<http://openjdk.java.net/projects/jdk7/features/>

~~~
jonburs
Project Lambda is about adding closures to the Java language. Method handles
are part of the Da Vinci Machine Project
(<http://wikis.sun.com/display/mlvm/Home>) which is at least partially
supported in JDK 7.

------
atambo
If you're looking for a webserver to use for jruby check out kirk:

<https://github.com/strobecorp/kirk>

It's a really nice jetty binding for jruby.

~~~
larrywright
Mizuno is really nice as well: <https://github.com/matadon/mizuno>

It's wicked fast.

------
auxbuss
Great job Charlie, Tom, et al. One of the great FOSS projects. Awesome.

------
mrinterweb
I'm holding my breath for the RVM update for JRuby 1.6. Wayne is always on it
with the updates. Can't wait to try JRuby 1.6 out. I was waiting to try JRuby
until it supported 1.9.2. Looks like today is the day.

~~~
andrewvc
rvm install jruby-head

------
hugh4life
Great, I've been waiting for 1.9.2 support..

Now I really wish some more work was being done on Jython because Jython and
AppEngine is what is holding back Django from moving to Python 3+.

------
jseifer
As usual, rvm is quick to update. If you're on rvm: rvm update head; rvm
install jruby.

~~~
mdemare
Actually, it's: rvm get latest ; rvm reload ; rvm install jruby

------
rbranson
Will a stable implementation of fork() ever exist? I know JRuby provides
threads, and that is great, but I have existing code that's using fork() +
message-passing I don't care to rewrite it using shared memory and threads.

~~~
stephenjudkins
No. The JVM spins up several threads, even when running a single-threaded Java
program. Threads and fork() do not mix well together, and using threads is
heavily entrenched in the Java world. I doubt Oracle intends to do the work to
make fork() work.

As far as rewriting your code, would it be that difficult to change it to use
threads? They don't FORCE you to share state, and there are powerful
primitives for message-passing in java.util.concurrent. As long as you're not
abusing global variables in Ruby it should translate over just fine.

~~~
rbranson
I don't have a strong use-case for JRuby in this particular case, so I'll just
continue to use YARV. There are some Java libraries I've been tempted to use,
but it's not crucial at this point.

It's not implementing message passing that's the problem, it's the shared
state, multi-threaded model in general. It's too easy to trip up, so I prefer
fork() and message-passing. I am less worried about my own code, but what
future maintainers who have less experience in concurrent programming will
have to deal with.

It's just a framework for a pool of workers that hang off an MQ, so fork()
also provides some extra resiliency in the event that something bad happens.

~~~
bensummers
There's nothing stopping you from running multiple JRuby instances, just as
you would with any other interpreter, it's just you can't use fork() to create
them. Use an external script/daemon to start up multiple processes.

It's not as memory efficient as MRI, but isn't _too_ bad unless you're on a
cheapo memory constrained VPS.

------
swaits
Is MRI embarrassed yet?

~~~
headius
I personally believe the MRI core devs have done a great job of moving YARV
and Ruby 1.9.x forward. We would not have added 1.9.2 support had they not
cleaned it up and made it a really compelling set of features.

YARV may start to lag behind in performance measurements, but it's already
faster than many popular runtimes (Python, for example) and there's nothing
stopping them from making more drastic moves to improve it (adding JIT or
concurrent threading).

And of course they are still the reference implementation; we want them to
continue to push the boundaries of what Ruby can do, and continue to challenge
us with new features.

