Updated Sun Microsystems' rocky relationship with open source over Java is again in the spotlight, after it lost support of two influential groups for the latest update to enterprise Java.
The Apache Software Foundation (ASF) has voted against Java Enterprise Edition (Java EE) 6.0 to register its protest in a long-running dispute over licensing of test compatibility kits (TCKs) with spec-lead Sun. It's the first time Apache has voted against a pending Java spec, having voted for both Java EE 5.0 and Standard Edition (SE) 6.0 in the past.
Abstaining from the Java EE 6.0 vote was SpringSource, home of the ever-popular Spring open-source Java framework. SpringSource blamed a process of "design by committee" that it said had led to the inclusion of new and untested features that risked introducing breaking changes to enterprise Java.
Other, closed-source companies taking part in the Java Community Process (JCP) vote who said "yes" qualified their support. Enterprise giant SAP called for more work on a "single consolidated and extensible" component model instead of the current three: EJB, JSF and JSR 299.
Apache - home of the ever-popular web server - was the only one of 16 JCP members to vote "no" on the Java EE 6.0 spec, though. Java EE 6.0 is the long-awaited update to the EE platform used by Oracle, Sun, IBM and relied on by organizations like Eclipse and SpringSource.
Geir Magnusson Jr, Apache's JCP representative, told The Reg JCP members have few avenues to disagree with Sun, so a "no" vote was the only option open.
Apache voted against the spec because it said Sun - the spec lead - has breached the terms of the JCP's Java Specification Participation Agreement (JSPA), by inserting terms into the licensing of the all-important TCKs that limit uptake of Java.
Magnusson said he's forbidden from revealing what the licensing agreement is, but that Apache cannot pass on another company's terms and conditions in its own license.
It's the latest chapter in a long-running disagreement between Sun and ASF over TCKs. Magnusson published an open letter to Sun chief executive Jonathan Schwartz in 2007 that asked for a TCK license that complied with JSPA.
Magnusson claimed today, as the did two years back, that Sun's refusal to change its licensing terms is damaging Apache's Project Harmony, an open-source implementation of Java SE. Harmony had a modular, OSGi implementation in Java SE before Sun's official Java SE. Without a TCK, Apache cannot prove Harmony complies to Sun's Java specification, meaning people will shy away from using it.
"Sun's doing tremendous damage to the project," Magnussen said.
It looks like Sun's rigorous stance is hurting the one thing the company holds so dear, anyway: compatibility. Google's Android uses Harmony's class libraries.
SpringSource, meanwhile, said while the Java EE 6.0 was a move in the right direction with the inclusion of a "web profile" - hence the "abstain vote" rather than "no" vote - the final spec had departed from its original vision of being lightweight. The concern is that particularly during the last six months a significant number of dependencies were added to the web profile that increased its size.
Another problem was the addition of unproven technologies in Java Specification Request (JSR) 299 that risk causing more harm than good, with the introduction of breaking changes.
Johnson called it a classic case of design by committee instead of building something real-world users would want. The inclusion of untried features had raised a "red flag."
"We feel there's too much new and unproven stuff we think is unproven - in part the light-weight variant to EJB that's never been seen in the wild," Johnson said.
The Java EE spec is now finished and is now simply awaiting implementation by Java vendors. SpringSource senior vice president of engineering and product management Peter Cooper-Ellis told The Reg the company is evaluating the spec and would only implement the parts "that make sense."
Sun was unavailable for comment at the time of going to press.®