JRuby: What happens next? Will it affect Groovy/Grails?

Posted by Scott Delap on Sep 11, 2006 06:35 PM

Community

Java,

Ruby

Topics

Dynamic Languages

Tags

Groovy ,

JRuby ,

Grails

With Sun's supporting JRuby by adding two of its committers to its payroll, the next question is where does this leave other JVM language alternatives such as Groovy? Since the announcement both Charles Nutter and Thomas Enebo (the two new hires) as well as Tim Bray of Sun have both provided follow up answers to questions about what will happen next. In summary:

• Improving JRuby is their primary priority but...
  
• They also have a mandate to improve the Ruby tool landscape
  
• Sun will not control the project and licensing will not change.
  
• While, as Sun employees, they have a major interest in ensuring Netbeans support, JRuby will not discriminate between users or other tools such as RadRails which is based on Eclipse.
  
• Neither will be moving to sunny California ... instead opting for the lovely Minneapolis winters.
  
• The JRuby hiring has nothing to do with the recent IronPython 1.0 announcement for all you conspiracy theorists.
  
• Sun is still actively interested in supporting non-Java technologies on its systems and OS platforms.
  
• Sun is also still interested in other languages on the JVM such as Visual Basic and JavaScript.

Charles Nutter responded to the question of JRuby vs Groovy, Rails vs Grails on OnJava.com.

...trying to build a house with a hammer. The very notion is absurd. It’s just as absurd to say there should be one true dynlang on the JVM, be it Groovy or Ruby or Python or anything else. We are craftsmen, if not artists, and no craftsman will claim that a single tool can do everything...After fighting for alternative languages to curry favor with the development community, does it make sense to claim our language is the one true choice? And the same question with alternative web frameworks?

Tim Bray's recent blog entry highlights that the hiring was not about JRuby vs other languages. It was simply a response to the great work Charles and Thomas have been doing:

...First, these guys took an existing semi-dormant project and brought it alive, unprompted, unpaid, applying energy and engineering skills to the problem in large quantities. Second, they were working in a field that has a large and growing community; in this case because of the hype around Rails. Third, they were vocal and outward-facing and articulate, getting on the stage at Java One and lots of other events with impressive demos. Fourth, they shipped code that worked pretty well and improved qualitatively from release to release. I’m not sure it’s Sun’s role to pick and choose the winners and losers in this space, or anoint leaders; what would make us think we’re that smart? But when obvious leadership emerges in an interesting space, why wouldn’t we get behind it?

Finally Graeme Rocher, Grails project lead, comments in respect to Groovy/Grails.

First, I must express my congratulations to the JRuby guys at the news that they have been hired to work fulltime on JRuby by Sun. This is great news as we may finally see a high quality Ruby VM for Java ... What do I personally think it means to Groovy? Well not a great deal actually. Groovy already has tight integration with Java and compiles to byte code hence its performance and integration is excellent ... If JRuby gets Rails working on Java then it is just another choice amongst such great frameworks like WebWork, Cocoon, Rife and Grails.

1. Back to top

   Groovy vs. Ruby

   Sep 11, 2006 8:51 PM by Tom Nichols

   I'll reiterate what I've said at ONJava -- If you're a Ruby user, this is good news hands down. It will probably allow you to interact with Java when you need. If you're a Java user/enterprise, have a huge existing Java codebase and run on the JVM 95% of your time, consider Groovy. Sure JRuby will give you a strong dynamic language and the Ruby codebase, but I fear there will be 'seams' whereever Ruby and Java meet. Imagine having to always apply patches when you want to use your favorite Ruby libraries in JRuby. How long until we see JRuby code that explicitly depends on Java libs and doesn't work in native Ruby? Will JRuby always be playing catch-up with the native version? This is the way porting usually goes. Personally, I'd prefer a dynamic language that is built from the ground up to take full advantage of the JVM, its codebase and well-established frameworks (Spring, Acegi, Lucene, and all of those EJBs you created!!) Not to mention that any Grails app runs in a standard Java servlet container/ app server. If you want 'portability,' isn't that what the VM was meant to do? Personally, I'm going to pick a platform (be it Java, .NET, Ruby or Python), _then_ choose my implementation language(s) that best allow me to leverage that platform. Sure, Groovy and Grails are still a bit immature and the documentation needs work, but otherwise it's no less capable. I don't think there's anything in Ruby that you can't do just as easily in Groovy. Side-by-side, I think Groovy is easier to read (and hence maintain). Regardless, if your bread and butter is Java, why deal with incompatibility, conflicting paradigms and duplicated libraries when you can have something that is meant to work with Java? Pick what works best. Of course -- if you have Ruby code that you need to interact with Java, by all means that's what JRuby is meant for. It's a bridge between two worlds. But that bridge will always be less stable than the solid ground on either side. Groovy will always remain squarely on the solid Java foundation. JRuby is your choice if you want to use Ruby. Groovy is your choice if you're a Java user. I'm confident that Groovy and Grails have nothing but good things ahead of them. Thanks for reading. -Tom

   Reply

2. Back to top

   Re: Groovy vs. Ruby

   Sep 11, 2006 11:45 PM by Steve Zara

   I'm not sure I understand what your point is about JRuby code using Java libraries. JRuby code which depends on Java libraries is pretty much guaranteed, as surely that is one of the main uses of such a language on the JVM - as scripting language which can use Java classes and libraries. Unless Ruby on the JVM has signficant advantages over 'native' Ruby (in future, better performance could be one), I can't see that many pure Ruby developers using JRuby, and aiming to use exactly the same code on or off the JVM. Also, I am not sure how much on-going catching up with 'native' Ruby will need to be done. Ruby is a relatively stable language, and even the changes in Ruby 2.0 don't seem to be major. It is not that much of a moving target. I agree strongly with your opinions on Groovy and Grails; I suspect Groovy will get much more attention when 1.0 is released, and the GORM persistence used in Grails is, in my view, a far better way of doing things than Rails' ActiveRecord. When GORM gets JPA support, it will be a very attractive framework indeed.

   Reply

• Older >