InfoQ

News

JVM Dynamic Language Shootout

Posted by Charles Humble on Mar 11, 2008 04:00 AM

Community
Java
Topics
Dynamic Languages
Tags
Jython,
Groovy,
JRuby

The JVM's ability to support multiple languages is a facet that has only relatively recently received much emphasis from Sun. The change reflects the changing tastes amongst the broad spectrum of developers who target the JVM, some of whom are looking to dynamic languages to speed up parts of their development process. Through the inclusion of JSR 223 (Scripting for the Java Platform) Sun began to formalise the change, ensuring that Java SE 6 is able to execute scripting language code written in dynamic languages, such as Ruby, Python, Groovy, or JavaScript.

Travis Jensen, a technical architect at SirsiDynix, recently carried out a comparison of Groovy, Jython and JRuby looking at the three languages' suitability as the language for web GUI development by an existing team of Java developers. His assessment compares the languages against five broad criteria:

1. The interaction between the dynamic language and Java. Jensen felt that Groovy came out strongest with Jython close behind:

"Because Groovy supports applying types, overriding class methods is clean. Instantiating a Groovy class is the same as instantiating a Java class."
He sees JRuby as presenting the most challenges:
"Going from Java to JRuby is not trivial, even though JRuby compiles down to a class. The compiler seems to be primarily for faster JRuby-to-JRuby interaction."

2. IDE support. SirsiDynix have standarised on JetBrains' IDEA which limits this part of the assessment - NetBeans' JRuby plugin, for example, was not covered. Jensen felt that the Groovy support in IDEA made Groovy a clear winner.

3. The learning curve for existing Java developers. Once again Groovy came out on top in Jensen's assessment:

"As a super-set of Java, it has a very straight-forward learning curve from Java. This is especially important around the APIs, since it uses the Java APIs directly. I honestly don't know whether the top-line productivity is as high as Python and Ruby, but I don't have any evidence that it is not. My gut feel is that the Python and Ruby libraries are optimized more towards their languages and will give a higher top-line."
He also argues that JRuby, despite being regarded as a highly productive language, offers the most challenges for a Java developer:
"Given its closer functional ties, the learning curve for Ruby is highest of the three. It also has the same issues around the Java and native libraries. I honestly think that, once the curve is passed, JRuby could offer the most productivity. I've been nothing but impressed by what I've read about Ruby in that regard."

4. Available web frameworks. A strong vote for JRuby:

"With its direct port of Rails, JRuby seems to come out on top here."
Jython is considered the weakest of the three:
"While CPython has some great options, Jython went nowhere for two years. The main cause of this is two-fold: Jython's current version is 2.2.1, whereas CPython is 2.5 and so many frameworks require compiled C code for performance."

5. Community support: Jensen feels that all three languages enjoy excellent community support but that Groovy has a slight edge:

"As the JVM is the only target for Groovy, the entire Groovy community is the JVM community. This obviously has some significant advantages for people looking to deploy on the JVM. It also seems to be picking up a lot of mind-share as the defacto 'Java Scripting Language', which is helping that community."

Of course any such assessment is to some extent subjective. It is also very much fixed in time - for example the increased activity around Jython, further bolstered by Sun's recent hiring of Frank Wierzbicki and Ted Leung to their team, should improve Jython's web framework status in future. Jensen's post does though provide a useful starting point and set of base criteria for architects or developers facing a similar decision.

7 comments

Reply

IMO by Shahzad Ismail Posted Mar 11, 2008 5:53 AM
Re: IMO by Matt Raible Posted Mar 11, 2008 9:52 AM
Rails on jruby is not a "port" by Michael Neale Posted Mar 11, 2008 7:53 AM
Sun Loves Jython Too by Zeev B Posted Mar 11, 2008 9:55 AM
Performance by Arash Bizhanzadeh Posted Mar 11, 2008 12:30 PM
Re: Performance by Jon Chase Posted Mar 11, 2008 1:11 PM
A few thoughts by Travis Jensen Posted Mar 20, 2008 12:28 PM
  1. Back to top

    IMO

    Mar 11, 2008 5:53 AM by Shahzad Ismail

    This is going to be the same sh*tty race as that of Java Web Frameworks at the launch of JSF. Meaning: there'll be no clear winners and all the consultants, in order to mint money, will conclude that each JVM lang is tailored for some specific need. IMO, the end result will be that there'll be no Java replacement lang and Java's life will be extended for further 10 years, as happened to classic struts framework. This will be highly detrimental for the whole damn software industry.

  2. Back to top

    Rails on jruby is not a "port"

    Mar 11, 2008 7:53 AM by Michael Neale

    It is just rails. And JRuby is just ruby.

  3. Back to top

    Re: IMO

    Mar 11, 2008 9:52 AM by Matt Raible

    Would the software industry be better off with a lack of choice?

  4. Back to top

    Sun Loves Jython Too

    Mar 11, 2008 9:55 AM by Zeev B

    Sun just hired two key developers that work on Python and Jython. You can read all about it at Tim Bray's blog. This will undoubtedly promote Jython's state and add proper Python/Jython support in NetBeans.
    As for Python web frameworks on the JVM see : http://www.infoq.com/news/2008/01/django_on_jython

  5. Back to top

    Performance

    Mar 11, 2008 12:30 PM by Arash Bizhanzadeh

    It is really interesting that the performance left out from the review, I think one of the most important factors in dynamic languages on JVM, is their performance. And AFAIK all of them sucks; but the question is which one sucks less?

  6. Back to top

    Re: Performance

    Mar 11, 2008 1:11 PM by Jon Chase

    I actually just did a micro-benchmark (completely unscientific) of some Java vs. Groovy code parsing XML. Conclusiong: Groovy was slower to execute but quicker to write:). http://www.juliesoft.com/blog/jon/index.php/2008/03/10/groovy-micro-benchmark/ Jon

  7. Back to top

    A few thoughts

    Mar 20, 2008 12:28 PM by Travis Jensen

    As the original author, I've been surprised by the reaction this post has gotten. To reply to some of the comments here: @Neale: Of course, you are right. I put it in the "port" category for the same reason I would many of the Python libraries for Jython. Many libraries in Ruby have components written in C that will not work in JRuby. @Zeev: Personally, this was the most exciting news I've heard this year. I love Python and am looking forward to it getting more love on the JVM. PyPy is also doing very interesting stuff with its ability to target the JVM. @Performance: I didn't do anything with performance because I didn't feel I would be able to extract any meaningful data. I did look through The Computer Language Benchmark Game, but I didn't feel that was representational of the web applications we'd be using it for. We also feel similar to the Python/Ruby communities' use of C, in that, if we see performance problems, we'll look at those as areas to re-write in Java.

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.