Is it time to retire Java?

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

DukeYesterday, the boss and I took a trip up to London for Sun’s UK Developer Update event at the Royal Geographical Society. There was a “keynote” by James Gosling, followed by presentations on JavaFX, Java EE 6 and details of what is likely to be in Java SE 7.

Now I should make it clear that until recently, I regarded myself as a C# and ActionScript programmer. I’m new to Java. This isn’t strictly true, as I used Java back in its Java 1.1 days, but its changed so much since those days (and I’d forgotten most of it anyway), that in practice I’m a Java newbie. As a result, I naturally judge Java against C# (and to a far lesser extent, against ActionScript).

C# owes its existence to Java. Languages prior to Java may have had garbage collection, reference types rather than pointers, bytecodes, just-in-time compilation etc, but Java bought these technologies into the mainstream. As it came after Java, C# was able to adopt all the good points of Java, and scrap the bad stuff (the getter and setter mess of Java is replaced with elegant properties for example). Whether it did this successfully or not is a matter of opinion of course. From my point of therefore, Java automatically deserves respect, but it doesn’t deserve automatic authority. People grow old and wise, but also grow set in their ways. Programming languages appear to do the same.

Despite its seniority, Java has some clear advantages over C#. Breaking to labels is a glaring omission in C#, which Java has. C# requires the use of the evil-incarnate “goto” to simulate breaking to labels. Also the XML mess that is documentation comments in C# is pure farce compared with the simple elegance of Javadoc. Java has a whole raft of deficiencies though, and the two biggest ones are the lack of anonymous functions (let alone closures) and the lack of properties. Both have been proposed for Java 7, but – according to Sun’s presentation yesterday – neither will now appear. On a lesser note, Java 7 will not support operator overloading either, so string comparisons will remain using the grossly messy .equals() method to compare string value. This is a minor issue in comparison with properties and closures.

Why are anonymous functions/ closures and properties such a big deal? Both can be worked around in Java. Properties are after all just a neater way of doing getters and setters and people have come up with bodge simulations of delegates for Java. The big deal is that these are basic features of modern languages. Even the somewhat “noddy” scripting language, ActionScript, manages to implement both. Every other JVM-based language that I know of – JRuby, Jython, Groovy and Scala – all support closures.

Java is old and is becoming set in its ways. Language developers always run into problems with balancing feature advancements with avoiding breaking legacy code and Java is no exception. Perhaps we need to accept that closures and properties will never come to Java as it is just too difficult to implement both neatly, without breaking backward compatibility in too big a way. If this is the case, then perhaps Java 7 should be the last version of Java and it ought to be retired and replaced with a younger, more adaptable language.Whether the growth in alternative JVM languages is a sign that people are already moving on from Java to newer languages is difficult to judge. JRuby, Jython, Groovy and Scala are all dynamic languages. Dynamic languages have seen a general resurgence in popularity recently. What is needed though is a static language replacement to Java. One that can seamlessly interact with legacy Java code, whilst supporting modern programming principles such as closures, operator overloading, properties etc, along with support for dynamic types (without being inherently dynamic), functional language principals such as currying and lambda expressions.

The more astute of you may spot where I’m heading here. Just as C# was born of Java, so perhaps we need a new version of Java, born of C#. Being a English tea addict, who is pretty indifferent to coffee, I propose (not very seriously) that we call it Lapsang. C# itself is starting to get old, and many of the new features – such as extension methods – have been implemented in an inelegant manner to avoid the backward compatibility issues that new keywords bring. So just as C# took Java’s good bits and added more of its own, Lapsang could take C#’s good bits, add a few new bits of its own (build concurrency into the core of the language for example) and give the JVM another 10+ years of life.

Java proberly is a dying language and it risks taking the JVM with it. If Sun (or IBM perhaps, if they buy Sun) bite the bullet and retire it as the prime JVM language, then there is no reason why the JVM cannot thrive and grow for many more years.