Monthly Archives: September 2011

The First Class Languages of the JVM

The announcement of Kotlin, a JVM based language from JetBrains, drew quite a bit of attention. Firstly, when the makers of the best Java IDE in the world announce their own language you pay attention and secondly, it wasn’t that long ago that to the average developer the JVM meant Java and only Java and the rise of other languages on the JVM was some sort of bizzaro dream. While Jython (1997) and JRuby (2001) predate Groovy (2003-ish) it was the latter that really seemed to show everyone that something other than Java could be run on the JVM. The fact that Groovy is a super-set of the Java language meant that the barrier to adoption was very low and developers seemed to lap it up. This encouraged adoption but the push from the likes of SpringSource and the rise of Grails piggy-backing on Ruby on Rails’ success seemed to drive its acceptance. Even the fairly poor tooling support seemed to not be too much of a barrier as many companies started using it and benefiting from something other than Java.

Kotlin’s emergence does raise an interesting question;¬† from the developers perspective, what are the first class languages for the JVM right now and who will be in that list in 3-5 years time, and more importantly why?

Of all the languages that can run on the JVM, I would say that the the list of the premier league languages can be restricted to the following: Java (natch), JRuby, Jython, Clojure, Groovy and Scala (Kotlin is interesting but until Jetbrains write IntelliJ in it I won’t take it too seriously). Of these 6 languages it also interesting to note that only 2, Java and Scala, are statically typed and 3 are versions of a previous language: JRuby (Ruby somewhat obviously!), Jython (Python) and Clojure (Lisp dialect).

Scala has been seen as the language most likely to supplant Java but its complexity (especially the multiple different ways you can write and do the same thing) has held it back. It’s functional nature has also meant that many Java/OOP developers freeze in the headlights when Scala code switches to this mode. Scala is awesomely powerful and the likes of Twitter, Foursquare and GridGain use it in missions critical systems but it currently lacks that magic sauce that makes it accessible to mere mortal developers.

The same goes for Clojure. Lisp and its dialects has never really found a massive following in the commercial environment despite being held in high regard elsewhere. Even with the increasing interest in functional languages it still does not have the momentum required to be wildly successful but it is still early days for Clojure.

Ruby (1995) and Python (1991) are not new languages. Since there appear to be about 3.5 times as many jobs currently being advertised for Java than for Ruby and Python combined¬† it appears unlikely that even JVM friendly versions of them will be the next big thing. Don’t get me wrong, Jython and JRuby are great languages but they are hardly new kids on the block.

Groovy‘s similarity to Java makes it’s adoption very easy but its performance historically has not not great. I’m being polite since it’s actually sucked pretty hard.. Whether this is still an issue with the inclusion of JSR 292 in JDK 7(Supporting Dynamically Typed Languages on the Java Platform) remains to be seen but the dynamic typing does not tend to be as accepted as static typing in the enterprise context. I know this is a contentious point but Nuxeo moved from Python to Java and Twitter’s adoption of Scala indicate that context is important: if you have a large-scale performance orientated application, static typing is your friend and this is where Java is used heavily. Should you really like Groovy’s syntax and want static typing, Groovy++ offers what you need but again, does it offer enough to replace Java. I’d have to say no.

So what will be the language that retires Java? I have no idea and I don’t think that anybody else does either but I suspect that the language that finally does has not been written yet. It appears that the usage of Scala, Groovy, Clojure, Jython and JRuby will increase in the next few years but none of them seem to be the Java killer. The increasing adoption of languages with better type systems than Java seems assured for the the next few years but none of them seem to offer the combination of features to supplant Java.

If I had to back one of the runners, Scala appears to be the one with the most momentum as well as arguably the most power and functionality. The perception of complexity can be dealt with by education and training so it may well grow to be a contender to Java but given the learning curve, it is hard to see it ever replacing it. Who knows, it may be a language from an IDE company that finally sees Java developers cry “The King is dead, long live the King.”

Closure Syntax in Java 8

The expert group for Java 8 have announced the syntax for closures. Thankfully, they have chosen the sane route of choosing a similar syntax to Scala and C#. Quoting from

The decision to choose this syntax was twofold:
– The syntax scores “pretty well” on most subjective measures (though
has cases where it looks bad, just like all the others do). In
particular, it does well with “small” lambdas that are used as method
arguments (a common case), and also does well with large
(multi-statement) lambdas.

– Despite extensive searching, there was no clear winner among the
alternatives (each form had some good aspects and some really not very
good aspects, and there was no form that was clearly better than the
others). So, we felt that it was better to choose something that has
already been shown to work well in the two languages that are most like
Java — C# and Scala — rather than to invent something new.

There is still some argument around fat versus thin arrow (surely a huge issue!) but for those of us that program in multiple languages it’s nice that they haven’t fallen for the “not invented here syndrome” and have chosen something that doesn’t require us to perform massive context switches when using something different.