There are two documents that define how the JCP is organized and how it
does its work: the Java
Specification Participation Agreement (JSPA), which is a legal contract
between members and Oracle, addressing Intellectual Property
grants and the terms
under which the Spec, RI, and TCK should be licensed, and the Process
Document, which defines the governance of the organization and the processes
that we use to develop and maintain JSRs.
Since we have a well-defined process for developing technical specifications,
it seemed sensible to use it to modify these constitutional
than to create something new. So, we use the Process to modify the Process,
by filing a special JSR. As Chair of the JCP I am the Spec Lead for these Process
while the Executive
Committee members form the Expert Group.
One such JSR is in progress now: JSR
348: Towards a new version of the Java Community was filed in May and
has just gone into Public Review. This JSR is focusing on relatively simple
changes that can
be implemented within about six months (we want to complete it before this
year's JCP elections in October.) For this reason it focuses only on changes
to the Process Document and to a new ancillary document that outlines the
Standing Rules for the operation of the ECs.
There will be two follow-on JSRs: the first will merge the two ECs into one
for greater efficiency and to encourage synergies between the Java platforms,
second will implement more complex changes, including any that require modifying
the JSPA. (Since the JSPA is a legal contract, changing it is a Big Deal, requiring
input from Real Lawyers.)
principal themes of JSR 348 are Transparency, Participation,
The Transparency changes will require that Expert Groups
conduct all of their business in public, using a public mailing-list and a
public issue-tracker. Similarly, the Executive Committee, which already publishes
all of its minutes and meeting materials (see here)
will be required to hold some public meetings and to create a public mailing
list for community feedback. Finally, there will also be some additional transparency
requirements around licensing, TCK testing, and the election process.
The Participation changes will require that requests to join Expert
Groups are published, will define formal processes for dealing with situations
where Expert Group members or Spec Leads are not performing their duties, and
will define penalties for Executive Committee members who do not attend meetings.
In the Agility area we intend to introduce time-outs for
JSRs, requiring them to reach various stages of the process within a defined
time or face the possibility of being shut down. We will also clarify the
Final Release and Maintenance processes to ensure
that Specifications, RIs, and TCKs are posted promptly.
Since JSR 348 will require that all Expert Groups conduct their work in
the open, we thought we should set an example with this JSR. So, we've created
a public java.net project where you can follow and participate in our work.
All of our deliberations are copied to a public Observer Alias, we're tracking
our issues on a public Issue Tracker, and all our documents (meeting agendas
and minutes, task lists, working
drafts) are published in our Document Archive.
We want your input, particularly now, during the Public Review period. Please
visit us on java.net where you
can learn how to participate. Subscribe to the Observers alias, review our
issues, browse our meeting minutes, download the drafts of our new documents,
and provide your feedback through the Issue Tracker.
See you there!