Sunday, June 10, 2007

JRuby 1.0 Released!

We have finally released JRuby 1.0, based on the last release candidate, RC3. And what more is there to say? Not really a whole lot...It's almost entirely RC3, with one or two minor fixes added in. But it's really turned out to be an outstanding release, and already reports are coming in of folks trying it out en masse. We're very happy.

So I'll do a little recap here. JRuby 1.0 was focused almost entirely on one goal: Ruby 1.8.x compatibility. To that end, we are now the only alternative Ruby implementation that can reasonably claim we're "compatible". It's no longer a question of whether we can run Ruby applications or not...we've proven that again and again. The issues people run into now are those requiring minor behavioral tweaks, minor parser tweaks, and occasionally exploration of some peculiar threading or memory concerns. It's been a long time coming, but the compatibility issue is largely answered.

Now we start looking toward the future. Once you have a working Ruby implementation, what next? I believe we've shown that the correct way to approach Ruby is to get it right first. The next step is making it run as well as possible. Ok, so we've cheated a bit along the way, introducing interpreter optimizations and a JIT compiler, but that's all fun stuff. The heavy lifting for performance and scalability are coming up, and there's a lot of low-hanging fruit we can start to tackle with 1.0 safely behind us. So action item #1 for the future of JRuby is plucking that low-hanging performance fruit.

The second item for any working implementation would have to be platform integration. Our platform is Java (and of course we've cheated a bit here by doing additional work to make Java integration really useful and usable), so integration involves making Ruby a better citizen of the Java platform. In this area, expect to see us further reduce the disconnect between Ruby and Java, allowing you to construct Ruby objects directly from Java code, define real Java classes using Ruby (classes you can then compile Java code to call), and minimizing to as large an extent possible the performance impact of calling from dynamically typed Ruby code into statically typed Java code. Java integration is action item #2.

And then what? Well, there are many options, all very attractive. I personally would like to see time spent implementing potential Ruby 1.9/2.0 features, to provide a second testbed where people can try those features out. I would like to find ways to share code with Rubinius (beyond tests), either by implementing just enough Rubinius logic to run its pure-Ruby core-class implementations or by implementing a full Rubinius kernel on the JVM. I would like to see JRuby expand to the rest of the Java world, bringing the Ruby Way to Java EE. But most importantly, I want to reach out to the Ruby community and find ways for them to be a part of the JRuby process.

Up to now, JRuby has really existed in its own, separate world. There was the Ruby community and also the JRuby community, and although members might identify themselves with both, there was always this perceived boundary.

We need to break that boundary down...not only for JRuby but for the other Ruby implementations as well.

Ruby is coming of age. Multiple implementations shows that Ruby has really matured as a language...and also shows it has a lot of maturing left to do. Ask Evan (of Rubinius) or me how we feel about retry behavior or block argument processing or thread event processing or SAFE levels and tainting and you'll start to understand some of the ugly, hidden bits of Ruby. We need to make sure that Ruby development proceeds as a whole...not necessarily as a single project or a single codebase, but as an open, direct exchange of concerns, complaints, solutions and ideas. We need to start treating the Rubinius community and the JRuby community and any other implementations' communities as part of the whole...different facets of the same gem.

If you have never tried an alternative implementation of Ruby: do it today. Pick out your favorite app, library, or framework and build your next app using something other than Matz's Ruby. Start running your continuous integration tests against JRuby trunk (or Rubinius trunk, if it runs your code ok; those guys sorely need more CI hits). Make sure your gem releases work on JRuby too, and if you have native (i.e. C) code, explore what it would take to do a JRuby port. Show that you welcome diversity into the Ruby world...that you recognize that diversity is an essential part of language evolution.

JRuby has always been a community project, and only by absorbing the JRuby community into the Ruby community will JRuby continue to be successful. If we can make that happen, I see wonderful things in Ruby's future...regardless of which implementation you use.

12 comments:

  1. Good job for the team's work. However, I think I will not try JRuby until it supports for 'win32ole'. I am always program in Windows platform and I use quite a lot of window's ActiveX dll. If I want to port my current application to JRuby, supporting'win32ole' is a must for me. I heard about the Java JACOB before, but never explore how it could use in JRuby.

    ReplyDelete
  2. Thanks so much to the entire team for the hard work. This is great, and the future sounds hugely exciting!

    ReplyDelete
  3. Congratulations Charles, Thomas and all JRuby Core Team. This is indeed an important milestone for all Ruby communities. And I totally agree on having Rubinius more on the spotlights. Their efforts can't go on unnoticed any further. I guess the future of JRuby + Rubinius opens up big doors!

    ReplyDelete
  4. Congrats Charles !

    As a Ruby Nuby I've had a lot of use of JRuby combined with the work of Tor Norbye delivering the best Ruby IDE to date.

    The Netbeans Ruby download with integrated JRuby has been the most complete and easy to use start for someone like me, even though it's all been heavily beta up til now.

    I agree documentation could be of great use for Nubies,since I almost lost my source to open a generic JDBC link (with some nifty extensions of the JDBC connection class) and could not rebuild it because the forum threads I based it upon were lost.

    But otherwise its been a great ride, and indispensible for the stuff I do at work now.

    ReplyDelete
  5. Congratulations to the entire JRuby team. A great job indeed!

    Thank you for not "embracing and extending" Ruby and for being a good member of the community!

    ReplyDelete
  6. Well done everyone - thank you all, and thank you especially, Charles, for your even-handed support for other languages (dynamic or not) on the JVM.

    ReplyDelete
  7. P.S. Don't forget to put the news on the JRuby site!

    ReplyDelete
  8. Congrats! And thanks...

    ReplyDelete
  9. After you have installed rails,Your jruby's bin(eg:C:\jruby-1.0\bin) does not contain a file call rails.cmd
    your should create a file named rails.cmd.
    it contains the following contents:
    @jruby "C:/jruby-1.0/bin/rails" %*

    ReplyDelete
  10. I know this isn’t exactly JRuby, but any support/bug-fixes to facilitate the Eclipse plugin RDT working well with JRuby would be very appreciated.

    ReplyDelete
  11. Atif Khan: have you seen regular Ruby 1.0 ? I remember that 1.4 was 50x times slower at IO than it is now. JRuby 1.0 is in *much* better shape than MRI was not that long ago.

    ReplyDelete
  12. Should Ruby facets work with JRuby? I installed the gem, but doing:

    require 'facets' fails. Any suggestions?

    ReplyDelete