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
  • 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

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

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”)

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.

comments powered by Disqus