Write a JSR |  Submit a JSR |  JSR Review |  EG formation |  Early Draft Review |  Public Review |  Proposed Final Draft |  Final Ballot |  Maintenance |  Spec Lead Guide  

This page lists detailed instructions for the Maintenance process for JSRs under JCP 2.1 through 2.7. For other versions, or for an overview of the Maintenance process, please return to the Spec Lead Guide: Maintenance Review page.

Listen to the audio tutorial on the JSR Maintenance process.

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 still follow the Maintenance process applicable to your JSR.
 

Maintenance for JCP 2.7 and earlier

For JCP 2.7 and earlier, Maintenance Release automatically follows the Maintenance Review, so the materials for both are submitted at the same time. To start a Maintenance Review, you must submit all the following to the PMO (spec-submit@jcp.org):

1. 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.
   
2. The desired length of the Maintenance Review, normally 30 - 90 calendar days (you may request a 14-day review for particularly trivial changes). During the review you can request to extend the length of the review by sending mail to admin@jcp.org at least two days before the scheduled end date (90 days is the maximum).
3. How the community provides feedback to you on the proposed changes
4. 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. This will be used to produce the final specification license.
5. The final Spec, in pdf or zip format (be aware that Javadoc files must be zipped). This will be used to post your Maintenance Release following the successful conclusion of your Maintenance Review
6. The location of the Reference Implementation (or detailed instructions on how to get it), available to the public for Maintenance Release
7. The location of the Technology Compatibility Kit (or detailed instructions on how to get it), available to the public for Maintenance Release
8. The revised final licenses for the RI and TCK, or confirmation that the licenses have not changed since the last release.
9. A detailed description of the process by which qualified individuals and educational or not for profit organizations can access the TCK at no cost.
10. The answer to the following questions, provided for each specification file you are submitting (ie, one set of answers for the specification .pdf file, another set of answers for the javadocs)
    

    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) from the US State Department for the posting of the Maintenance Release specification.
11. The name and contact information of the Maintenance Lead.

Note that the Executive Committee may take exception to one or more of the proposed changes. In that case, there may be an Item Exception Ballot to see if the change should be excluded from the Maintenance process, deferring it to a future JSR as a major revision to the specification.

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. The Maintenance Release should be posted within 2 business days of the close of the review.
 
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 (which requires a new JSR).
 
Updating a JSR's Change Log during review: as the Maintenance Lead receives feedback on the proposed changes, sometimes - rarely - the Maintenance Lead feels that further changes to the list of proposed changes need to be made. This is discouraged, as it can be perceived as misleading to the community, but still happens from time to time. 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 updated (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 (up to 90 days, which is the maximum) 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.

The PMO welcomes suggestions and requests from the Spec Leads for improvements of this guide and the process: pmo@jcp.org