Java 7.0 or Java.next?

A while back I was in a WCF master class hosted by Juval Lowy the MS software legend.

At the time Visual Studio 2008 was a pending release so most of the people were not yet familiar with the language changes in C#.

Juval took a little time to demonstrate the closures in C# to an impressed bunch of hardcore .Net programmers.

At the time I had been regularly writing ruby scripts and all I could think of when I saw the C# closures syntax is: "Man that looks terrible".

Ever since then, I can't help but get the feeling that if MS keeps chucking new features into C# it's not going to look pretty in a few releases.

But regardless of the impact of those features to the core C# language. MS has managed to - with the help of frameworks to make use of the features - create a whole lot of excitement around C# and .Net.

And in the IT industry, excitement around products is important unless you want to leak market share.

It unfortunately also been a couple of years since there's been any excitement around Java.

So what is a direction-less Java developer to do?

One of the options is the Java.next option: keep the JVM but use another language to run on top of it.

This has got quite a few advantages:

You can maintain the investment in Java while moving onto a new language.

You have an nice way to re-skill developers quickly.

You have a clean slate to start from when you design the language.

You can generate excitement while placating your very corporate customers.

As a developer you have a nice new toy to play with.

But before you can do this there are some requirements for corporate IT to accept this:

It must have vendor support, and by vendor support I mean the big guys; IBM, Oracle, Sun etc. etc.

It has to be very easy to to move from Java to Java.next. In fact ideally it should be a superset of Java but that might be pushing it :-).

It has to seamlessly interoperate with all the existing Java frameworks and libraries.

IDE support needs to be on par with Java.

JCP certification wouldn't hurt.

Another option is the Java 7.0 option: simply add new language features to Java to at least maintain parity with other languages. And that of course comes with the risk of messing up the language. Furthermore the changes need to added within a certain time line in order to not create the perception that the language is behind the times.

And then if that fails there is always the COBOL option: leave the language be and then for us developers; when the Java well runs dry we become COBOL style system maintainers or we simply dump the platform all together and start from scratch.