It may be almost a fortnight since the European Commission gave Oracle the go-ahead to acquire Sun Microsystems – and in that time we may have been bombarded with Oracle strategy webcasts – but speculation is still rife about the future of Java under Oracle Corp.
The latest ‘What’s Going To Happen Now?’ post, is by Serdar Yegulalp. He offers a fresh take on the Sun-Oracle-Java saga: Oracle probably doesn’t want to sabotage Java, but the company has its work cut out for it, if it truly wants to revitalise the language. The first part of his argument seems logical: Oracle has an extensive portfolio of Java applications and middleware; why would it want to effectively shoot itself in the foot? The second part is more complex. See, Yegulalp believes that Java has been haplessly treading water for years now, and a host of new programming languages are threatening to overtake it.
Let’s analyse his argument that Java is in danger of becoming a “relic of an earlier age.”
Firstly, Yegulalp blames Sun for prizing backwards compatibility over agility – both in terms of the language itself, andthe Java virtual machine.He claims that the sheer amount of Java code out there, has inhibited Sun’s development of the JVM. Distracted by making sure tomorrow’s Java engine is compatible with all the code around today, Sun has failed to move Java forward as a language. InYegulalp’s eyes, Java has lost favour with the ‘cutting-edge’ crew.
His advice for Oracle is simple and blunt: if making Java more agile comes at the cost of making it incompatible with earlier versions of itself, then this is a price they must be willing to pay.
“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?” Serdar Yegulalp.
He cites Java’s release schedule as proof that Java has stagnated. He does have a point: the last major Java update was Java 1.5 in September 2004. Java 1.6didn’t follow until two years later.
His argument is an interesting paradox. While it’s positive that Java has managed to maintain backwards compatibility, couldn’t that also be a sign of how little Java has evolved?And couldn’t newer, but faster-evolving programming languages, overtake it?
The solutions Yegulalp proposes are another paradox. Oracle could leave Java development in the hands of the Sun team. These are arguably the people who know Java best, but they are also responsible for the stagnation Yegulalp perceives as the root of the problem. Or, Oracle could really shake things up by demanding the next version of Java isn’t backwards compatible with previous versions. This isn’t unheard of in the world of programming languages: Microsoft’s .NET 1.x framework isn’t compatible with versions 2.x – 4.x. Finally, Yegulalp briefly proposes that another party should fork Java and develop it along a fresh track, but he dismisses this for fear of ending up with two incompatible versions of the same programming language.
Yegulalp is perhaps failing to take into account just how large the Java community is. Any new version of Java that lacked backwards compatibility, would affect countless developers, programmers and applications – unfortunately, it isn’t as simple as throwing a wildly updated, completely incompatible version of Java out there, and expecting everyone in the Java community to be happy starting from scratch.