The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JSR #337
Java^TM SE 8 Release Contents
JSR Review Ballot
Ballot duration: 2010-11-16 to: 2010-12-06
These are the final results of the JSR Review Ballot for JSR #337. The Executive Committee for SE/EE has approved this ballot.
Votes

SE/EE
Apache Software Foundation
Credit Suisse
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Keil, Werner
Oracle
Peierls, Tim
Red Hat
SAP SE
VMware
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

SE/EE
On 2010-11-30 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-02 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

IBM intends to work closely with the community on the "JSR TBD: Java Platform Module System" referenced in the JSR 337 proposal to ensure a sound underpinning for OSGi as part of the base JRE.  IBM will also perform a Maintenance Release of "JSR 291 - Dynamic Component Support for Java SE" with the intent of providing a seamless upward compatibility path for the proposed "JSR TBD: Java Platform Module System" to ensure rapid and seamless adoption.
------------------------------------------------------------------------------
On 2010-12-05 VMware voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-11-17 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-03 SAP SE voted Yes with the following comment:
SAP's vote is strictly based on the technical merits of the Java 8 specification, not on its license terms. It is important for Java 8 to proceed now, but we nevertheless want to express our disagreement about Oracle's decision to deny Apache a TCK and place FOU restrictions on its license terms. The reason that was provided to the EC was that Java compatibility could no longer be enforced with code shared under a permissive open source license. As the new steward of the Java language, we respect Oracle's right to license their intellectual property under terms that support their strategy of how to evolve the Java ecosystem. However, we believe that the additional potential for innovation in open source communities outside of OpenJDK well offsets the risks as already demonstrated in the Java Enterprise space. For example, the broad adoption of OSGi and creation of an OSGi-based ecosystem has been greatly enhanced by sharing an implementation of the OSGi runtime under the Eclipse Public License. We regret that the Java 8 JSR has not already made a commitment towards adopting OSGi as their module system. With its broad adoption, we believe it would be a mistake to introduce another module system in Java 8 other than OSGi. We are committed to work with the Expert Group to make this happen.
------------------------------------------------------------------------------
On 2010-11-17 Google Inc. voted No with the following comment:
While we support the technical content of this JSR, Google is voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations or otherwise. Licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates, and violate the expectations of the Java community that JCP specs can be openly implemented." Most EC members, including Oracle, voted for both of these resolutions. But the proposed license clearly violates them in Exhibit A, Section II.

It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license (which violates the above resolution and the JSPA) by voting for this JSR. We were initially reluctant to vote no because we do not want to delay progress of the Java platform. But this concern was made moot by Oracle's statement at the JCP meeting of 10/4/2010 that they intend to move forward with the release outlined in this JSR with or without the approval of the JCP.

------------------------------------------------------------------------------
On 2010-12-03 Peierls, Tim voted No with the following comment:
Changing my vote from "Abstain" to "No" to register my extreme disappointment with Oracle's failure to address EC questions about the licensing terms of this JSR.
------------------------------------------------------------------------------
On 2010-11-30 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-01 Apache Software Foundation voted No with the following comment:
The Apache Software Foundation must vote no on this JSR.  While we support the technical contents of the JSR, and earnestly support the need for the Java platform to move forward, we cannot in good conscience vote for this JSR because : 

a) This JSR's TCK license includes a "Field of Use" restriction that restricts commonplace and mundane use of independent implementations, a licensing element that not only is prohibited by the JSPA but also has been unanimously rejected by the majority of the members of the JCP EC - including Oracle - on several occasions.  We can only speculate why Oracle included such an element, but we believe that an open specification ecosystem must be independent of - and protected from - any entity's commercial interests.

b) On process grounds, this JSR is in conflict with it's own TCK license. The JSR explicitly states that Java SE is targeted for, among others, embedded deployments. Yet the TCK license specifically prohibits such usages (for example, netbooks) of tested independent implementations.  We find this to be a misleading legal trap for potential implementers, and believe that any independent implementation that passes the TCK should be able to be used and distributed under whatever terms deemed fit by the implementer.

c) The spec lead has ignored repeated requests from multiple EC members for and explanation of both a) and b)

