What's Java's Future?

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

With all of the screaming about the fate of MySQL under Oracle’s thumb, there’s been far less discussion about a much more important software project now under their control: Java.

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

Oracle’s many Hobson’s choices

Oracle made it clear that Java was one of their prize acquisitions when they bought Sun. They were proud to have it, and it made sense in terms of the stack they were creating: Sun hardware and OSes, Java middleware, and Oracle databases.

But that means they need to kick internal Java development up that many more notches. Also, Oracle needs to be realistic about Java being used by other parties apart from their stack: few people are going to ditch an existing solution with Java to use Oracle’s own version of same—especially if they already have a custom or pre-integrated solution that uses Java.

So what could Oracle do to spur Java development – both for their sake and everyone else’s?

First, Oracle could do nothing on its own. They could leave the whole business of Java to the existing teams at Sun, and maybe provide no more guidance than would be needed to better integrate Java with Oracle’s own products.

The upside of such an approach: Java remains in the hands of the people who know it best.

The downside: Those people may well also be responsible for Java’s stagnation, and so the new regime would simply recapitulate the sins of the old.

Second, Oracle could break ranks with Java developers and unilaterally demand that the next version of Java not be backwards compatible. The road ahead would be cleared, but at what cost?

It isn’t as if no models exist for a solution to this dilemma. Consider Microsoft’s .NET frameworks. Programs written for the 1.x framework aren’t compatible with those written for 2.x—4.x. But Microsoft partly ameliorated this by allowing runtimes for all editions of .NET to exist side by side. The total cost to end users amounted to some initial annoyance at having to deploy each framework.
A bit of a hassle at first; today, it’s scarcely a blip on the radar of .NET issues.

The same thing could be done for Java: package side-by-side runtimes, with a minor tradeoff in disk space and maybe initial app startup time. And odds are Oracle can take the heat for a move like this than better the old Sun could.

Another, outsider possibility, is that Java could be forked by another party and developed along a different track – one where fresh blood is brought in. Red Hat (a major contributor to Java EE 6), for instance. But forking in any form brings with it at least as many new problems as it does solutions to the old ones. It also means there’s a strong chance we’d end up with two mutually incompatible versions of Java – or at least an old breed and a new one, with all of the issues that come from such things developing in parallel.

Whatever happens, Oracle has to decide fast, and make their decisions stick. Not just for the Java community at large, but for the future growth of the stack they’ve built – and all the things that may be built from that, too.

ALSO SEE: The ‘Anti-Java’ Professor and the Jobless Programmers

AND: The TIOBE List Director vs. the ‘Anti-Java’ Professor

AND ONE MORE: Bjarne Stroustrup on Educating Software Developers