Time to Put the Brakes on Java?
Java: Keep up or fall behind
But it arguably wasn't until the emergence of Java that developers had to worry about actual version numbers of their language platform, the way they would for a word processor or other desktop application. Was Swing support reason enough to upgrade to J2SE 1.2? Was the J2SE 1.3 JVM stable enough? Did we need the standard regular expressions and XML parser from J2SE 1.4, or should we stick with a third-party class library?
None of these were trivial questions. Performance issues, in particular, have dogged the Java platform from the beginning. However attractive a new feature might look in specification, there's no way to tell how it will perform in real-world use cases until the JDK is actually in hand. Implementation matters.
And that's the insidious thing about adding new features to a language specification: It implies that you're supposed to use them. If a certain new feature is buggy today, should developers put off work on a new project until a more stable point version of the JDK arrives? What does a new Java specification mean for an existing code base that doesn't use the new features? Is the best practice to only design new components using the latest language features, all the while hoping that the new compiler and JVM will maintain support for the earlier code? Should the old code be rewritten? Or should developers avoid using the new standards for existing projects, and risk having their code bases slip ever further into the "legacy" shadows?
The more rapidly a language specification changes, the more developers must forever play catch-up, like it or not. For most of Java's history, a single company has been the predominant force driving the changes -- and that still seems uncomfortably true today.
Whose voices are heard?
Tim Peierls resigned from the JCP EC to voice his disappointment with the recent vote, although not because he doesn't think there's any need for Java to move forward. On the contrary, he feels the addition of lambda expressions (also known as closures) and various other changes to the language are important improvements, and he remains involved in the technical discussions for those efforts. (The ASF later resigned as well.)
What troubles Peierls is what he sees as intense "commercial" pressure to evolve the language, rather than a genuine response to the needs of the Java community. "The big boys want big apparent forward motion because it means more stuff to sell, more contracts and control," he writes. "I'm reasonably certain that the bulk of the yes votes were due to contractual obligations rather than strongly held principles ... it finally made it clear to me that my vote was worthless."
Peierls's comments echo those of Doug Lea, who announced in October that he would no longer seek a seat on the JCP EC. "Rather than fixing rules or ceasing violations, Oracle now promises to simply disregard them," Lea wrote in an open letter to the Java community. "If they indeed act as they have promised, then the JCP can never again become more than an approval body for Oracle-backed initiatives."
If Lea and Pereils are correct, and the JCP has become nothing more than a rubber stamp for Oracle's product strategy, then maybe it really is time to step back from active development of the Java specifications. The Java platform is far too important to developers and industry to be driven by the profit motives of Oracle and a few large partner companies. Rather than charging ahead blindly and pulling the Java community along with it, Oracle should slow down and get the JCP back on track.
This article, Is it time to put the brakes on Java?, originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com."
Time to Put the Brakes on Java?