Given Werner's email below is a collection of confusions , impressions and speculations, some clarifying words :
- the only ME related umbrella JSR ever, was the MSA
- MSA was not specleaded by Sun/Oracle but Nokia & Vodafone
- an ME configuration or an ME profile JSR is not an umbrella JSR by definition and so 360/361
- the Device Access non-existing JSR ( and there will be none with such name ) would be an optional package
- inclusions of APIs into 360 , as speculated below , have no real basis
The type of email like the below is very difficult to handle in an email dialog....
if you have questions, please give me a call, this way we would probably reduce the # of emails and the # of less relevant topics.
On Jan 26, 2013, at 2:06 AM, Werner Keil wrote:
Thanks, those are good points.
Not touching the subject of Architecture Entity (Board, Council,...) here again too much, but the option of having not just Oracle among Umbrella Spec Leads would of course leave some freedom to encourage other companies or individuals to get involved there. If Oracle has veto power, that's fair, but it could allow some diversity here if desired.
Although not explicitely named "Umbrella", and I recall, only former ME EC Members voted for both 360 and 361, both, 360 probably more than 361 make the impression of an ME "Umbrella", too.
I can confirm from the EE 7 Umbrella, that a rather active and seemingly democratic (though Spec Leads, both by Oracle have the ultimate say, but they don't seem to do so against a vast majority of voices by EG Members) decision making process happens there, about which JSRs to join EE in general, and which of them to go under what profile.
2.1.2 goes along my concerns about a "backport" of JSR 310 under another Java Platform related package space, e.g. javax.time, etc. Based on what co Spec Lead Roger Riggs replied, and I glimpsed on GitHub, while he continues to integrate that JSR with the platform, his pairs now focus on development outside the JCP in a project named "org.threeten". The proposal of 310 already suggested, it may become part of SE (then 7) and an independent pet project may seem more like a successor to JodaTime than conflict with a part of the platform. Whether or not there was any IP flow in that case, that I leave to those with the "appetite" on that particular area, it's of course possible<347.gif>
2.1.3 was e.g. found to be violated by Java Batch we recently heard about. Which clearly duplicates features from SE 7 in 2 interfaces. While Linda and EE 7 Umbrella EG is aware, it seems, the Spec Lead and EG of that particular EG wishes to make it available under either the EE 6 Umbrella or standalone, so they insist on keeping the minimum SE version to be 1.6, not 1.7. I remember, Markus Eisele quoted what seems to be the same paragraph on this matter. It was noticed, but doesn't seem applicable or overrule the interest of portability by the Batch JSR. I may ask EE 7 members again.
2.1.4 sounds fascinating. Not sure, how some new JSRs like Device Access (TBD) or Money and Currency (354) will pin-point the Umbrella JSR they fall under? As of now, SE 9 for 354 is a known but late target. RI and TCK following an EDR (as mentioned, as soon as result of Renewal is in<347.gif>) may each follow within the deadlines which are 12 months max for Public Draft and another 12 months after that to go Final. That's within the predicted SE 9 timeframe.
Whether a JSR like Device Access or 354 may also be included with CLDC 8 prior to that, is an interesting question?
Given the parts (we talk about Modules or subsetting here already, especially for ME Embbedded where entire parts of SE 8 are to e subsetted<329.gif>) relevant may be ready and Final by the time that Umbrella JSR goes Final.
Section 2.16 of the original JSR 354 proposal states:
TCK and RI will be developed as standalone modules. RI is intended for distribution as part of Java SE version 8 but can run standalone
Should be version 9 btw., but important question also to Java Batch JSR btw, is, does a JSR once it intends to become part of an Umbrella HAVE TO discontinue standalone availability, or can it CHOOSE TO discontinue it?
On Sat, Jan 26, 2013 at 12:39 AM, Steven G. Harris <
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.
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:
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.
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.
The minutes from today's IP Working Group meeting have been posted to the Document Archive.