Recent top five:
Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first
post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together
in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
Sun Microsystems introduced the Java Community Process (JCP) on December 8, 1998, to provide a blueprint for the Java community's activities. Almost from the start, the JCP became the target of intense criticism from the Java developer community: the JCP wasn't open enough, or efficient enough, or effective enough in promoting Java. Partly in response to those criticisms, the JCP has changed over time. In this article, we evaluate the JCP's effectiveness based on measurable facts of its four-year history to see if these criticisms are based on truth or mere perception.
Read the whole series "Effort on the Edge:"
A typical early complaint went like this, gleaned from a 1999 XML.org mailing list message sent by Simon St. Laurent:
The JCP may feel like an 'open' process if you're a mammoth, or even if you're a reasonably well-off saber-toothed tiger, but to us small mammals, it's the same old [stuff]...we get from standards organizations. We get to run around among the mammoth and saber-toothed tigers wearing funny lenses that blur our vision, and working with tools that may not have been created with our needs in mind.
In an editorial from the same year, titled "The Java Gated Community Process," author Elliotte Rusty Harold wrote:
If it seems a little strange that all of this work is going on behind closed doors without significant public input or awareness of its existence, that's the Java Community Process at work. The JCP is Sun's new procedure for adding to Java with input from its major commercial partners. The "community" is comprised of companies who are willing to pay Sun ,000-,000 a year to belong, as well as Sun's Java commercial licensees who pay even more to license the JDK source code. This is very much a gated community designed to keep out the riffraff like you and me and let Sun run things the way it sees fit.
More recently, a January 2003 article on Builder.com laments:
Many veteran Java developers are shying away from the Java Community Process (JCP) in large numbers and gravitating toward smaller developer communities to implement their new ideas. The JCP, once a place where developers were on a first-name basis with leadership and could email a question and get an answer within minutes, has become Java the Hutt: fat, sluggish, and difficult.
Not only have individual developers frowned upon the JCP, but so have many of the largest companies among Java's key backers. For instance, a comment about the JCP's attitude towards Web service-related standards prompted Stefan Van Overtveldt, program director of IBM's WebSphere product line, to opine in a December 2002 interview with Integration Developer News:
There might be significantly more pressure on Sun to submit Java to [another] standards body to really open it up. We have enough leverage to exert some changes with companies like IBM, BEA, and others driving for new ways of bringing in new services. [J2EE (Java 2 Platform, Enterprise Edition) is] driven as much by other members of the JCP as it is by Sun. In fact, 70 percent of the initial J2EE specification is [intellectual property and] technology we donated to Sun and the community. [For instance, the] transaction and messaging, and JCA (Java Connector Architecture) is IBM architecture.
An open Java standard has long been on IBM's, and other large Java backers', wish list. Since Java is a strategic tool for those firms, they prefer Sun to have as little control over the technology as possible. Bob Sutor, IBM's director of e-business standards strategy, echoes that sentiment: "Sun is a competitor to us and is not a neutral body. What we want is an industry-neutral body where no one company has too much power, and that body has to have jurisdiction over all of the Java specifications...If Java was an open standard, technologies like [Microsoft's] C# and the technologies it works with [like .Net] might not exist today" (from "IBM Pressures Sun to Free Java," David Berlind (ZDNet, September 11, 2002).
As if the barrage of criticism from individual Java developers and mammoth corporate Java sponsors were not enough, the most popular open source developer communities have also expressed strong dislike for certain JCP aspects. The only open source group with a JCP executive committee seat is the Apache Software Foundation. Apache used its executive power to cast a "nay" in the final approval of 14 JSRs (Java Specification Requests) over the past two years. Its reasons were not primarily technical. In voting against acceptance of JSR 47, the Java Logging API Specification, Apache's JCP representative explained the vote: "Regretfully, under the Merlin business terms, log4j (or any other potential independent implementation of this specification) cannot use the specification, nor can anyone implement this specification for earlier J2SE platforms...and it is on this basis that Apache cannot support this JSR." (For an overview of the JCP, including the various JCP voting stages, please see Part 1.)
Given that strong negative sentiment from practically all sides of the software universe, can the JCP survive? Since the JCP's primary raison d'etre is to advance Java and ensure that all Java implementations stay compatible with agreed-upon standards, any Java developer would be wise to start worrying: dark clouds are surely gathering on Java's horizons.
But are they? Is a developer's worry about Java's future justified?
In this article, we endeavored to answer those questions, not by listening to the "experts," but by looking at a few indisputable facts about the JCP. We examined publicly available information from the JCP Website to construct our own database and run a few analytic queries on that database to check on the JCP's health. The Website lists all JSRs, including not only their names and descriptions, but also the members in each JSR's expert group as well as the votes each EC (executive committee) member cast.