Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business
Javas 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 doesnt have the kind of track record with software development to make people think theyd be able to drag Java development currently treading water back onto dry land.
Oracle probably doesnt want Java to become a relic of an earlier age. But theyve got their work cut out for them.
Two wheels in the mud
The first and biggest is the way Sun has historically valued backwards compatibility over expanding Javas 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 tomorrows Java engines can use todays 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 Javas 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 theres C#, or Ruby, or Pythonor, for that matter, F# and Scala (one language which runs in the Java VM)? Especially if youre in a hurry, and those other languages better support the kind of rapid prototyping you want?
Its not that Java the language runs slow; its 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.
Heres 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 whats in front of them.
Its 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 Javas 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 codefaster 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, thats not the real bottleneck its the development cycle that Java forces on people who program in it. Projects like Apache Struts, for instance, might not be required if Javas internal development had been more cohesive and forward-thinking.
No criticism of Struts itself intendedjust that its a sign that whats 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 its also a sign of how little Java has evolved internally, and is in danger of being overtaken.
Oracles many Hobsons 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 Oracles own version of sameespecially 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 elses?
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 Oracles 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 Javas 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 isnt as if no models exist for a solution to this dilemma. Consider Microsofts .NET frameworks. Programs written for the 1.x framework arent compatible with those written for 2.x4.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, its 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 theres a strong chance wed 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 theyve built and all the things that may be built from that, too.
AND ONE MORE: Bjarne Stroustrup on Educating Software Developers