eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
SAN FRANCISCO—JavaOne is here, but where is Java EE 6?
Java Platform, Enterprise Edition 6 is the next generation of the specification governing the upcoming version of the enterprise Java technology. The technology is expected to be on display at the JavaOne conference here.
A specification had been submitted to the Java Community Process for approval, but the specification was withdrawn soon after it appeared.
An IBM official, who requested anonymity, said, “We asked for more information around Suns thinking on the business models prior to endorsing. I dont think we ever heard back—then it went poof!”
The Java EE 6 specification, known as JSR (Java Specification Request) 313, was offered for ballot on April 3 and later withdrawn on April 13, following a series of questions by the key group of supporters of the issue.
A group of 16 companies or individuals voted on the specification. Sun and Red Hat voted for the spec. Intel, Hewlett-Packard, Oracle, SAS Institute, Google, SAP, Doug Lea and Hani Suleiman abstained from voting, and the Apache Software Foundation, BEA Systems, Borland Software and Fujitsu did not vote at all.
At issue some are some of the “field of use” restrictions Sun has put on its Java EE TCK (test compatibility kit), an issue first raised in eWEEK by Geir Magnusson of the Apache Software Foundation. Magnusson said Sun was purposefully protecting Java for its own commercial gain.
Intel voted to abstain on the JSR 313 approval, saying it was waiting for responses to questions raised by BEA and SAP.
Intel said, “We are concerned about the issue of field of use restrictions raised in the Apache Open Letter on Java SE TCK Licensing. The Spec Lead has confirmed the Java EE TCK License will not contain field of use restrictions as described below. Wed like to see that confirmed in an update to the JSR (like in JSR 312).
“The rest of this comment describes a general procedure we employ as part of the determination of our vote. We think the best approach is to make at least one alternative for the required licenses publicly viewable so that the community knows what is required to implement a spec.
“If there is not an alternative in which all licenses required to implement the specification are publicly viewable, we intend to ask the Spec Lead for confirmation that at least one alternative does not impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations other than the compatibility and reciprocity conditions described in the JSPA [Java Specification Participation Agreement]. In particular, we intend to ask for confirmation that at least one alternative does not limit field of use of a compatible implementation (e.g. prohibit or charge royalties for distributing for use on particular operating systems or particular devices or for use in particular environments or require implementation of features other than what is required in the spec).”
SAP voted to abstain, saying: “We will need to get more clarification for the new proposed license terms, which seem to require a license fee per Java EE profile. If this means a fundamental change in the Java EE licensing model, SAP may decide to vote NO on this JSR based on the proposed license terms.”
Red Hat, which voted for the specification, said, “The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no field of use restrictions, as originally raised by Apache with regard to another JSR [the SE TCK licensing]. That is a good thing. However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.
“Consequently, in the future, for any submitted JSR (by Sun or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.”
Mark Little, director of standards and ESB project lead for Red Hats JBoss division, said in an interview with eWEEK.com, “We had some concerns around some of the wording behind this JSR, but did not believe them important enough to slow down the development and subsequent adoption process. We know the EE6 is very important for the community and vendors, so we voted for [it], but with reservations that we passed on to Sun.”
Meanwhile, rumor has it that Sun plans to open-source the JDK the week of May 7, which should also include the JCK (or TCK in different parlance).
Yet, one observer is skeptical. “I dont believe it as described if it means, The JCK is now under an free/open license, and anyone can use it as-is to demonstrate compatibility with the Java SE specification and in passing the tests, receive all necessary IP from the spec lead and expert group for their implementation,” said the individual. “Why dont I believe it? Because if they were going to do this, why would they take the PR hit of fighting over the TCK in the first place?
“Meanwhile sources said Sun might try something really boneheaded like saying that the JCK is available under the GPL if your code is GPL…If they do this, what I think it will be is that the source is available under GPL, but that still doesnt mean you get all IP rights simply by passing that code base. In other words, that code base is the source that goes into the JCK, but its itself the JCK—thats something else you get from Sun.”
Its true that many in the JSR 313 expert group have said they think the Java EE licensees having are problems with the new profiles, which cause changes in the commercial licensing structure for the TCKs and branding rights.
One observer added, “I think the FOU [fields of use] thing is a red herring here, as there never was a material FOU for Java EE. They may be making a stand on misguided principle here, but in the end, I think they are going to have to capitulate on this—the JCP has to be FOU-free if its to be respected as an open spec organization. My hope is that Sun leads us there rather then gets dragged there.”
Steven Harris, vice president of Oracles Java Platform Group, who has been involved in the discussions around Java EE 6, said he believes the spec will be re-submitted and approved without fanfare.
“I look forward to JSR 313 [being] resubmitted and accepted, as the issues holding it up are not major issues,” Harris said.
Im not sure what Sun plans to announce this week, but it would do well to address the issues to do with Java EE 6. Attempts to contact the Sun leads of the project went unanswered.