Is it time to put the brakes on Java?

It looks like it's full steam ahead for Java. The next two versions of the Java Standard Edition, Java SE 7 and 8, were officially given the green light in a vote by the Java Community Process executive committee (JCP EC) this week. In addition, two other proposed specifications were approved, paving the way to add further new features to the Java language and class libraries.

But not everyone is pleased with the outcome. The Apache Software Foundation (ASF) has long contended that development of Java cannot go forward until Oracle addresses its licensing terms, which the ASF argues are hostile to open source implementations of the Java platform. That's a breach of Oracle's obligations to maintain Java as a free and open standard, the ASF says, per the terms of the Java Specification Participation Agreement.

[ Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. | Follow the latest in Java technology with our JavaWorld Enterprise Java newsletter. ]

Several other JCP EC members -- including Crédit Suisse, the Eclipse Foundation, Google, IBM, and SAP -- concurred with the ASF's complaints during the recent vote. Although only Google went as far as to cast a no vote, the others amended their votes with comments to the effect that their approval was based on the technical merits of the specs only and that they were similarly concerned with the ongoing licensing debate.

To independent JCP EC member Tim Peierls, the fact that so many members approved the specifications when such important legal issues remained unresolved was deeply troubling. "To my own surprise, I'm coming to believe something heretical: that it actually is not all that crucial for Java to move forward," Peierls wrote in a recent blog post. "We are whipped to a frenzy with messages (both subliminal and explicit) that Java is falling behind, losing mind share, being lapped by C#, anything to sell the idea that more is desperately needed, when in fact most folks could make do with a lot less."

Is this standard really necessary?

Peierls has a point. The idea that programming languages should progress at a steady and rapid rate, continually gaining new features and adapting their syntax to fit them, is a relatively new one. By comparison, the languages of past eras evolved much more slowly.

Take C, for example. Brian Kernighan and Dennis Ritchie published "The C Programming Language," an informal specification, in 1978. Actual compiler behavior varied widely. A true C standard would not emerge until 11 years later, with the first version of ANSI C. That version was adopted as an ISO standard in 1990, and work continued from there. The current version of the ISO C standard is the 1999 revision, known as C99.

But standardization is one thing; adoption is another. Although the most recent C standard was published over a decade ago, compiler support for the specification is spotty at best. Only IBM and Sun (now Oracle) claim full support for C99 features, while the compilers from AMD, Intel, and the Gnu Project only offer partial support. Most notably, as of Visual Studio 2010, Microsoft's compilers do not support any C99 features at all.

Although much of the reluctance to adopt C99 can be attributed to vendors switching their emphasis to C++, the history of C++ has been similarly rocky. Although "The C++ Programming Language," was first published in 1985, the Standard Template Library (STL), today considered a fundamental component of the C++ standard, would not emerge until 1994. Even then, compiler support for templates was often poor, leaving developers deeply divided over their use for years to come.

~

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.

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."