What's Java's Future?

Java’s development as a language has been effectively stalled for years now. Other languages, better suited to the kind of rapid-fire development pace needed today, are eclipsing it. Worse, Oracle doesn’t have the kind of track record with software development to make people think they’d be able to drag Java development – currently treading water – back onto dry land.

Oracle probably doesn’t want Java to become a relic of an earlier age. But they’ve got their work cut out for them.

Two wheels in the mud

There are two major reasons Java has become increasingly hidebound and reactionary.

The first and biggest is the way Sun has historically valued backwards compatibility over expanding Java’s capacity and flexibility, except where the latter can be accomplished by things added on outside the language itself. The second is how development on Java the language has stagnated as opposed to development on the environment that the language runs in – the Java virtual machine.

The first problem, backwards compatibility over agility, stems from good intentions. The amount of Java code out there is more than incentive enough to make sure tomorrow’s Java engines can use today’s code. But my opinion is that Sun has for too long valued backwards compatibility over moving Java forward as a language – so much so that Java’s prestige as a language is being eroded.

The things that could make Java a better and more agile language might well come at the cost of making it compatible with earlier editions of itself. Lack of agility means the language, in time, falls from favor with people who do cutting-edge work.

If you have your pick of languages (and programmers), why go with Java when there’s C#, or Ruby, or Python—or, for that matter, F# and Scala (one language which runs in the Java VM)? Especially if you’re in a hurry, and those other languages better support the kind of rapid prototyping you want?

It’s not that Java the language runs slow; it’s that development in Java is the real bottleneck, because other languages are learning to avoid those issues.

For proof that work on Java has slowed to a crawl, look no further than the release schedule. The last time Java had a major update was in September 2004, with the release of Java 1.5. 1.6, which came two years later, was more like a 1.5.1 edition. Java 1.7 was supposed to have been out late last year; the newest projection is sometime late this year.

Here’s another fun experiment: take an existing Java programmer and give him an app written in 2003 or so – or, better yet, take a circa-2003 Java hacker and show him something written today in the language. Odds are both of them will have no trouble understanding what’s in front of them.

It’s harder to say the same thing for a C# programmer. The vintage 2003 guy would be scratching his head at innovations like LINQ and WPF. Baffling as those things may be to a newcomer, they make it possible to do more advanced things that much faster.

The other reason Java’s stagnated as a language is because the aforementioned runtime engine for Java has been garnering more attention than the language itself from the people that matter. The JRE has become a way to not simply compile and run Java, but many other languages. Consider JRuby, a JRE port of Ruby, which produces amazingly fast code—faster than the native Ruby system itself.

Much emphasis was put on the JRE as, again, a way to make Java run that much faster. But more often, that’s not the real bottleneck – it’s the development cycle that Java forces on people who program in it. Projects like Apache Struts, for instance, might not be required if Java’s internal development had been more cohesive and forward-thinking.

No criticism of Struts itself intended—just that it’s a sign that what’s weak within Java has time and again been propped up, pun intended, by third parties.

Spin all this positively and you have a way to say Java has maintained excellent backwards compatibility. But it’s also a sign of how little Java has evolved internally, and is in danger of being overtaken.

Next Page: Java and Oracle’s many Hobson’s choices