
See all our reports

The Adventurous Developer’s Guide to JVM Languages


Why do we need so many JVM languages?

It’s 2013 and you have over 50 JVM languages to choose from for your next project. But even if you can name more than a dozen or so, are you going to pick a new one for your next project?

Nowadays it’s easier than ever to create a new language with support from tooling like Xtext and ANTLR. Many new JVM languages have emerged as a result of limitations and disadvantages, either for creative individual coders or the masses, perceived in existing JVM languages, historically Java.

New JVM language developers feel as though their work is a result of existing languages either providing too limited functionality for their needs or too much functionality, leading to overweight or complex languages. Software development spans across such a wide range of appliances, so the usefulness of a language is frequently determined based on how relevant it is to a specific task, or how generic it can be across a larger area. All of which leads to development libraries and frameworks.


James Gosling,
Creator of the Java Programming Language(2011, TheServerSide)

With so many languages already around, will the language graveyard become overpopulated? A danger exists that with so much choice in the market, many languages will just not last because they don’t get enough attention or contribution in the face of less and less community resources.

The industry, however, survives based on innovating and creating, which very often comes from a project starting from scratch, dropping existing constraints and designs, and going with a blank slate.

There is a fine line that we will naturally dance around here: between helping to build existing languages and frameworks–helping to create the community backing it needs to survive and perhaps become the next Java- -and the creation of new ideas, structures and paradigms which ultimately will make their way into existing languages.

This RebelLabs report takes a look at Java 8, Scala, Kotlin, Ceylon, Xtend, Groovy, Clojure and Fantom. But wait–with so many JVM languages to choose from, how did we settle on these eight only?

The team over here at RebelLabs has been discussing for 6 months how to do a report like this, and which languages to choose. Basically, we wanted to give something for everyone: Java is an incredibly well-known, widespread language, but Java 8 has new things that we wanted to explore. Groovy, Scala and Clojure have found their niches in the market and are becoming more popular, and languages like Ceylon, Kotlin, Xtend and Fantom are relatively new on our radars, gaining credibility and in need of some investigation.

Our goal is to give an understanding of where each language came from, how they evolved and where they may be going. So in this report you will see us express our first impressions of the languages, including the features which rocked and the features which… well, didn’t rock!

You’ll be able to see our source code of a basic HTTP Server example in all implementations, with links to GitHub so you can play along with us.

A little History

In the beginning, there was only Java, and it used to be the only programming language for the JVM. But the industry realized the need, and potential, for more options on the JVM quite early on. The first alternatives were targeting the scripting domain: Jython, a Python implementation for the JVM, as well as Rhino and JavaScript engines for the JVM, appeared in 1997, followed by BeanShell in 2000 and JRuby in 2001.

Scripting facilities were in high demand at that time due to the need for dynamic customization of applications. Nowadays, application servers like Oracle WebLogic and IBM WebSphere utilize Jython scripts for automation and Rhino was bundled with Java 6 to make JavaScript a first-class citizen on the JVM.

jvm languages timeline

However, scripting facilities weren’t the one and only factor for the growth of alternative programming languages on the JVM. Due to Java backwards-compatibility principles, alternative programming languages started to appear, offering some innovative features that weren’t provided by Java or its standard libraries. Scala and Groovy were the first successful projects to offer something beyond Java.

An interesting observation can be made: most of the recent programming languages utilize static typing. Developers who use Scala, Ceylon, Xtend, Kotlin and Java itself rely on the compiler that verifies target types at compile time. Fantom tries to find a golden middle between static and dynamic typing, and Groovy, although initially a dynamic language, now added compile time static type checking in its 2.0 release in 2012. Clojure, the flavor of Lisp, is still the only reasonably-popular JVM programming language that sticks to dynamic typing, which some developers working on large teams in enterprise organizations consider to be a disadvantage.

The trend for new programming languages running on the JVM is changing from dynamic scripting languages for application customization towards statically-typed general purpose languages for application development.

Java is still the most used programming language for JVM and with its upcoming Java 8 release it tries to keep up with the modern trends in syntax esthetics as well as with the requirements for multi-core programming.


  • http://wordsanddeeds.org/blog Jason Rogers

    Two observations…

    “Scala and Groovy were the first successful projects to offer something beyond Java” — you miss JRuby. I think it was a viable, successful project before Scala or Groovy

    “Clojure, the flavor of Lisp, is still the only reasonably-popular JVM programming language that sticks to dynamic typing” — again, you miss JRuby. It is very popular and sticks to dynamic typing.