

JRuby 9000 released - headius
http://blog.jruby.org/2015/07/jruby_9000/

======
aurochs
JRuby is a great idea.

It has one pitfall which consistently stops me from using it though : poor
support with newer releases of Rails, usually due to the Active Record stack
not working well with the AR JDBC adapter.

I know some work was being done on a JRuby version of the standard pg gem
(without the need for JDBC) which would be fantastic if it was completed and
working.

~~~
astrodust
Define "newer" and define "poor"? The JRuby team has done a fantastic job of
keeping things working. Do you have any specific problems other than vague
grumblings?

Anyone married to the MRI ecosystem because of dependencies on modules with no
JVM equivalent may have problems, but new projects usually have no such
issues.

~~~
amalag
I don't want to complain because it is a free product. But there is no doubt a
big lag with activerecord. Rails 4.2 is still not supported:
[https://github.com/jruby/activerecord-jdbc-
adapter/issues/59...](https://github.com/jruby/activerecord-jdbc-
adapter/issues/599)

~~~
juliangregorian
Currently, there's $1700 in store for whoever does support it:
[https://www.bountysource.com/issues/5831191-tasks-to-
finish-...](https://www.bountysource.com/issues/5831191-tasks-to-
finish-4-2-support)

~~~
ch4s3
Yep, I've put up money for it myself, and regularly be on twitter for other
folks to do the same. I wish a big company that uses jRuby would step up and
support the tools they use :/

~~~
headius
Agreed.

~~~
ch4s3
Know anyone? ;)

