Skip to main content

[JSR 358 Observer] [JSR358 EG] Re: Minutes from today's IP Working Group meeting

  • From: "Steven G. Harris" < >
  • To:
  • Cc: JSR 358 Expert Group < >
  • Subject: [JSR 358 Observer] [JSR358 EG] Re: Minutes from today's IP Working Group meeting
  • Date: Fri, 25 Jan 2013 15:39:18 -0800
  • List-id: <experts.jsr358.java.net>

Relative to my statements about tying exceptions to umbrella or platform specs, I was under the impression that Oracle was explicitly named as the umbrella spec lead. However, I see it's a more indirect than that when I look more closely at the Process Document

TL;DR summary:

1. Oracle has veto power over new umbrella specs, which include Platform Editions and Profile Specs. Thus, while Oracle is not pre-defined to be the spec lead, nothing can happen in umbrella specs without Oracle's approval, and an umbrella spec cannot be created without Oracle's approval.
2. Major changes to language, API, and JVM can only happen within an umbrella JSR. Thus, Oracle has veto power over language, API, and JVM changes.
3. Whether a JSR is included in the umbrella spec is something decided by the spec lead and expert group. Thus, Oracle controls what goes into platform specs.
4. While I'm not familiar with the existing situation in ME land, it has somewhat by definition happened with Sun and Oracle's approval, and Oracle has control over what happens there in the future for umbrella JSRs.

Longer version for the legally inclined:

The Process Document defines UJSR as:

Umbrella Java Specification Request (UJSR): A JSR that defines or revises a Platform Edition or Profile Specification. A UJSR proceeds through the JCP like any other JSR.

and specifies the voting rules:

Ballots to approve UJSRs that define the initial version of a new Platform Edition Specification or JSRs that propose changes to the Java language are approved if (a) at least a two-thirds majority of the votes cast are "yes" votes, (b) a minimum of 5 "yes" votes are cast, and (c) Oracle casts one of the "yes" votes. Ballots are otherwise rejected.

Thus, Oracle has veto power of UJSRs, which means it can refuse to initiate new ones unless it is happy with the proposal, including presumably who is the sped lead (and whatever arrangements it might have on the side with the spec lead).

Some other relevant verbiage about Platform JSRs from the Process Document for those with the appetite:

2.1.2 PROTECT THE INSTALLED BASE AND GUARD AGAINST FRAGMENTATION

Changes to the Java programming language, the Java virtual machine (JVM,) the Java Native Interface (JNI,) packages in the "java.*" space, or other packages delivered only as part of Java SE, have the potential to seriously disrupt the installed base if carried out inconsistently across the Platform Editions. In order to protect the installed base, any such changes can only be accepted and carried out within a UJSR for Java SE.

In order to guard against fragmentation, new Platform Edition Specifications must not substantially duplicate existing Platform Editions or Profiles.

2.1.3 PROFILES AND API SPECIFICATIONS TARGET CURRENT PLATFORM EDITIONS

All new or revised Specifications must be compatible with the most recent versions of the targeted Platform Edition Specifications. In order to achieve this, all UJSRs to define new Profile Specifications or revise existing Profile Specifications must reference either the most recent Release version of the Platform Edition Specification they are based upon or a newer version of that Specification that is under development via an active UJSR.

2.1.4 PLATFORM INCLUSION

The JSR submission form requires the submitter to state whether the JSR's RI and TCK should be delivered as part of a Profile or Platform Edition, in standalone manner, or both. The final decision as to whether a specific JSR is included in a Profile or a Platform Edition is made by the Spec Lead and Expert Group of the Platform Edition or Profile JSR, and is confirmed by the EC ballots on the relevant JSR. If the Spec Lead for the Platform Edition or Profile JSR turns down a request for inclusion then the JSR must deliver a standalone RI and TCK.

Technologies may be incorporated into a Profile or Platform Edition after having been initially delivered standalone. A JSR for a new version of an API that proposes to become part of a Profile or Platform Edition and is considering discontinuing standalone availability must state the rationale for this change and must inform the public of the intention to discontinue the availability of the standalone RI, and TCK one JSR submission in advance.


On Jan 25, 2013, at 2:13 PM, Patrick Curran < "> > wrote:

The minutes from today's IP Working Group meeting have been posted to the Document Archive.



[JSR 358 Observer] [JSR358 EG] Minutes from today's IP Working Group meeting

Patrick Curran 01/25/2013

[JSR 358 Observer] [JSR358 EG] Re: Minutes from today's IP Working Group meeting

Werner Keil 01/25/2013

[JSR 358 Observer] [JSR358 EG] Re: Minutes from today's IP Working Group meeting

Steven G. Harris 01/25/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Minutes from today's IP Working Group meeting

Werner Keil 01/26/2013

[JSR 358 Observer] [JSR358 EG] Re: Re: Minutes from today's IP Working Group meeting

calinel pasteanu 01/27/2013
 
 
Close
loading
Please Confirm
Close