BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JSRs for Java 7 and Java 8 Approved

JSRs for Java 7 and Java 8 Approved

This item in japanese

The results of the recent Java JSRs are in, and all have passed with all but Apache voting consistently against them. Google and Tim Peierls voted against the Java SE 7 and Java SE 8 JSRs, supporting the ongoing licensing issues and field-of-use restrictions for the TCK.

The comments make interesting reading; Steven Colebourne summarises them on one page. Even though the majority voted for the TCK, the comments continue to criticise the licensing issues:

  • Google: is voting no because of its licensing terms
  • SAP AG: While we believe it is important for Java 7 to proceed now, we want to express our disagreement about Oracle's decision regarding the TCK for Apache.
  • Eclipse: is disappointed with the continuing issues around Java licensing
  • RedHat: is extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead
  • Credit Suisse: The current battle around licensing term, however, reveals that Java never actually was an open standard.

Many of the comments also show that they are begrudgingly voting for the JSR if only to move the Java platform forwards from the stagnant location it is today. In addition, modularity raises its voice in both the Java SE 7 and Java SE 8 discussions, with OSGi interoperability being mentioned specifically for the Java SE 8 JSR.

This is also the first time an umbrella Java SE JSR has been put to the vote before it's actually ready. Whilst the work on Project Coin and Project Lambda have made significant progress recently, and the other inclusions (such as JDBC 4.1) in Java SE 7 will be welcomed, the contents of the Java SE 8 JSR include a number of not-even-started JSRs. Perhaps when Java SE 8 is ready, Oracle can point back to the votes and claim that it was agreed by most, even if the Java SE 8 content differs markedly from its original version.

However, with the licensing issue left unresolved, some are calling the JCP “Just Customers, Please” – Oracle does not appear to take the JCP seriously any more. The last stage in this saga will be Apache's resignation from the JCP which will follow up on their earlier threat. Here is what may be the Apache Foundation's last vote on a JSR:

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:

  1. 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.
  2. 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.
  3. The spec lead has ignored repeated requests from multiple EC members for and explanation of both a. and b.
  4. 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.

Since Oracle looks unlikely to honor the agreement, a statement by the Apache Foundation is expected in the next week.

Rate this Article

Adoption
Style

BT