The Next Big JVM Language

A Conversation with Stephen Colebourne

by Bill Venners
September 23, 2010

Summary
At the JavaOne 2010 conference in San Francisco, Stephen Colebourne, member of technical staff at OpenGamma and project lead of the Joda Time open source API, gave a talk entitled "The Next Big JVM Language." In this interview, he reveals what he thinks the next big language should be.

Bill Venners: What do you think the next big JVM language will be?

Stephen Colebourne: First I think it is useful to think about what we've learned from Java. What did Java get wrong? What did Java get right? Where are we going in the future? In that context, are any of the main alternative languages---Groovy, Scala, Clojure, Fantom---likely candidates for the next big language on the JVM?

So what have we learned from Java? Well, if we had to do it over again, we'd avoid a whole slew of things like exposed primitives, exposed arrays, and checked exceptions. We wouldn't put these into the language.

Then there are the things we might do in new languages going forward. A better solution on modularity is obviously one that we are talking about. But the modules going into Java, the ones we're talking about so far, are not really as far as we could go. We could actually no long compile to class files but only compile to modules. The compiler would never ever output class files, only modules. We could add to the module system the ability for it to work out, sometimes, whether version 1.1 is compatible with version 1.2. A module system could examine the bytecode of all the methods you're actually using and conclude that because the bytecode of all the methods you're using hasn't changed, 1.1 and 1.2 are therefore exactly compatible for you. There's a lot more that can be done, but sometimes these things require a little bit of a rethink.

Now, what about the four biggest contender languages we have out there: Groovy, Scala, Clojure, and Fantom?

Clojure is Lisp syntax. It's so different to Java developers that it seems unlikely it will be the next big language, though it's got some great ideas.

Groovy has a distinct niche with its ability to fill in Java's need for a scripting language. Groovy will have a role in build scripts, particularly with Gradle. It will perhaps have an important role in web apps as well.

The other two languages, Scala and Fantom, are similar in that they are statically typed, but they take the type system in opposite directions. Scala has gone down the route of adding to the type system, even to the degree of, if I understand correctly, that you can make a Turing-complete language within the generics of Scala. Fantom goes in the other direction and weakens the type system. In contrasting these two languages, I came to the conclusion that Scala is just too complicated. It's added too much stuff. It gives you too much rope to hang yourself with. That's the concern I have with Scala. Whereas Fantom has a great set of features and is very easy to learn, very easy to pick up---but perhaps a weakening of the type system and a couple of extra classes is just not quite enough to make it the next big language.

So I ultimately came back to the concept of---what if Java was the next big language? Well, the problem is that the more we add the more difficult it gets to add stuff because the language is already full. But maybe rather than us going out there and saying to Oracle, "Let's add closures to the language; let's add properties to the language," what if we made a backwardly incompatible version of Java? What if we had a tool that could convert from JDKn+1 to JDKn+2, if you like, to convert between the two versions of Java, forwards and backwards. So there's your backward compatibility story: you can convert between the two of them. What if that was JDK8? What if instead of doing closures and modules in a hacky way in JDK8, what if we actually delayed the release by a year and made it backwards incompatible, so we could do closures properly and properties properly and a few other things. There are quite a few other things that could be fitted in as well. And actually remove stuff too: remove checked exceptions, remove the ability for a reference to be null unless it is a Nullable type, etc. Doing a few things like that could make a big difference. What if we went down that route?

Resources

The Clojure language is at:
http://clojure.org

The Groovy language is at:
http://groovy.codehaus.org/

The Scala language is at:
http://www.scala-lang.org/

The Fantom language is at:
http://fantom.org/

About Stephen Colebourne

Stephen Colebourne is a Sun Java Champion and Co-spec lead, JSR-310, Date and Time API Project lead, Joda-Time. Stephen is a regular contributor to the Java language change debate, a conference speaker and a member of the technical staff at OpenGamma. http://www.opengamma.com/

Talk back!

Have an opinion? Readers have already posted 62 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.