Controversial JSRs Made Public

Oracle Submit Four JSRs For Controversial JCP Vote

Jessica Thornsby

Oracle have submitted JSRs to the JCP vote, complete with explicit Field Of Use clause.

Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle has announced that four new Java Specification Requests have been submitted to the JCP for voting. These four JRS are:

  • JSR 334 from Project Coin. This features some “small enhancements to the Java Programming Language.”
  • JSR 335 from Project Lamdbda, which features Lambda Expressions.
  • JSR 336, which is Java SE 7 Release Contents from JDK 7 and the first half of Plan B.
  • JSR 337, which is the rest of Plan B, for the eventual JDK 8.

Mark Reinhold hopes to get the results in two weeks, although there has been some lobbying from the community – most notably from the ASF – to vote against the JSRs, and Stephen Colebourne has already delved into the licensing terms. He summarises that the Specification and Reference Implementation licenses look “fairly normal and bland,” but the TCK license is interesting for him as the “Field of Use” clause is an explicit part of the license:

Java Environment(s) Specification” means a Java Specification that defines a baseline API set that provides a foundation upon which applications and other Java Specifications can be built. For example, and not by way of limitation, Java Environment Specifications include: (a) “Platform Editions” such as the Java Platform, Standard Edition (“Java SE”); Java Platform, Enterprise Edition (“Java EE”); and Java Platform, Micro Edition (“Java ME”) Specifications; (b) “Configurations” such as the Connected Device (“CDC”) and Connected Limited Device (“CLDC”) Configurations; and (c) “Profiles” such as the Mobile Information Device (“MIDP”) Profile.

The TCK license states a product must meet three additional criteria beyond the basic ones. It must:

  • “have a principal purpose which is substantially different from a stand-alone implementation of that specification.”
  • “represent a significant functional and value enhancement over any stand-alone implementation of that specification.”
  • “not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification.”

Stephen Colebourne believes that, if the Apache Harmony project attempted to implement this JSR, it would fail on all three of these criteria: it would be a stand-alone implementation with the same purpose as OpenJDK, with no significant functional enhancement, and it would be marketed as a replacement technology. Oracle also bar others from “distribut(ing) code which implements any portion of the Java Specification unless such code is included in a Product within the meaning of Section 1.12.” Since Apache Harmony fails Oracle’s ‘product’ tests, it is not a product, and therefore cannot distribute code. Clearly, despite the controversy surrounding Oracle’s withholding of the TCK and IBM’s decision to abandon Harmony, Oracle have made no concessions to Apache Harmony in this latest round of JSRs.

Inline Feedbacks
View all comments