Is it time to put the brakes on Java?

The Java SE 7 and 8 specifications have the green light, but commercial pressures threaten to derail what should be a community effort

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.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform