What's Java's Future?: Page 2

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