d) The spec lead - Oracle - is in breach of their obligations under the JSPA by continuing to provide a TCK license for Apache Harmony under terms that allow Apache to distribute its independent implementation under terms of its choice.  We do not believe that anyone that willfully fails to meet their contractual obligations under the JSPA should be allowed to participate as a member in good stating in the JCP.  The rules apply to everyone.

While we understand that it's Oracle's stated intent to move forward irrespective of the EC's decision, we urge Oracle to fix the above-mentioned issues, and continue to work with the members of the JCP within the structure of the JCP to keep Java a vital and viable platform.
------------------------------------------------------------------------------
On 2010-12-02 Eclipse Foundation, Inc voted Yes with the following comment:
Eclipse is disappointed with the continuing issues around Java licensing. The unresolved TCK licensing issue with the Apache Software Foundation is a symptom of the fundamental problem with FOU restrictions on the Java platform. Our vote is based entirely on the premise that improvements and evolution are required if the Java platform is to remain viable. In addition, we remain concerned that the future of Java modularity may fail to adequately reflect the requirements of the existing OSGi community and ecosystem. Future votes on these JSRs will reflect this concern.
------------------------------------------------------------------------------
On 2010-12-02 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-04 Red Hat voted Yes with the following comment:
Red Hat's vote is based solely on the technical merits of the JSR. We believe that this JSR is important for the industry at large and that further delays risk fracturing the Java landscape further. However, we are extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead. We continue to believe that the TCK should contain no "field of use restrictions", as originally raised by Apache with regard to another JSR during the development of EE6 (i.e. the SE TCK licensing). As a result, this approach risks limiting adoption of this and subsequent JSRs by a wider audience and the fracturing that we mentioned earlier could still occur. We hope that all Specification Leads will take this into account in the future and rank the viability of the Java Community higher than one individual member's abilities to monetise the platform.

Red Hat intends to work closely with the community on the "JSR TBD: Java Platform Module System" referenced in the JSR 337 proposal. We would like to see the Expert Group carefully consider all options available for modularity, including the use of OSGi as part of the base JRE. Any update to JSR 291 should also be taken into account.
------------------------------------------------------------------------------
On 2010-12-06 Keil, Werner voted Yes with the following comment:
While I'm dissapointed with the ongoing license dispute and the effect this and other issues had on the actual content and scope of Java 7 and 8 I believe, it is a necessary and long overdue step towards the future of Java. SE8 although not all of its content JSRs are yet fully finalized is what SE7 should have been under better and less conflictual circumstances.
------------------------------------------------------------------------------
On 2010-12-06 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-06 Credit Suisse voted Yes with the following comment:
Credit Suisse's vote is purely on the technical content. We strongly demand open standards and an active community around Java as we selected Java SE & EE as primary pillars for our application development (as many others in the industry do). The current battle around licensing term, however, reveals that Java never actually was an open standard. FOU restrictions clearly discriminate open source implementations and prevent competition, and with that, innovation in that space. While Java had a considerable head start, it lost a lot of momentum over the last years. Fragmentation (or a fork) of the language and its platforms are clearly not desired. But today, customers are already facing competing models for developing enterprise applications (e.g., Spring, OSGi, Java EE). The main problem, in our view, is the lack of modularization, clear delineation of Java IPs owned by Oracle and truly open standard extensions, and the ignorance of developments outside of the JCP (even though OSGi has a JCP blessing). The OpenJDK framework is not sufficient for all aspects of the language. Java must be kept interesting for researchers and universities: researchers not only contribute to the standards (e.g., Doug Lea for concurrency or Michael Ernst for type annotations) but also decide on the languages (and paradigms) that are taught at universities -- and this in the end determines the knowledge and mindset we acquire with our software engineers. While we recognize Oracles intellectual properties around Java, we strongly encourage Oracle to re-think its current position around licensing terms. We strongly support open source as a licensing model for contributions in the JCP. 

We want to express some concerns about the proposed modularization concepts. As OSGi already provides modularization (and one that truly forces modularization), we do not see why we need yet another implementation. We also encourage Oracle to merge the different platforms (ME/SE/EE) and use modularization to implement different application types. 

------------------------------------------------------------------------------