How to Read a JSR
By pelegri on Nov 17, 2010
As promised, here is a basic Reading Guide to a Java Specification Request (JSR). Technical terms are described in the JCP process (current version is 2.7); the initiation process is in Section 1. I've added some historical background and context.
Caveat! I do not work for the JCP office and if there are any discrepancies between the excerpts below and the JCP Document, the official rules win, hands down!
The Submitting Member is the JCP member that is submitting the JSR; for these 4 JSRs, it's Oracle.
The Specification Lead is the JCP member, or the employee of a JCP member that will lead the Expert Group. In our case they are: Joe Darcy (Coin), Brian Goetz (Lambda) and Mark Reinhold (Java SE 7 and Java SE 8).
Coin targets Java SE 7; Lambda targets Java SE 8.
The Initial Expert Group Membership is an initial list of JCP members that have already expressed interest to the EG Lead to participate in the EG. Normally that list is expanded further before the EG starts working.
Increased Transparency was one of the drivers for JCP 2.7 and each JSRs must include a description of how transparency will be achieved in the EG in that is in Section 2.15. The new transparency requirements and infrastructure means that interested parties can follow the activities of the EG without being a member of the EG.
Every JSR has a link to a form to nominate experts to an EG; for instance this one is for Coin. The EG lead decides who to accept; normally it needs to balance representation and expertise with manageability.
The Supporting This JSR section lists JCP members that support the initiation of the JSR. Normally, but not always, these members will also be in the Initial EG Membership. It would be reasonable to expect that EC members that support a JSR will vote for it, but, AFAIK, there is no requirement for that.
Section 2.2 indicates the target platform and section 2.4 what Executive Committee will vote on the JSR. All 4 JSRs will be voted by the SE/EE Executive committee - see the results of the most recent election.
The JSR review is a 2 week period when anybody can review and comment on a new JSR. Comments can be posted through a BBoard; for example this one is for Coin.
EC voting is described in Section A.5; refer to it for a full description but, in a nutshell:
- "A.5.3 EC Members may cast two types of votes: "yes" and "no". Alternatively, a Member may explicitly abstain or, in the extreme and undesirable case, not vote at all."
- "A.5.4 Only "yes" and "no" votes count in determining the result of an EC ballot"
- "A.5.5 Except where noted otherwise in this document, EC ballots are approved if (a) a majority of the votes cast are "yes" votes, and (b) a minimum of 5 "yes" votes are cast. Ballots are otherwise rejected.
- "A.5.9 EC ballots to approve UJSRs for new Platform Edition Specifications 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) Sun casts one of the "yes" votes. Ballots are otherwise rejected."
- Note that there are a number of other rules described in that section.
Applying the voting rules
to the quartet, we have (
I'm awaiting confirmationCorrected!):
- Coin and Lambda require that 2/3rds of the votes cast are YES, a minimum of 5 YES votes, and Sun/Oracle must vote YES.
- Java SE 7 and Java SE 8 require that 2/3rds of the votes cast are YES, a minimum of 5 YES votes, and Sun/Oracle must vote YES.
I think this covers the basics. Check out the full JCP 2.7 process if you want all the details!
Added - I talked with Patrick Curran to confirm under what rule each JSR falls. Since Coin and Lambda have language changes, they require 2/3rds, and since Java SE 7 and 8 include Coin and Lambda, respectively, they also require 2/3rds.