Version 1.0 (December 1998)
Comments to: email@example.com
Java Software, Sun Microsystems, Inc.
Copyright (c) 1996 - 1998 Sun Microsystems, Inc.
1. Propose a New Specification
2. Selection of a JSR for Development
3. Form the Expert Group
4. Working Within the Expert Group
5. Write the Participant Draft
6. Review and Refine the Participant Draft
7. Public Review
8. First Public Release
9. Final Release
10. Interpretation Guru
Appendix A: Java Specification Request (JSR) Format
THE JAVA COMMUNITY PROCESSSM PROGRAM
Sun Microsystems, Inc., is implementing a formal process for developing
Java specifications that produces high-quality specifications in
"Internet-time" using an inclusive, consensus building process that not
only delivers the specification, but also the reference implementation
and its associated suite of compatibility tests.
Our experience has proven that the best way to develop a specification
is to start with a handful of industry experts who have a deep
understanding of the technology in question and then have a strong
technical lead work with them to create a first draft. Consensus is
then built using an iterative review process that allows an
ever-widening audience to participate and to see their comments and
suggestions incorporated into successive draft versions of the
specification prior to its final release.
The recent additions to our process have been to:
These new procedures are designed to allow for wider participation in
the early stages of specification development and to provide an extra
level of assurance to the international Java community that all steps
of the process have been properly carried out by all parties involved
and that a given specification can be implemented and tested for
- Refine and formalize the steps,
- Allow companies, organizations, and individuals who have not
licensed Java technology from Sun Microsystems to formally participate
in the Specification development process,
- Enable companies, organizations, and consortia to use this process
for developing Java specifications with or without the direct
involvement of Sun Microsystems, Inc. engineers.
- Have an independent auditing firm review the process at key
milestones to uncover and correct any anomalies before they become a
- Have the independent auditor carry out a final, overall, audit at
the end of the process and then issue a final public report at a 3rd
party web-site not under the control of either Sun or the auditor,
- Require a reference implementation and the associated suite of
conformance tests to be developed along with the specification.
THE JAVA COMMUNITY PROCESSSM PROGRAM
There are 11 steps to the Java Community Process. Each step is
described in its own section below. Terms are defined in their
1. PROPOSE A NEW SPECIFICATION
DEFINITION - Java Specification (Specification): A written
specification for a Java Application Programming Interface (API).
DEFINITION - Specification Development Process (Process): The
formal, auditable process for developing Specifications that is
described in this document.
DEFINITION - Process Management Office (PMO): The group
within Sun Microsystems, Inc. designated to oversee the development of
DEFINITION - Java Technology Licensee (Licensee): A
company, organization, or individual that has entered into a commercial
license for Java technology with Sun Microsystems, Inc. and is not in
breach of that agreement.
DEFINITION - Java Specification Participation Agreement
(JSPA): A one-year, renewable, agreement between Sun
Microsystems, Inc. and a company, organization, or individual that
allows the latter entities to participate in the Process. Licensees
are required to sign a JSPA to participate in the Process.
DEFINITION - Java Specification Participant (Participant): A
company, organization, or individual that has entered into a Java
Specification Participation Agreement with Sun Microsystems, Inc.
DEFINITION - Java Specification Request (JSR): The form
submitted to the PMO by one or more Participants proposing the
development of a new Specification.
Participants can submit a request to develop a new Specification, or
make a major revision to an existing one, by filing a Java
Specification Request (JSR) with the PMO. The format of the JSR is
described in Appendix A. Briefly, the JSR serves to identify the
submitter, identify the other Participants who support the request (if
any), describe the proposed Specification, the reason(s) for developing
it, the target Java platform(s), and any pre-existing documents,
technology descriptions, or implementations that might be used as a
starting point. A Participant can have up to thre e JSRs under
consideration by the PMO at any given time (a JSR is defined to be
under consideration from the time it is filed with the PMO up until it
is either accepted for development into a Specification or rejected and
returned). Any JSR that is under consideration can be withdrawn by its
submitter for whatever reason upon written request to the PMO.
2. SELECTION OF A JSR FOR DEVELOPMENT
Once a JSR has been submitted, the PMO will evaluate it for
completeness. The JSR will be automatically rejected by t he PMO if
- Does not provide all of the requested information (see Appendix A).
- Conflicts with, or substantially duplicates, a Specification that is currently under development.
- Conflicts with, or substantially duplicates, an existing Specification.
The PMO will inform the submitter of the specific reason(s) for
rejection. The submitter has the option of amending the JSR to address
the problem(s) and then re-filing it with the PMO.
The PMO will post all other JSRs to the Participant Web Site for JSR Review.
DEFINITION - Participant Web Site: The designated Sun web
site that is accessible only to Participants. It serves to disseminate
information of interest to Participants and to gather their feedback.
DEFINITION - JSR Review: A period of at least 7 days but no more than 30 days during which time the
JSR is posted at the Participant Web Site for review and comment by all Participants.
At the end of JSR Review, the PMO will review the comments received and
decide whether to accept the JSR for development, reject it, or defer a
final decision while more information is gathered from the
submitter(s), other Participants, and/or experts in the technology in
3. FORM THE EXPERT GROUP
DEFINITION - Expert: An active practitioner who has
expert knowledge in the technology area covered by a JSR and is a
full-time employee of a Participant. These are typically senior
engineers engaged in product design and development who have been
involved in designing and building products that are closely related to
DEFINITION - Expert Group: The group of Experts who develop a
Specification using the Process. There will generally be no more than
one Expert from a given Participant on the Expert Group.
DEFINITION - Specification Lead: The Expert responsible for
writing the Specification with input from the other Experts, and hence
responsible for developing consensus within the group. This person
must possess strong diplomatic and writing skills as well as technical
The actions of the Expert Group are coordinated by the Specification
Lead - the Expert responsible for writing the Specification with input
from the other members of the Expert Group. He or she will ultimately
be responsible for developing and maintaining consensus within the
group as well as rendering tie-breaking decisions based on his or her
technical and design knowledge when general consensus cannot be
The PMO forms the Expert Group by issuing a "CAll For Experts" (CAFE)
to all Participants. The CAFE asks Participants who wish to volunteer
one of their employees to serve on the Expert Group to identify both
themselves and their expert to the PMO. These Participants must
provide the PMO with:
- A summary of how the Participant has used or developed the technology in question.
- The name of the employee the Participant proposes to contribute to the Expert Group, and
- The qualifications and biographical information of that employee.
The CAFE will be open for at least 15 days. When the CAFE closes, the
PMO will evaluate the qualifications of the proposed Experts and select
a Specification Lead from among them. This person need not be a Sun
DEFINITION - Reference Implementation (RI): The "proof of
concept" implementation of the Specification that will be made
available by Sun Microsystems, Inc. The Participant whose Expert is
chosen as Specification Lead is typically responsible for producing the
DEFINITION - Compatibility Test Suite (CTS): The suite of
tests and requirements that an implementation of the Specification must
pass in order to be considered compliant with the Specification. The
Participant whose Expert is chosen as Specification Lead is typically
responsible for producing the CTS.
It's important to note that the Participant whose Expert is the
Specification Lead typically assumes the responsibility of producing,
maintaining and licensing both the Reference Implementation (RI) and
its associated Compatibility Test Suite (CTS).
Note that the Participant who is responsible for the RI and CTS does
not necessarily have to produce these items personally. The
responsible Participant can arrange to produce the RI and/or CTS in
cooperation with other Participants who have contributed Experts to the
Expert Group or delegate that task completely to one or more of these
Once chosen, the first duty of the Specification Lead is to select the
other members of the Expert Group from the remaining list of nominees
based on both their qualifications and on the need to preserve
diversity of opinion within the group. While there is no specific
limit on the size of an Expert Group, experience has shown that smaller
groups are usually more effective.
It is possible that the Specification Lead may feel it essential to
include experts from Participants who did not respond to the CAFE. In
this case, the Specification Lead may approach these Participants and
try to work with them to identify their expert and bring them into the
Expert Group. The Specification Lead can also add additional Experts
later in the Process if he or she can justify to the PMO that they
would significantly enhance the technical quality of the
Specification. The PMO can also elect to add a Sun Expert to the
Expert Group at any time during the Process (provided one is not
already in the group).
Participants who responded to the CAFE but were not selected to serve
on the Expert Group possess focussed expertise and skills that may be
of considerable use to the Expert Group during the Process. The Expert
Group will therefore retain the complete list of CAFE respondents so
they can call upon some or all of the respondents as needed to help the
Expert Group understand and/or resolve specific technology issues.
Once the Expert Group has been formed, the Independent Auditor will
carry out the first Milestone Audit of the Process. After any auditing
anomalies have been corrected, the Experts must attend a "kick-off"
meeting held by Sun Microsystems' Java Software Division. This meeting
will serve to introduce the Experts to one another, give them an
understanding about how the Process will proceed, and provide them with
audit training so that all Experts will understand what they must do to
DEFINITION - Independent Auditor: The external
company designated by Sun to be responsible for auditing each use of
4. WORKING WITHIN THE EXPERT GROUP
Each Expert Group is free to define and follow whatever working style
it finds most productive and appropriate (subject to the auditing
requirements of the Independent Auditor). However, experience gained
from carrying out more than 30 successful Specifications projects using
the Process has shown that the most straightforward and consistently
successful approach to producing high-quality Specifications in a
timely manner is for the Specification Lead to gather most of the
technical information and input from each Expert in a pair-wise fashion
while writing and revising the Specification. As this information is
incorporated the Specification Lead should frequently distribute
updated versions of the Specification to the Experts for all to see.
E-mail exchanges within a private mailing list established for the
exclusive use by the Expert Group, along with conference calls and
group meetings, are then used to discuss and resolve issues raised by
the Experts as they review the evolving contents of the document. Note
that in-person group meetings should perhaps be used sparingly as they
tend to slow the Process down considerably due to the need to
It is recognized that an Expert may withdraw from the Expert Group
during the Process. In this case, the Specification Lead will approach
the Participant who originally contributed the Expert and work with
them to find a replacement. If no replacement can be found, the
Specification Lead should recruit the replacement from among the
original group of Participants who responded to the CAFE but were not
selected for the Expert Group. If that fails, the Specification Lead,
in consultation with (and approval of) the PMO, can try to recruit a
replacement from Participants who did not respond to the CAFE. If the
departing Expert is the Specification Lead, a new Specification Lead
will be recruited by the PMO after consultation with the remaining
members of the Expert Group.
There may be instances where members of the Expert Group feel that one
or more of their fellow Experts are not acting in ways that advance the
work of the Expert Group. These concerns should be brought to the
attention of the Specification Lead and/or the PMO so quickly as
possible so they can be proactively addressed and resolved.
5. WRITE THE PARTICIPANT DRAFT
DEFINITION - Participant Draft: The first draft of
the Specification that the Specification Lead, in consultation with the
other Experts, prepares for review by Participants.
The Expert Group begins work by considering the requirements set forth
in the JSR, any pre-existing documents, technology descriptions, or
implementations identified in the JSR, the comments received from
Participants during JSR Review and, if this is a revision of an
existing Specification, the Change Log kept by the Interpretation Guru
(see section 11, Maintenance, for details). Additional input should
then be obtained from the Java community by having discussions with
other Participants, industry groups, software developers, end-users,
and academics. The intent is to gather as much information as possible
from those with expertise and a material interest in the technology.
The goal of this step is to define requirements and then produce a
draft of the Specification that is suitable for review and comment by
When the Specification Lead, in consultation with the other Experts,
decides that the Participant Draft is ready for distribution, the
Specification Lead will notify the PMO to initiate the associated
Milestone Audit. Any auditing anomalies must be corrected before
Participant Review can begin.
The Experts are encouraged to carry out prototype engineering work
while writing the Participant Draft. This work will serve to solidify
the concepts and ideas that are being incorporated into the draft.
6. REVIEW AND REFINE THE PARTICIPANT DRAFT
DEFINITION - Participant Review: A period lasting at
least 30 days during which Participants can review and comment on the
original Participant Draft and any revisions issued by the Expert Group
during this time.
The iterative refinement of the Specification begins when the
Participant Draft is distributed to Participants for Participant
Review. The goal of Participant Review is to get the Specification
draft into a form suitable for Public Review quickly. The review
period must be at least 30 days. The precise number of days is set by
the Specification Lead (in consultation with the other Experts) and is
ultimately determined by the number and the type of Participant
comments balanced against the need to complete the Participant Review
in a reasonable period of time.
All Participant comments will be assigned a unique identification
number. The Specification Lead is responsible for ensuring that all
Participant comments are considered and responded to. Responses to
similar comments from multiple Participants may be responded to as
The Participant Draft may be revised based on comments from
Participants. If, in the general opinion of the Expert Group, those
revisions result in major changes, the Specification Lead will arrange
for a revised Participant Draft (along with a synopsis of the changes
made) to be re-circulated to the Participants. This posting of revised
Participant Drafts may be repeated as necessary throughout the
Participant review period.
Following the end of Participant Review, the Specification Lead will
have up to 30 more days to make any final revisions to the Participant
Draft in preparation for the next Milestone Audit.
At this point, the Specification should be in good enough shape for the
Participant responsible for the RI and CTS to develop an implementation
project schedule and begin work. In general, the Reference
On or before the end of the 30 days, the Specification Lead will inform
the PMO that the Participant Draft is complete and submit the RI/CTS
project schedule to the PMO. The PMO will then initiate the Milestone
Audit. Any auditing anomalies must be corrected before the Public
Review period can begin.
- Be written in the Java programming language as much as possible,
- Be as platform-independent as possible,
- Make as much use of existing Java core classes as possible, and
- Not utilize any private classes and methods defined inside those core classes.
7. PUBLIC REVIEW
DEFINITION - Public Review: A period lasting for at
least 30 days during which time the general public can review and
comment on the original Public Draft and any subsequent revisions
issued by the Expert Group.
DEFINITION - Public Web Site: Sun's public web site
where Java Specifications are available for download. The URL for this
site is http://java.sun.com.
DEFINITION - Public Draft: The refined and improved
draft of the Specification that the Expert Group prepares for Public
Upon successful completion of the Milestone Audit, the Specification is
promoted to Public Draft and is published on the Public Web Site for
Public Review. In keeping with the goal of web-wide participation,
anyone with access to the Internet can download and comment on the
Public Draft of the Specification. Like Participant Review, Public
Review will last for at least 30 days. The precise number of days is
set by the Specification Lead, in consultation with the other Experts,
and is ultimately determined by the number and the type of Public
comments balanced against the need to complete the Public Review in a
reasonable period of time.
Public Review is a critical part of the development process. In the
past, comments from the public have raised fundamental architectural
and technology issues (missed by both the Expert Group and Participant
Review) that have considerably improved Java Specifications.
The Specification Lead is responsible for ensuring that all Public
comments are read and considered. If those comment s result in
revisions to the Public Draft, and those revisions result in major
changes (in the general opinion of the Experts), then the Specification
Lead will arrange for the revised Public Draft, along with synopses of
the changes made, to be re-posted to the Public Web Site.
Following the end of Public Review, the Specification Lead will have up
to 30 more days to complete any final changes to the Public Draft in
preparation for the next Milestone Audit. On or before the end of the
30 days, the Specification Lead will inform the PMO that the Public
Draft is complete so the PMO can initiate the associated Milestone
Audit . Any auditing anomalies must be corrected before the First
Public Release of the Specification.
8. FIRST PUBLIC RELEASE
Upon successful completion of the Milestone Audit, the Specification is
made available for download at the Public Web Site.
It is possible that the Reference Implementation and Compatibility Test
Suite may uncover areas of the Specification that were under-defined,
incomplete, or ambiguous. The Specification Lead, in consultation with
the responsible Participant and the other members of the Expert Group,
will correct any deficiencies in the Specification that may be
uncovered. If changes are necessary, the Specification Lead will
arrange to re-post the revised Specification, along with synopses of
the changes made, at the Public Web Site at least once a month while
the RI and CTS are being developed. Public comments on the corrections
will be accepted and considered by the Specification Lead as per the
process used during Public Review.
The Specification Lead will promptly report any delays in the RI/CTS
project schedule to the PMO and provide an updated project schedule
along with each such report. Excessive problems or delays in the
completion of either the RI or CTS may result in the PMO reassigning
these tasks to another Participant who is better able to complete
them. In this latter case, the PMO may also need to appoint a new
Specification Lead for the remainder of the Process.
When the Specification Lead, in consultation with the other Experts and
the PMO, is satisfied that the CTS provides adequate test coverage, the
RI adequately implements the Specification, and the RI passes the CTS,
the Specification Lead will inform the PMO that the Process is
complete. The PMO will then initiate the Final Audit. Any auditing
anomalies must be corrected before the Specification can be promoted to
DEFINITION - Final Audit: The audit of the entire
Specification Development Process that is carried out by the
Independent Auditor prior to Final Release of the Specification.
The Final Audit report will be posted on a 3rd party web site that is
not under the control or influence of either Sun Microsystems, Inc. or
the Independent Auditor.
9. FINAL RELEASE
The PMO will arrange for the completed Specification to be placed on
the Public Web Site. Upon Final Release, the Expert Group will have
completed its work and disbands.
10. INTERPRETATION GURU
The Interpretation Guru handles maintenance of the Specification. The
Specification Lead will take on this role at the time of Final
Release. This is one of the duties that both the Specification Lead,
and his or her organization, agrees to as a condition of being
appointed to the role. Every released Specification must have an
assigned Interpretation Guru and it is the responsibility of the
Interpretation Guru, in consultation with (and approval of) the PMO, to
recruit a replacement if he or she is unable or unwilling to either
take on this responsibility or to continue with this responsibility
going forward. The replacement should be recruited from one of the
Participants who contributed an Expert to the former Expert Group or,
with the approval of the PMO, from one of the other Participants. In
exceptional cases, the PMO may choose to appoint a new Interpretation
Guru when the departing Interpretation Guru is unable to locate a
The Interpretation Guru is responsible for drafting proposed changes to
the Specification in response to requests for clarification,
interpretation, enhancements, and changes that are received from
Participants and the public via the designated e-mail address published
with the Final Release. All such requests will be assigned unique
identifying reference numbers and logged. The Interpretation Guru will
review all comments, identify common themes, and maintain a public list
of frequently raised issues and their status.
The Interpretation Guru is free to consult with the former members of
the Expert Group, or any other source, for input on how to revise the
Specification in view of the issues raised in the requests. All such
changes proposed by the Interpretation Guru will make their way into
the Specification by either the lightweight maintenance process defined
below or by the full Process when a major revision to the Specification
DEFINITION - Change Log: A public document available
on the Public Web Site that lists all revisions made to the
Specification by the Interpretation Guru during Maintenance. There are
three sections: proposed (revisions not yet integrated into the
Specification), accepted (revisions that have been made), and deferred
(revisions held over for consideration by a future Expert Group formed
to carry out a major revision using the Process).
The lightweight process runs as follows: the Interpretation Guru will
log all proposed changes in the "Proposed" section of the
Specification's public Change Log. Such changes should be consistent
with the public list of frequently raised issues. An e-mail
notification of the proposed changes will be sent to all Participants
and anyone else who has signed up to be notified of changes to the
Specification (sign-up is accomplished using an electronic form that
will be made available at the Public Web Site upon Final Release of the
Comments on proposed changes will be accepted from Participants and the
public for at least 30 days and logged on the public comment list. If,
at the end of that time, no strong opposition has been expressed by a
majority of the Participants or the PMO, the Interpretation Guru will
make the proposed changes to the Specification (with due consideration
to the comments received), document the changes in the "accepted"
section of the Change Log, and then delete the corresponding entries in
the "proposed" section of the log. All proposed changes that are not
incorporated into the Specification, or judged by the Interpretation
Guru to constitute a major revision that should be made using the
Process, will be moved from the "proposed" section to the "deferred"
section of the log.
Whenever the Specification is revised, the Interpretation Guru will be
responsible for reviewing the current CTS to determine what tests (if
any) need to be revised and then make sure those revisions are carried
out. The CTS is an integral and critical part of any Specification and
the Interpretation Guru is encouraged to augment the CTS to increase
its coverage even if no revisions have been made to the Specification.
Naturally, whenever there are revisions to either the Specification or
the CTS, the Interpretation Guru will be responsible for updating the
Reference Implementation to make sure it continues to pass the CTS and
stays synchronized with the Specification.
When a major revision is made to the Specification by the Process, the
Change Log will be made available to the new Expert Group so they can
consider all the changes that were placed into the "deferred" section.
Interpretation Guru may be replaced when the Specification is
superceded by the major revision since the Process allows for the
appointment of a new Interpretation Guru at the time of Final Release
of the revision.
APPENDIX A: Java Specification Request (JSR)
A JSR must conform to the following general outline and contain at least the following information:
Section 1. Identification
- The names and contact information of the Participants submitting the JSR.
- An optional list of other Participants who endorse the JSR.
Section 2: Request
- The target Java platform (i.e., desktop, server, personal, embedded, card, etc.).
- The need of the Java community this work addresses.
- An explanation of why the need isn't met by existing specifications.
- The Specification to be developed and how it addresses the need.
- Detailed description of the underlying technology or technologies.
- Proposed package name for API Specification (i.e., javax.something, org.something, etc.).
- Possible platform dependencies (such as an anticipated need for native code).
- Security implications.
- Internationalization implications.
- Localization implications.
- Risk assessment (impact of work on target platform, impact if work
not carried out, difficulties in carrying out RI and/or CTS).
- Existing specifications that might be rendered obsolete or deprecated by this work.
- Existing specifications that might need revisions as a result of this work.
Section 3: Contributions
- Detailed list of existing documents, specifications, or implementations that describe the technology.
- Explanation of how these items might be used as a starting point for the work.