The following stages of the Process require the Spec Lead to submit materials to the PMO.
Please consult
the timeline as a graphic view of the way a JSR moves through the process.
The
JCP multimedia page has audio tutorials explaining different stages of the process as well.
The Spec Lead's role is to drive the proposed specification through the process.Communication between the Spec Lead and the PMO is essential to achieve the goal of releasing a final spec within the schedule outlined in the Proposal. This schedule should be updated by the Spec Lead at regular intervals to show the correct information on the JSR public page.
If you are submitting a Proposal as an employee of a JCP Executive Committee (EC) Member company, please indicate the internal approval of your JSR Proposal by copying the EC Representative on your submission to the PMO. Otherwise the PMO will delay the posting of your Proposal to the Ballot until the internal approval confirmation is received.
Please provide the PMO at your earliest convenience with your complete contact info, including postal address. If the Spec Lead and the Submitter of the Proposal are not the same person, please provide this information for both. The PMO will then provide you with your login to the Expert Group private page of the JSR.
The first step in the process is to write the proposal. The Proposal should describe clearly what is being proposed -- what problem is being solved, what the constraints are on the solution, what approach will be taken, what existing technologies may be used as a starting point, etc. The Spec Lead should consider marketing and business issues as well -- who are the customers for the solution, how will the solution be delivered, and what companies should be involved in creation of the specification. The Spec Lead should find endorsers/supporters for the proposal before submitting it, so as to demonstrate community support/interest in the specification.
You may want to solicit support for your Proposal from the Members of the voting Executive Committee at this early stage. EC Members will look at various aspects of the JSR Proposal:
- Is the schedule credible?
- Does the submitter have the appropriate expertise?
- Does the Proposal address appropriate needs in specific markets?
- Is the featureset appropriate?
- Is there enough detailed information?
The Spec Lead should look at some of
the JSRs that were voted down to get an impression of some EC objections.
The JCP 2.6 Proposal Form requires the outline of the proposed business terms for the final Specification. Knowing the proposed business terms gives potential Expert Group members the opportunity to decide at this early stage whether or not they want to become members of your Expert Group and accept these terms.
You may choose to use any of the following license templates for your proposed business terms under JCP 2.6. You are also free to choose another licensing model, as long as it is not in conflict with the JSPA.
As compatibility testing is an essential component of the JCP, the Spec Lead should consider how the technology will be tested, how the test suite will be developed, and what testing infrastructure might be needed. You should also plan the budget for the development of the RI and TCK. The more completely and clearly the JSR provides this information, the easier it will be for others to review the JSR, and the easier it will be for the Spec Lead to recruit EG Members.
Spec Leads are also asked in the JSR submission form to consider which Java platform editions their JSR will target and how their JSR will relate to those they are not targeting. Spec Leads should carefully consider this question, to ensure they are taking possible migration of the technology to other platforms into account. If the Spec Lead has questions about the applicability of the JSR to other platforms, they are encouraged to contact EC members for the editions in question, they will be happy to help.
As of JCP 2.6, JSRs can choose to target both Executive Committees, if the technology of the JSR is applicable across multiple platform editions. If a Spec Lead chooses this option, they will be voted on by both the ECs at each ballot stage, and they must pass both ballots (the votes are not combined into one ballot) in order to proceed. Alternatively, Spec Leads can also create two separate JSRs for the technology, and operate them in parallel.
Spec Leads must also carefully consider how the work of their JSR will be made available to the community and the public. The Executive Committees will review the Spec Lead's plans for how their Expert Group will inform the outside world of the progress and decisions that have been made, and could choose to reject a JSR if the operating plan does not take the community and the public into account. Spec Leads are encouraged to answer the following questions in their transparency plan:
- How often will you provide a draft specification to the community and to the public?
- How will the community be made aware of the open issues that the Expert Group is working on, and the decisions it has made?
There are tools available that can help Spec Leads create a more successful and more transparent JSR. Here are some of the tools that Spec Leads are encouraged to use:
Use the
JSR Proposal form to submit a JSR. Older versions of the JSR Proposal form do not include the newest requirements and will delay the posting of your new JSR. See
Sun Trademark and Logo Policies for guidelines for JSR names. For information about the JSR Naming program, please send inquiries to jsr-name-request
@sun.com.
To get on a particular JSR Approval Ballot, submitted JSRs must be received on or before the Wednesday prior to the desired Tuesday's ballot. For example, if you wished to submit a JSR to be posted on Tuesday, 7 April, you would have to use the JSR Proposal Form toubmit your proposal no later than Wednesday, 1 April.
When received, the proposal is reviewed by the PMO for completeness. The PMO will contact the submitter if there are any issues that require clarification. Once there are no issues, the PMO then assigns a JSR number to the proposal and prepares to post it for the next available Tuesday ballot.
The JSR is posted to the JCP web site and announced to the community when the JSR Approval Ballot begins. The JSR Approval Ballot runs for a 2 week voting period starting on Tuesday and ending on Monday, midnight PST/PDT. If Monday is an U.S. holiday, the voting period extends to Tuesday midnight under the holiday voting rules. The elected
Executive Committee (EC) appropriate to this proposal casts votes on your proposal during this period.
A Ballot requires a minimum of 5 yes votes and a majority of the votes cast to be approved. Non votes are not counted. The Spec Lead must be responsive to comments sent to the JSR comments alias from the voting EC. The PMO establishes the comments alias with the posting of a JSR. The Spec Lead(s) and the PMO are on the comments alias. If you are not available during the voting period you must provide the PMO (pmo
@jcp.org) with an alternate contact. You may provide the PMO at any time with an addition to the comments alias on either a temporary or permanent basis.
If your JSR Proposal is not approved by the EC, you have 14 calendar days to revise the Proposal for a reconsideration ballot. If you plan to submit a revised Proposal, please notify the PMO (pmo
@jcp.org) as soon as possible. If you have reason to believe that your JSR may not be approved, you might want to start revising the Proposal earlier.
You may update the JSR detail page throughout the process in all stages except during the initial JSR Approval Ballot. Please note that after the JAB, you can update schedules, TBAs, dependencies on or connections to other JSRs, but not the approved scope of the JSR. Like the rest of the proposal, the initial Expert Group and Supporters sections can only be updated until the JSR Approval Ballot begins. After the beginning of the JAB, no additions or changes will be made to these sections of the JSR page. Any updates made after the ballot completes will be posted in a separate section entitled 'Updates to the Original Proposal', while the original text will still appear in the 'Original Java Specification Request' section. Spec Leads are encouraged to use the Community Update section of the JSR to provide frequent updates on the JSR to the community and the public (regular updates before the review periods are very valuable to those outside of the EG who are tracking the JSR), though they may augment this with third party tools. Java.net, SourceForge and other services are available for this.
Nominations for the Expert Group are accepted from the first day that the JSR is available for review from the JSR page itself (with the JSR # already inserted) or from
http://jcp.org/en/jsr/egnom. They will be accepted until you notify the PMO (pmo
@jcp.org) that the EG will no longer accept new nomination. The PMO then closes the EG and the link "I would like to join this Expert Group" will be removed from the JSR detail page. Nominations can then be processed by the Spec Lead via a link on the Expert Group private page (
http://jcp.org/en/eg/my). The Spec Lead votes on whether the nominee is desired on the Expert Group, and the PMO votes as to whether the nominee is legally able to participate. Remember that all Experts on your Group must be JCP Members. The PMO only screens for JCP Membership and nominations from embargoed or terrorist countries. If you wish to accept an Expert to the group who is not yet a JCP Member, inform the nominee that s/he needs to
become a Member first. If you vote Y on a nominee and the PMO votes Y (the nominee is legally able to participate on your EG), then the nominee is automatically added to your Expert Group, login information is sent to the nominee, and the Expert Group-private e-mail alias is updated to include the new expert.
If you want to invite someone to join your Expert Group, have them fill out the nomination form on your JSR detail page (the link labeled "I would like to join this Expert Group"). You can check Membership at: http://jcp.org/en/participation/members. You are encouraged to actively recruit Members to join. Recruit your EG as soon as possible. Before inviting multiple experts from one company or organization you should consider the diversity and industry representation of your EG. Please note, you may have more than one Expert from any given company or organization on your EG. You can always check the membership of your current EG on the EG private page. As the Spec Lead you can also edit contact information for your EG there.
As the Spec Lead you have the following responsibilities with respect to formation of the EG:
- Form an Expert Group large enough and diverse enough to ensure wide adoption of the resulting Specification.
- Notify each person who volunteered to serve on the EG of the status of their nomination.
- Document the reasons for accepting or rejecting each nomination. You will be expected to provide these reasons if there are questions from the nominee or the ECs about the composition of the EG.
Keep in mind that most Expert Group members are only available part-time. Depending on the JSR decide on the ideal size of the Expert Group. You may want to carefully think about the minimum number of EG Members needed. The Expert Group should be large enough to ensure reasonable industry representation and diversity of opinion. The EG should not have less than 4 Members excluding the Spec Lead. In any case you may want to allow for a late nomination of an Expert with excellent qualifications and knowledge of the technologies associated with your spec.
- You must inform the newly formed EG at the earliest opportunity how you plan to manage the group (eg conference calls, e-mail list, regular face-to-face meetings, etc.). The best opportunity is a kickoff meeting where EG members still have the choice to withdraw from the EG without having a lot of time and work invested if they cannot agree to your methods or your business terms. Even though the planned business terms are outlined in the Proposal, they usually cause lively discussions in kickoff meetings. It is important for you as the Spec Lead to have the support and active involvement of your EG.
Sun is an United States corporation, which means that we are legally bound to follow the laws of the U.S. This includes rules dictated by the State Department on countries with which we may and may not do business. We include the State Department's disclaimer about terrorist and embargoed countries for your convenience, so you won't be disappointed by selecting an expert only to find out that he/she can not legally participate in the process. Information on Embargoed and Terrorist Countries can be found at:
http://www.treas.gov/offices/enforcement/ofac/. Information on the Denied Persons List can be found here:
http://www.bis.doc.gov/dpl/Default.shtm.
The PMO (pmo
@jcp.org) will then publish the names of the represented JCP Members (the company name or the name of an individual) on the JSR page. The Experts will be listed on the JSR's Expert Group private page with their names, e-mail addresses, and telephone numbers, if provided. The PMO sends the appropriate login and password to each Expert.
- Maintain communication venues for the Expert Group. The PMO provides a comments alias for the initial JSR, a private web site for the Expert Group (with file upload capability), and a private Expert Group e-mail alias archived on that same site. Also listed on this private page is the entire Expert Group and any aliases that you wanted added to the EG's private alias. As the Spec Lead you can edit the contact information for your EG at any time on this site. Whatever additional communication venues you choose, keep in mind that they must be accessible to all experts in the EG. The archives of these communications must also be accessible to all experts in the EG.
Some Expert Group members may be involved in developing Independent
Implementations so the Spec Lead should take reasonable precautions to
allow those who do not want to see RI internals to avoid them. This in
no way restricts making the RI source available to the EG or the
public. It's just a matter of labeling so that those who do not want
to see it can avoid it. It is recommended that all email concerning
RI implementation details use subject lines that make it clear the
mail is about the RI. Any teleconference or other meetings where RI
details are discussed should have the agenda arranged so that those
who do not wish to participate in that discussion can drop out.
Downloads for RI source code should be clearly marked to indicate it
contains the RI.
The Spec Lead can edit the JSR's private page by clicking on the link "My Home" which is located under the JSR title on the Expert Group private page.
Each JSR has a comments alias created for it, to which the Spec Lead is subscribed. This alias, jsr-xxx-comments
@jcp.org, is intended for comments by Community Members and the general public on the JSR. The Spec Lead should collect and share those comments with the EG. Each individual on the Expert Group is subscribed to a private Expert Group mailing list, jsr-xxx-eg, to which only they can post by use of their unique e-mail address. The Spec Lead must make sure that each expert's e-mail address is current, so that no messages on that alias are missed. Communications on this alias are stored on the Expert Group private page in an archive accessible only by the individuals on the EG.
The methods that you use to stay in touch with your EG may differ depending on the JSr, the locations of the experts, the size of the EG and how involved the individual team members are. For some Groups e-mail aliases, online groups or web sites will work best. Others might consider face to face meetings, conference calls, video conferences or any combination of these.
- You need to be responsive to your Experts' concerns and input. You must make it clear to the EG that each Expert has the right to call for a conference call to resolve issues with a further ability to inform the PMO in case of failure.
- If you have a Program Manager or Product Manager to help you with the administration of the JSR process, please provide the PMO (pmo@jcp.org) with the name and contact info for this person as well.
Note that a representative of the PMO is available to help you through this process. If you wish to have a PMO representative attend the initial/"kick-off" meeting of your EG, please send a request to admin
@jcp.org to that effect. The PMO can attend such an initial meeting by telephone (or occasionally in person, depending on location) and would be available to answer questions about the process and/or give a short presentation to the Expert Group about the process.
The involvement of the Expert Group can determine how well a spec is written and its success. You should consider involving the Expert Group team in each stage of the Specification's development. As the Spec Lead you will write successive drafts of the spec and present these for comments and review to the Expert Group. You should work to address your Expert Group's questions and concerns about the drafts you present. The more diverse an Expert Group, the more likely the Spec Lead will get a broader perspective followed by acceptance and buy-in. Remember that the goal of the JSR is to accommodate real business needs, the needs of the community and to have it widely adopted.
For all public postings of your JSR, the PMO will create a spec license, which will be used as a click through license for the posting. If you wish to use that license within your specification file, please provide the version number of the specific version of the spec to be posted, (N/A/ if there is none), the date for the posting, and the full corporate name and address of the Spec Lead Member, all before submitting the materials for the stage posting. The PMO should provide the license within 2 business days of receiving your request.
Here is the
license template for non-final JSRs and the
license template for final JSRs.
Please note that if you choose to provide your own license for any submission, your submission must go through legal review and therefore the PMO cannot guarantee the regular turnaround time for posting your spec.
If your JSR is operating under JCP 2.1 or earlier versions of the process, your first stage will be
Community Review. Please inform the PMO (spec-submit
@jcp.org) as soon as possible of the approximate date for the Community Review to allow preparation time.
Once the EG agrees that you are ready for Community feedback on the draft of your spec please submit it to the PMO (spec-submit
@jcp.org) via e-mail with the JSR number and "Community Review" or "CR" in the subject line. When submitting the draft please provide the following:
- The Spec, in pdf or zip format (please note that Javadoc files must be zipped).
- The alias for comments. You need to share all comments received during the review with your EG. It is also very important that you acknowledge these comments.
- The length of the Review (30, 45, 60 or 90 calendar days). During the review until the the draft goes on the Community Review Ballot you can increase the length to the next increments. (Note that the final week of review is the draft approval ballot which may result in a slight extension of your review in order to accommodate the ballot.)
- A draft of the anticipated Business Terms. These terms are made available to the voting EC as part of the draft approval ballot. Please provide the draft of the business terms to the PMO. At the minimum this draft needs to include the licensing model and the anticipated licensing fees that you expect to apply to the Final Release versions of the RI, TCK and specification. Your Marketing Department can help you with this part of the requirements. Please look in the "Writing a JSR" section above for licensing templates. You can use one of these templates or any other licensing model provided that the compatibility requirements in the appropriate JCP document are addressed. The lastest version is JCP 2.6 found at: http://jcp.org/en/procedures/jcp2
- The answer to the following questions.
A. Does the specification include software codes
in the following format:
Binary : Yes _______ No __________
Source (compilable) : Yes _______ No __________
Javadocs : Yes _______ No __________
B. Do the codes or the spec call on, contain, use or demonstrate encryption technology?
Yes _________ No ________
If yes, please describe in detail
Turnaround time: The Community Review should be posted within 2 business days of the PMO receiving
all of the above materials.
At this point the PMO recommends you begin with the scheduling and planning of your RI and TCK. A stable RI and well planned TCK require careful scheduling.
Please note that you cannot enter any Review period until all of your deliverables are submitted.
During Community Review you may receive good suggestions that you wish to incorporate into the Spec. You and the EG may revise the Spec. In the case of major revisions to the draft during Community Review, you should send the revised draft, along with a synopsis of the changes, to the PMO (spec-submit
@jcp.org) at any time up until the last 7 days of the review period. (The draft is frozen during the last 7 days of Community Review in order for the EC to complete their Draft Specification Approval Ballot). The PMO will notify Members of any updated drafts and change synopses received via the jcp-interest alias, and make them available for download.
If your draft is not approved by the EC, the EG has 30 calendar days to revise the draft for a reconsideration ballot. If you plan on submitting a revised draft, please notify the PMO (pmo
@jcp.org) as soon as possible. If you have reason to believe that your draft may not be approved, you might want to start on revising the draft earlier. Working with your EG and lobbying the voting EC members reduces the risk of no votes. You can find information on the current voting EC Members for your draft at:
http://jcp.org/en/participation/committee
If your JSR is operating under JCP 2.6 or newer, the first milestone of your JSR will be
Early Draft Review.
Please inform the PMO (spec-submit
@jcp.org) as soon as possible of the approximate date for the Early Draft Review to allow preparation time.
Once the EG agrees that you are ready for feedback from the public on the draft of your spec please submit it to the PMO (spec-submit@jcp.org) via e-mail with the JSR number and "Early Draft Review" or "EDR" in the subject line. Please note that this review is open to the public. This review occurs early in the process and does not have a ballot at the end of it. This is designed to encourage Expert Groups to feel comfortable going into this review with open issues and questions that they would like the public to help them resolve.
The PMO will host your draft and provide the export classification and spec license for you. If you wish to have the spec license text to embed in your spec document, please send item #6, below, to admin
@jcp.org beforehand. The license should be provided within 2 business days of receipt.
When submitting the draft please provide the following:
- The Spec, in pdf or zip format (be aware that Javadoc files must be zipped)
The PMO will provide a standard evaluation license unless you choose to provide your own.
- The alias for comments. You need to share all comments received during the review with your EG. It is also very important that you acknowledge these comments.
- The length of the Review (30, 45, 60 or 90 calendar days). During the review you can increase the length to the next increments.
- The answer to the following questions.
A. Does the specification include software codes
in the following format:
Binary : Yes _______ No __________
Source (compilable) : Yes _______ No __________
Javadocs : Yes _______ No __________
B. Do the codes or the spec call on, contain, use or demonstrate encryption technology?
Yes _________ No ________
If yes, please describe in detail
- A draft of the anticipated Business Terms. These terms are made available to the EC for comment. Please provide the draft of the business terms to the PMO. At the minimum this draft needs to include the licensing model and the anticipated licensing fees that you expect to apply to the Final Release of the RI, the TCK and the specification. Your Marketing Department can help you with this part of the requirements. Please look in the 'Writing a JSR' section above for licensing templates. You can use one of these templates or any other licensing model provided that the compatibility requirements in the appropriate JCP document are addressed. The lastest version is JCP 2.6 found at: http://jcp.org/en/procedures/jcp2
- The version number of the specific specification document you are submitting, the anticipated release date, and the full corporate name and address of the Spec Lead Member.
Turnaround time: With any public posting of a spec to jcp.org, the PMO will post the spec and related materials within 10 business days of receiving
all the above materials at spec-submit
@jcp.org.
You can choose more than one EDR.
You are encouraged to be proactive about including Spec Leads and Expert Group members from other JSRs in your review period. Communication between JSRs is invaluable in developing the most successful technologies.
This is the first stage in the JSR process where companies are allowed to specifically begin talking in press releases and other public venues about the JSR and their company's plans to produce products that implement it. Until the Early Draft Review Stage is reached, JSR access is only open to Expert Group members. Please consult the JCP PR and Communication Guidelines for more information.
At this point the PMO recommends you begin with the scheduling and planning of your RI and TCK. A stable RI and well planned TCK require careful scheduling. Starting early will make the preparation the required TCK documentation for FAB less time consuming. The TCK Coverage Document requires little effort if it is started in the EDR stage. Please see the requirements in the FAB section below and in the 'Developing TCKs' section below.
Please note that you cannot enter any Review period until all of your deliverables are submitted.
During each review period you may receive good suggestions that you wish to incorporate into the Spec. You and the EG may revise the Spec. In the case of major revisions to the draft during the review, you should send the revised draft, along with a synopsis of the changes, to the PMO (spec-submit@jcp.org) at any time The PMO will notify Members of any updated drafts and change synopses received via the jcp-interest alias, and make them available to them for download.
This is the first stage in the JSR process where press releases are allowed. Until the Public Review Stage is reached the JSR access is only open to JCP members. Please consult the
JCP PR and Communication Guidelines.
Once you and your EG are ready to have the Public review your draft you submit all materials as detailed below to the PMO (spec-submit
@jcp.org) via e-mail with the JSR number and "Public Review Draft" in the subject line.
The PMO will host your draft and provide the export classification and spec license for you. If you wish to have the spec license text to embed in your spec document, please send item #7, below, to
admin
@jcp.org beforehand. The license should be provided within 2 business days of receipt.
- The Spec, in pdf or zip format (be aware that Javadoc files must be zipped). The PMO will provide a standard evaluation license unless you choose to provide your own.
Please note: Any drafts posted for review must remain on the site as a record of the spec's development and will not be removed.
- The alias for comments. You can use the JSR comments alias if you wish for this or choose another alias.
- the length of the Review (30, 45, 60 or 90 days).
- The answer to the following questions.
A. Does the specification include software codes
in the following format:
Binary : Yes _______ No __________
Source (compilable) : Yes _______ No __________
Javadocs : Yes _______ No __________
B. Do the codes or the spec call on, contain, use
or demonstrate encryption technology?
Yes _________ No ________
If yes, please describe in detail
- An anticipated date when the PMO will receive the Proposed Final Draft specification
- If you are operating under JCP 2.1, the location for hosting your draft, if you are hosting it. In this case, you must submit your Evaluation license for the draft Spec. For a template of Sun's evaluation license please send your request to the PMO (pmo@jcp.org).
- The version number of the specific specification document you are submitting, the anticipated release date, and the full corporate name and address of the Spec Lead Member.
Turnaround time: With any public posting of a spec to jcp.org, the PMO will post the spec and related materials within 10 business days of receiving
all the above materials at spec-submit
@jcp.org.
If you are operating under JCP 2.1, you can choose more than one PR.
If you are operating under JCP 2.6 you may receive good suggestions during PR that you wish to incorporate into the Spec. You and the EG may revise the Spec. In the case of major revisions to the draft during Public Review you should send the revised draft, along with a synopsis of the changes, to the PMO (spec-submit@jcp.org) at any time up until the last 7 days of the review period. (The draft is frozen during the last 7 days of the Public Review in order for the EC to complete their Draft Specification Approval Ballot). If you are operating under JCP 2.1 there is no ballot at the end of PR which will allow you to make changes throughout the PR period. The PMO will notify Members of any updated drafts and change synopses received via the jcp-interest alias, and make them available for download.
If your draft is not approved by the EC, the EG has 30 calendar days to revise the draft for a reconsideration ballot. If you plan on submitting a revised draft, please notify the PMO (pmo@jcp.org) as soon as possible. If you have reason to believe that your draft may not be approved, you might want to start on revising the draft earlier. Working with your EG and lobbying the voting EC members reduces the risk of no votes. You can find information on the current voting EC Members for your draft at: http://jcp.org/en/participation/committee
.
Once the EG agrees that you are ready to go final with the Spec, you will release a Proposed Final Draft. This final draft allows the EC, JCP Members and the Public to review the Spec before it goes to the EC for the Final Approval Ballot. As with previous drafts when submitting this Proposed Final Draft, you need to submit it to the PMO (spec-submit
@jcp.org) via e-mail with the JSR number and "Proposed Final Draft" in the subject line.
The PMO will host your draft and provide the export classification and spec license for you. If you wish to have the spec license text to embed in your spec document, please send item #6, below, to
admin
@jcp.org beforehand. The license should be provided within 2 business days of receipt.
Please submit the draft to the PMO and providing the following:
- The Spec, in pdf or zip format (be aware that Javadoc files must be zipped). The PMO will provide a standard evaluation license unless you choose to provide your own.
- The alias for comments.
- The PMO recommends that you allow sufficient time between the Proposed Final Draft and the Final Approval Ballot for comments from the Public.
- An anticipated date when the PMO will receive the materials for the FAB.
- The answer to the following questions.
A. Does the specification include software codes
in the following format:
Binary : Yes _______ No __________
Source (compilable) : Yes _______ No __________
Javadocs : Yes _______ No __________
B. Do the codes or the spec call on, contain, use
or demonstrate encryption technology?
Yes _________ No ________
If yes, please describe in detail
The PMO will use this information to update the Export Classification Control Number (ECCN) for you.
- The version number of the specific specification document you are submitting, the anticipated release date, and the full corporate name and address of the Spec Lead Member.
Turnaround time: With any public posting of a spec to jcp.org, the PMO will post the spec and related materials within 10 business days of receiving
all the above materials at spec-submit
@jcp.org.
After you have incorporated any changes you decided to make after the Public has reviewed your PFD, you are ready to go final with the Spec, RI and TCK. You need to submit the Final materials to the PMO (spec-submit
@jcp.org) to put on the EC Final Approval Ballot. As with JSR Approval Ballot the PMO must receive all the materials of your submission on or before the Wednesday before the Tuesday that you wish the Ballot to start. The Final Approval Ballot runs for a 2 week voting period starting on Tuesday and ending on Monday, midnight PST/PDT. Once again it is good practice to get a sense of the voting EC's opinion on what you consider to be the Final version of your JSR. It is necessary that you are available during the voting period or you designate someone that will be able to respond any questions the voting EC may have.
When submitting the Final Spec to the PMO please provide the following:
- The completed questionnaire, found at: http://jcp.org/aboutJava/communityprocess/speclead/final-questions.txt.
- The Final Spec, in pdf or zip format (please note that Javadoc files must be zipped), the Final Reference Implementation, and the Final Technology Compatibility Kit (both in .zip format).
- The PMO hosts the Final Approval Ballot for you, and uses Sun's general FCS license unless you provide your own FCS license. Please be sure to provide the PMO with the version number for your spec and with the full legal name of your company or organization for the license.
- The PMO will get the update of the ECCN for you.
- The alias for comments.
- The final business terms for the RI and TCK. The business terms must address compatibility. 3rd party implementations must pass the TCK.
Please note, any JSR developed under JCP 2.6 or later must allow for independent implementations.
JSRs under JCP 2.6 or later must also license the RI and TCK separately and provide no cost access of TCKs to qualified individuals, educational and not for profit organizations.
- The TCK Coverage Document. This is a one- to two-page summary to assist the EC in evaluating the TCK. Please see more details in the 'Developing TCKs' section below.
- The final licensing model, usually integrated in the Business Terms. Please look in the "Writing a JSR" section above for licensing templates. You can use one of these templates or any other licensing model provided the compatibility requirements as demanded in the appropriate JCP Document are addressed. The latest version is JCP 2.6, found at: http://jcp.org/en/procedures/jcp2
- The name and contact info of the Maintenance Lead. In case the Maintenance Lead is a different company or organization the PMO requires an authorization from an Executive of the current Spec Lead company or organization relinquishing interest in the JSR. The same applies for a Spec Lead change earlier in the JSR process.
- The URL of the Maintenance Lead's Change Log. If you do not provide a Change Log, the PMO will create one for your JSR.
- In addition you should establish a first level TCK Appeals Process per JCP Document section 3.2.2. to handle challenges to the tests in the TCK.
Assuming the Final Approval Ballot is successful, please notify the PMO at your earliest convenience when you will be submitting the materials for Final Release.
If the ballot does not succeed, you have 30 days to consider the EC comments, revise your materials, and resubmit them for a Final Reconsideration Ballot. These are conducted the same as the initial Final Approval Ballot. If you plan on submitting materials for Final Reconsideration Ballot, please notify the PMO via spec-submit
@jcp.org as soon as possible. If the initial Final Approval Ballot fails and you do not submit for Final Reconsideration Ballot within 30 days or you do submit and the Final Reconsideration Ballot is also voted down by the EC, the JSR is marked as Rejected and the Expert Group disbands.
If the Final Reconsideration Ballot is approved by the EC, you will proceed to Final Release normally. Please notify the PMO at your earliest convenience when you will submit the materials for Final Release.
Now that the EC has approved your Specification, RI and TCK through the Final Approval Ballot, you can go public with the Final Release. Note that this does not happen automatically after the Final Approval Ballot. The Final Release must follow the FAB within a reasonable time frame. The PMO will contact you if the material for the Final Release has not been received within approx 4 weeks after a successful Final Approval Ballot. To post a Final Release, you need to submit the following to the PMO (spec-submit
@jcp.org), specifying the JSR number and "Final Release" in the subject line.
- The Spec, in pdf or zip format (please note that Javadoc files must be zipped).
- The PMO hosts the Final Release for you, and uses Sun's general
FCS license unless you provide your own final license. Please be
sure to provide the PMO with the version number for your spec and
with the full legal name of your company or organization for the
license. Note: providing your own license can delay the posting
due to necessary legal review of your final license.
- The alias for comments.
- An URL and detailed description of how interested parties can get the RI and TCK.
- The URL for your Change Log.
- The Export classification for the RI & TCK. Please contact your Trade Affairs or Legal Dept to get the ECCN. If you need help with this classification please contact the JSR Program Manager.
Once all these pieces are received, the PMO will post your JSR (see "Turnaround time", below) as having gone Final and announce it to the jcp-interest list. At that point your Expert Group is normally dissolved and the Maintenance process begins. Some Spec Leads decide to keep working with their Expert Groups.
Turnaround time: With any public posting of a spec to jcp.org, the PMO will post the spec and related materials within 10 business days of receiving
all the above materials at spec-submit
@jcp.org.
Listen to the audio tutorial on the JSR Maintenance process.
The Maintenance Review is an optional stage. You may choose to leave your JSR as FR or choose a new JSR instead.
For a Maintenance Review, you will need to submit the following to the PMO (spec-submit@jcp.org) via e-mail, specifying the JSR number, and "Maintenance Review" in the subject line:
- The alias for comments (this may be the Maintenance Lead's email address).
- The length of the Review (30, 45, 60 or 90 calendar days).
- The current URL for your Change Log, or the list of proposed changes for posting on jcp.org. IMPORTANT: if supplying the list of changes for posting on jcp.org, make sure that you provide just the list of changes - the PMO posts these changes in a table labeling them as proposed, accepted, or deferred. At the close of review, the list of proposed changes will be moved automatically to the approved/deferred sections as appropriate, so including your own label of the list of changes as proposed would be confusing for the community.
The PMO takes the information you provide and posts it to the web site. When it is ready, the Maintenance Review is announced to the community and the Executive Committee. After the close of review, proposed changes are automatically approved unless deferred by the Executive Committee by an Item Exception Ballot. No resubmission of the change log is necessary, unless you have new items to add to the proposed section of the change log.
Note that no updates may be made to the Change Log during the last week of the Review.
Turnaround time: When you post a Change Log for Maintenance Review, the PMO should have the web site updated with the Maintenance Review within 2 business days of receiving
all of the above materials.
NOTE: these are the requirements for posting a Change Log alone. If you wish, you may also submit a draft version of the specification that illustrates the proposed changes. If you wish to do this, you will also need to submit the following:
- The Spec, in pdf or zip format (be aware that Javadoc files must be zipped). The PMO will provide a standard evaluation license unless you choose to provide your own. Note that any license must be an evaluation-only license for Maintenance Review, since the changes you are proposing have not been approved by the Executive Committee at this stage.
- The answer to the following questions.
A. Does the specification include software codes
in the following format:
Binary : Yes _______ No __________
Source (compilable) : Yes _______ No __________
Javadocs : Yes _______ No __________
B. Do the codes or the spec call on, contain, use
or demonstrate encryption technology?
Yes _________ No ________
If yes, please describe in detail
The PMO will use this information to update the Export Classification Control Number (ECCN) for you.
- The version number of the specific specification document you are submitting, the anticipated release date, and the full corporate name and address of the Spec Lead Member.
Turnaround time: With any public posting of a spec to jcp.org, the PMO will post the spec and related materials within 10 business days of receiving
all the above materials at spec-submit
@jcp.org.
At the close of review you will have a list of changes that have been approved and a list of changes that have been deferred to a major revision (requires a new JSR). Update the Change Log accordingly.
Grandfathered JSRs (Specifications that have been developed outside the JCP) that are coming into the JCP enter at this stage and are assigned a 9xx number. If you are the Maintenance Lead for one of these Grandfathered JSRs you are responsible to provide the above listed materials.
Updating a JSR's Change Log during review: as the Maintenance Lead receives feedback on the proposed changes, sometimes changes to the list of proposed changes need to be made. Such updates are submitted just as the original review materials were submitted and will be posted to the Change Log up to the final week of the review, when the change log cannot be changed (as there is the potential Item Exception Ballot there). If the turnaround time to post the submission means that the update cannot be made before that deadline, Maintenance Leads have two options: extend the length of the review (from 30 to 45 days, 45 to 60, or 60 to 90) or to hold a second Maintenance Review shortly after the first completes.
Changes submitted after the completion of a Maintenance Review are always proposed changes. They must go through another Maintenance Review and be approved by the Executive Committee before they can be listed as approved.
After a successful Maintenance Review you may opt to prepare a Maintenance Release, a new JSR submission, or both. Note that "DEFERRED" items may not be placed in a Maintenance Release but must go into a new JSR. The Maintenance Release process is like the Final Release Process.
To post a Maintenance Release, you need to submit the following to the PMO (spec-submit
@jcp.org), specifying the JSR number and "Maintenance Release" in the subject line:
- The Spec, in pdf or zip format (please note that Javadoc files must be zipped, and the spec file must be set up with a click-through license).
Please be advised that your Final Product License for your Spec must ensure compatibility.
- The alias for comments.
- An URL or detailed description of how interested parties can get the RI and TCK.
- The URL for your Change Log.
- The answer to the following questions.
A. Does the specification include software codes in the following format:
Binary : Yes _______ No __________
Source (compilable) : Yes _______ No __________
Javadocs : Yes _______ No __________
B. Do the codes or the spec call on, contain, use
or demonstrate encryption technology?
Yes _________ No ________
If yes, please describe in detail
Turnaround time: With any public posting of a spec to jcp.org, the PMO will post the spec and related materials within 10 business days of receiving
all the above materials at spec-submit
@jcp.org.
A good Technology Compatibility Kit (TCK) is critical to insuring that independent implementations of the Specification are compatible with the Specification and each other. The JCP PMO does not impose requirements for these TCKs, but relies on the expertise within the Expert Group to provide feedback to the Specification Lead on the quality of the TCK. The PMO does, however, provide some Guidelines for Developing TCKs,
http://jcp.org/en/resources/tdk/.
Implementation conformance to a specification. NOT application portability (though it's related).
Compatibility provides assurance that:
|
Implementations match the specification
Implementations all meet (at least) a minimum level of quality
Developers can write to a specification rather than an implementation
|
| Test Suite |
|
Tests designed to demonstrate and verify implementation compliance to its specification.
|
| Test Framework |
|
Defines the particular test environment used by the test harness to run the tests and collect test results.
|
| Exclude List |
|
Provides a means to remove invalid tests.
|
| Test Harness |
|
Tool to automate testing for:
|
Selection
Scheduling
Execution
Reporting
Assures all required tests are run and pass.
Tests can easily be rerun for debugging purposes.
Very difficult to manually manage testing without introducing human error.
|
|
| Documentation |
|
How to Run the Test Suite
Compatibility Requirements
Appeals Process
Supporting Tools Documentation
|
