Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Creating a new JVM language

Creating a new JVM language

This item in japanese

Last week's announcement of Ceylon brought the focus on JVM-based languages. Ceylon isn' the first JVM based language; nor will it be the last. But the general case of JVM based languages was proposed in Bruce Tate's Beyond Java in 2005, and has been a focus of the Java platform for a significant time, as the list of JVM languages on Wikipedia can attest to. Bruce noted that community is the key to success:

It will need to establish a significant community. You won't see broad adoption unless the adopter can achieve relative safety.

Gavin noted that Ceylon would need a community effort, and has presented a clarification on one of the points he made (regarding Java as a mathematical language). Given the syntax of Java is based on C (and Algol and friends) the comparison was always a bit misleading, though he is now expecting an apology:

Now waiting for a flood of apologies from all the folks who've called me ignorant over this. I'm looking especially at you, Scala fans ;-)

Lockster declared Ceylon, interesting for the wrong reasons. What perhaps is interesting is the fact that there is a perceived need by RedHat for a new language. This might be due to problems with the existing evolution of the Java language (or lack thereof) – by creating a separate language, it may be possible to escape the Java trap whilst still using the performance of the JVM and the invokedynamic bytecode.

One key issue with the Ceylon proposal is the current lack of IDE (or for that matter, compiler or any other toolchain). Any language needs community support; and community support needs freely available (and powerful) tools. Scala has support in an Eclipse IDE, although JetBrains also supports Scala inside IntelliJ. Sven Efftinge also wrote a list of ToDos when considering developing a new JVM language:

  • Don't make unimportant changes
  • Static typing
  • Don't touch generics
  • Use type inference
  • Care about tool support
  • Closures
  • Get rid of old unused concepts

Sven also promotes Eclipse Xtext as a way of creating DSLs with integrated IDE support. This is a set of Eclipse tools which can be used to create a grammar, and then from it, a set of IDE plugins to allow you to edit and view scripts written in that grammar.

Interestingly, even small changes in a language can have significant impacts. Part of the reason why the development of the Java language has been slow is due to the concerns relating to backward compatibility. This is true not just of the libraries but also the language syntax itself. Last year, Brian Goetz published Quantitative language design on the choices in changes to the Java language. In this specific case, the availability of several million lines of Java code allowed choices of implementation (in this case, the type inference for the diamond operator) as to their effects on an existing codebase. For Java, the existing codebase is already present – but for new languages, that isn't necessarily the case.

There are a number of languages which have been ported to run on top of a JVM runtime, including Python (Jython), Ruby (JRuby), Lisp (Clojure) and even Tcl (JTcl). These all exhibit the same behaviour as the existing programming languages but run on top of a JVM based platform. In most cases, these run faster than their native counterparts; but such changes aren't always possible (e.g. see the last flight of the unladen swallow).

Then there are new languages, like Scala, Gosu and Mirah. These may be compatible (to some extent) with the Java platform but may provide similar or significantly different syntax to Java in order to operate. Ceylon is competing with these more than the traditional ports, since the ports are aimed at users of the existing languages elsewhere.

What's clear is that the JVM platform has become the location of choice for experimental languages, whether intermediately translated to Java for compilation, or generating bytecode on the fly. To date, none of the newly generated languages have risen to become the de-facto Java alternate (though there are many Scala libraries now available) – but there is room for growth in all languages, and a rising tide raises all boats.

The key question is how to grow community to the point where the language becomes self-sustaining. To do this, a language must have great IDE support (and preferably, in more than just one IDE) as well as exemplary frameworks (e.g. Ruby has Rails, Scala has Lift) which help drive adoption. Creating a new JVM based language starts at the grammar file, but it's only the start of a long process.

Rate this Article