David Herron's Blog

Dynamic language in Java or otherwise, specifically Groovy and Grails

The Java Posse gang just posted Interview with Graeme Rocher of Grails which serves as a great introduction and/or overview of both Groovy and Grails (a.k.a. Groovy on Rails). I've used Groovy just a teensy bit, so I won't go into the language at all. If you want to look further, there is groovy and grails home pages chock full of information.

What I want to do is contrast the state of different dynamic languages.

There are a wide set of the dynamic languages ... and many prognosticators have proclaimed Java would die due to the growth in popularity for these languages. But what's interesting in this story is the various dynamic languages that ride on top of Java, as Groovy does. For a language implementer to ride on top of Java, that gives a strategic advantage the other languages do not have.

Namely ... the rich swath of libraries existing for Java, and the infrastructure such as Java EE and web services that already exist and can be reused by the language author.

I should mention again -- as I've written before -- given the scripting language support in Mustang (the JSR223 javax.script packages), it should become easier for new languages to ride on top of Java.

In any case, in the interview Graeme Rocher makes a good case for the strategic advantage I'm talking about. e.g. in the Groovy/Grails system, they can use the Hibernate persistence engine, and they don't have to invent their own. e.g. they've made sure they can run inside a Java EE container, giving them all the deployability, infrastructure, web and other services, etc, all at a relatively small cost to them.

In comparison the other languages have to reinvent the world in order to bring some feature or infrastructure item into their environment.

Comments

• >>In comparison the other languages have to reinvent the world in order to bring some feature or infrastructure item into their environment.

  Well...it is non-trivial work to link existing C or native libraries into JVM-based languages as extensions. You cannot take native-binary extensions to Ruby and use them with JRuby, whereas Ruby can always be extended by using native libraries that already exist, are tested, well-known, etc. In Java we just are fortunate in that many different problems have been re-addressed in the Java language itself. But when the libraries don't exist in Java I think it's frustrating for developers who would like to be able to quickly wrap a native implementation and use it from Java, the way they do from non-JVM "dynamic" languages.

  In theory, the idea of multiple languages being used in the JVM sounds appealing. In reality--please take a poll and see how many JVM users actually use these languages (other than Java), and to what ends. My sense is this use is relatively small within the community of JVM users.

  I use Java all the time and am a big supporter of it, as well as of Sun's engineering work--but it's important not to get carried away by the marketing. Groovy promoters (and those of other JVM languages) should maybe quiet down until their language really make inroads somewhere, e.g. let the scripting do the talking.

  Cheers
  Patrick

  Posted by: pdoubleya on May 02, 2006 at 12:56 AM

This work is licensed under a Creative Commons License.