------
Freaky
Concurrent threads using magic regexp vars like $1 stomp all over each other,
quite nasty:
[https://github.com/jruby/jruby/issues/3031](https://github.com/jruby/jruby/issues/3031)

Stumbling over a serious race condition in the first 5 minutes of trying it
with real code makes me a bit wary. All the performance in the world isn't
much good if it's randomly _wrong_ :/

~~~
rugmug5
You really shouldn't be relying on globals anyway. Using $1 etc. is a serious
code smell. It shouldn't by definition be threadsafe in any event. The only
way that would work would be if you rely on the threads not actually running
at the same time as an implementation detail of the MRI.

~~~
infraruby
$~ and friends are not global:

    
    
      def f
        p $~ # => nil
        "123" =~ /\w+/
        p $~ # => #<MatchData "123">
      end
    
      p $~ # => nil
      "abc" =~ /\w+/
      p $~ # => #<MatchData "abc">
    
      f
    
      p $~ # => #<MatchData "abc">

~~~
headius
Matz himself has said he regrets putting these variables in the language, and
some day they may disappear. We'll match behavior as much as possible, but
they're a relic no matter how you slice it.

------
Scarbutt
_JRuby 9000 now uses native operations for much of IO and almost all of
Process. This makes us the first POSIX-friendly JVM language._

Did they achieved this via JNI?

~~~
mdavidn
This will prevent running JRuby 9000 in (today's) Google App Engine.

The project has been drifting away from App Engine support for some time now.
See #2304.

[https://github.com/jruby/jruby/issues/2304](https://github.com/jruby/jruby/issues/2304)

~~~
chrisseaton
There's a pure-Java fallback that has most of the same functionality. But if
you wanted precise POSIX function calls you probably weren't running on App
Engine anyway.

~~~
jshen
Have you tried the pure-Java fallback on App Engine? I tried it for JRuby 1.7
and it didn't work. I haven't tried yet with 9000, have you?

~~~
headius
We welcome GAE users of JRuby but they never seemed to be a big segment of the
community. And we continue to maintain non-native IO and process logic for
limited environments. If that is not sufficient for GAE, we'll work with you
to make it so.

~~~
jshen
Jruby 1.7 simply doesn't work in GAE, and maybe it's not worth making it work
there, which I would understand. I opened an issue a while ago
([https://github.com/jruby/jruby/issues/2304](https://github.com/jruby/jruby/issues/2304))
and I spent about a week trying to fix it. Each time I fixed one issue another
one popped up and I gave up after hacking up JRuby beyond my comfort level.

Edit: I just want to stress, the JRuby team is amazing, and I've always been
impressed with the responsiveness and openness of the team. This comment isn't
meant as a critique in anyway, just a statement of fact with my experience
trying to run JRuby on app engine.

------
magicdream
We're using JRuby in some core projects and it's great. From my experience
(moved 2 high load projects to Jruby) transition to JRuby from Ruby is not
just changing Ruby version. But often you spend around 1-2 weeks to move
medium size project on it, change some gems and configure Java options to not
have out of memory errors. So it works fine, I'd not say that it works much
faster than latest Ruby. But I think that main reasons why you should switch
are multithreading and Java libs. We switched because of we was need to use
latest Java libs for Kafka. But the main disadvantage is that sometimes when
you need to deal with Java objects you need to think about object data type
casting (from Ruby object to Java and vice versa). And this is extra actions,
extra memory usage.

I'm very happy to see JRuby 9000 and hope we'll upgrade soon.

------
flowerpot
I've actually found JRuby to be very handy when it comes to packaging. Using
warbler I can generate a jar file and then using the javapackager I can create
self contained packages for all the major platforms/package managers: windows
(.exe/.msi), linux (.rpm, .deb), osx (.dmg). Way more painless than packaging
a ruby runtime. I've tried traveling ruby, but have not had the same seamless
experience. Especially when it comes to multiple platforms. However, packaging
with java, jruby and my application usually turn out to be quite large. Around
80Mb for a CLI and the startup time for short running programs like CLIs using
JRuby can be quite long.

------
mataug
Damm, I so wish Jython improved like this too. I've been thinking of helping
out.

~~~
brightball
jRuby is one of the biggest reasons I lean to Ruby over Python. Ruby gains a
lot more from the JVM than Python (at least that's my understanding) does and
that leads to much more momentum behind jRuby.

~~~
WaxProlix
Like what? They both benefit from the lack of GIL (Jython maybe moreso) as
well as the portability and other benefits of JVM as a platform.

~~~
chrisseaton
Jython doesn't use advanced functionality like invokedynamic.

~~~
jrochkind1
It's unclear how much benefit invokedynamic actually provides at present, I
recall seeing benchmarks not showing much.

I think the big JRuby advantage is actually that by and large code written for
MRI Just Works on JRuby. The exceptions are relatively few, and usually easily
worked around, or if not quickly bug fixed. Despite this thread, I haven't had
significant troubles with ActiveRecord-ODBC, although in Rails 4.2 have
occasionally run into relatively minor worked-around-able issues.

My impression is that code written for standard Python tends to have a lot
more trouble running on Jython -- not from any fault of Jython, but because
'standard' Python code tends to be more likely to use native C than typical
ruby.

~~~
headius
Invokedynamic's benefits have been a bit of a mixed bag, but id _does_ make
the JVM see through dynamic call sites and optimize them like it does
statically-typed call sites. That generally improves performance for JRuby,
but there are cases where simply inlining the code together doesn't lead to a
measurable increase.

~~~
mike_hearn
Given that both you and Chris are posting to this thread, I was kind of
surprised to learn that you're planning to focus on a non-Truffle
compiler/optimisation engine in future. Isn't Truffle meant to give huge
speedups? It sounds like you might eventually get JRuby 9000 to be faster than
MRI but that a rewrite of the current code didn't do it yet.

Is there some kind of vision or plan for how Graal/Truffle fits into the JRuby
roadmap?

~~~
chrisseaton
Truffle is a research project. It is not a short-term goal to replace the
current IR-based runtime in JRuby, and Truffle isn't really part of the 9k
release (it's there but I wouldn't recommend trying to use it).

We are working towards being fully compliant and we're getting there fast - I
think with four full-time people and more in support we are now the largest
employer of Ruby implementors anywhere. But since we aren't ready yet,
stopping work on IR isn't an option even if we wanted to do so and we all need
Charlie and Tom to continue their excellent work on the IR.

In my personal view, Truffle will be good enough to replace JRuby runtime at
some point in the next couple of years, but we aren't advocating for this now
and if it did happen it would be because the JRuby community and leadership
make that decision for themselves.

I think we might come up with some kind of roadmap, or at least stated plan,
at JRubyConf next week.

------
kul_
So why does JRuby never got as much traction as other jvm langs like clojure,
scala, groovy? I have heard good things about the ruby syntax, top that you
get unparalleled powers of jvm like gc, cross platform, libs and much more!

~~~
VeejayRampay
For the same reason that alternative implementations of Python never got the
kind of traction they deserve, because 90% of the gems, libraries and
everything are specifically tailored to MRI and it's always harder to play
catch up.

Also, the strong anti-Java culture in the Ruby community probably didn't help
(even though JRuby has nothing to do with Java, or very little).

~~~
pjcabrera
Nothing to do with Java? Really? How did you come to that conclusion?

------
rf3000
Fantastic news! Very excited about seeing the Ruby ecosystem advance.

------
lgleason
Big thanks to the Jruby team!

------
gary4gar
is it faster than MRI?

~~~
FooBarWidget
That depends on what you mean by faster. For CPU-bound work, JRuby is almost
always faster. The JVM is very good at optimizing. However, the best
performance doesn't kick in until the JVM is sufficiently warmed up, which
means JRuby shines mostly for long-running tasks. Warming up can take a few
minutes, although some people tell me that I should warm up for half an hour
(!).

On the flip side, JRuby starts much more slowly than MRI. This is a general
Java problem: startup times are problematic. Also, code reloading performance
may be worse than MRI, so things may be slow in development. JRuby is
optimized for production-level long-running workloads. So something like
'rake' will likely take longer with JRuby.

~~~
astrodust
In practice I've found the start-up times aren't all that different. The drag
is more pronounced on older hardware, though. A current i5 or i7 system with
an SSD is usually _roughly_ the same.

~~~
FooBarWidget
That is very contrary to my experience. A Rake task in a Rails project almost
always takes somewhere like 15-20 seconds just to start up (on MRI it's around
2-5). Just today, I tried to run the Middleman static site generator. Where on
MRI, Middleman starts building after around 3 seconds, on JRuby it starts
building after around 10 seconds. And I'm on a 2012 Macbook Air.

------
fokinsean
It's at 9000!

~~~
igorgue
One more version to be over 9000!

------
joegyoung
If I committed to using jRuby instead of regular ruby, I would have that
nagging fear that Oracle would go after all the other companies that build
their product using Java APIs.

~~~
headius
We work closely with engineers at Oracle and JRuby is one of the premier
projects on the JVM. There's also no legal way they could come after us; their
suit against Google is about copying Java APIs, a very narrow domain.

