It?s official. With the final release of JSR 348, Towards a New Version of the Java Community Process (JCP), the JCP program is now under a new and improved constitution. As of 18 October 2011, every new Java Specification Request (JSR) will be required to conform to the terms of JCP version 2.8. Older, in-flight JSRs will have the option to upgrade to this latest version or continue under the old terms. The Executive Committee (EC) encourages all JSRs adopt the terms of version 2.8.

Changes to the JCP Procedures have occurred periodically over the years to streamline the stages of the timeline, offer greater insight into Expert Group operations, and so on. However, such revisions do not take place lightly. Rather, amendments "go through the process to amend the Process," says Patrick Curran, Chair of the JCP program, following the same rigorous process of standardization as any other JCP specification.

The JCP Program comprises two documents: the Java Specification Participation Agreement (JSPA) and Process Document. Although the community knows the JSPA needs to be overhauled, the EC decided to postpone this difficult legal task for the time being. JSR 348 amended the Process Document, which is easier to change and has the greatest immediate impact on the community in determining how JSRs progress through to final release.

Although some Spec Leads and Expert Groups may prefer to keep their JSR work away from public scrutiny, most of the community has been clamoring for the changes addressed in JSR 348 for a very long time. ?The greatest change is that Expert Groups will be required to work in the open with a great degree of transparency,? says Patrick. The JSR also makes adjustments that are designed to increase participation and agility at all levels of the community.

JSR 348 has a number of elements to ensure transparency for the community.

Expert Group Transparency. The Expert Group now has four mandates: do all substantive business on a public mailing list, track issues in a public issue tracker, respond publicly to all comments, and make all documents available in a public archive.

Executive Committee Transparency. The Executive Committee has its own transparency reforms. Even before JCP 2.8 went into effect, the EC began publishing meeting materials and minutes. Now, in addition, the EC must hold semi-annual teleconferences and an annual open meeting at the JavaOne conference. All JCP members are welcome to attend these meetings. Each meeting agenda will include topics suggested by members. Members will be able to provide feedback to the EC through a public alias with an archive. The EC also more clearly defined the Escalation and Appeals process by which any Expert Group member can appeal to the EC regarding a decision, an action or inaction by the PMO, a Spec Lead, or a Maintenance Lead that affects Expert Group participation or issue-resolution.

In acting as the JSR 348 Expert Group, the EC tested the initiatives by voluntarily using them for JSR 348. They conducted all of their work in the open through an open java.net project, which included the use of a Wiki, Expert Group and Observer aliases, discussion forum, issue tracker, and file download area. The use of java.net is not mandatory for all JSRs under JCP 2.8, but it hosts all the necessary tools in one place. Patrick says the EC itself learned a lot just by doing what they believed everyone should be doing, and discovered it wasn?t always comfortable, but definitely worthwhile.

License Transparency. Under JCP 2.7, Spec Leads began publishing the Specification, RI, and TCK licensing terms from the beginning. In the interest of full disclosure, JCP 2.8 requires that any changes to the original terms between releases must be explicitly called out. If a license was offered, that offer cannot later be withdrawn during the lifetime of the JSR although new terms may also be offered. Moreover, implementers who are required to adopt a new version of the TCK must be offered the old terms if that?s what they prefer.

TCK Transparency. TCK testing will no longer be conducted in private. JCP 2.8 specifies that Maintenance Leads must submit quarterly reports to the PMO listing all implementations that have been certified as compatible. That list will be published on jcp.org. TCK documentation must be publicly and freely available, and the TCK User's Guide must include all Compatibility Requirements. In addition, implementers must be free to discuss detailed TCK test results with interested parties.

Election Transparency. The Program Management Office (PMO) will improve the transparency of community elections. In an effort to help members feel more comfortable voting, the community will be offered more Meet the Candidates opportunities to get to know the candidates running in elections. This may be through live introductions, such as occurred at JavaOne 2011, online articles, recorded teleconferences, or other mechanisms. JCP 2.8 also clarified that employees of member companies cannot run for election in their own right.

Through JCP 2.8, even those outside the community can participate. According to Scott Jameson, EC representative for Hewlett Packard, JSR 348 makes ?everything open to everyone.? Now it will be easier for observers to follow any JSR from start to completion. It?s no longer necessary to make a commitment to join the JCP program in order to participate.

In Expert Groups, participation begins with recruitment. The process of recruiting Expert Group members must be openly documented for public scrutiny, raising the likelihood that all applicants are considered in an evenhanded way. Requests to join Expert Groups, the Spec Lead's responses to those requests, and decisions to remove or replace Expert Group members must be reported on the Expert Group?s public email alias.

More is expected of those who have assumed positions of responsibility. The new version incorporates better escalation and appeals processes for dealing with uncooperative, unresponsive, or disruptive Expert Group members and Spec Leads. Spec Leads who fade away but won?t relinquish ownership of the JSR are a thing of the past. By the same token, EC members who miss two consecutive meetings lose their voting privileges until they have attended two more. EC members who miss five meetings in a row or two-thirds of the meetings in a twelve-month period lose their seat. Mike DeNicola, EC representative of Fujitsu, observes that in this way JSR 348 gives the EC the power to discipline itself, a power it never had before.

The goal is to keep the JSRs progressing smoothly through their timelines. However, JCP 2.8 has instituted time-outs for the occasion when a JSR does go inactive. JSRs must reach Early Draft within nine months, Public Draft within one year after that, and Final Release within another year. JSRs that don?t achieve these milestones can be withdrawn by an EC vote.

JCP 2.8 simplifies the Maintenance Release process and requires the Maintenance Lead to submit regular update reports. The new version of the process clarifies the Final Release and Maintenance processes to require that the completed or updated Specification, Reference Implementation (RI), and Technology Compatibility Kit (TCK) are posted promptly. Links to the RI and TCK must be maintained; if broken links are not fixed in a timely manner, the JSR may be withdrawn.

JSR 348 also addressed some minor restructuring and cleanup issues. For example, some non-normative EC policies and procedures that had been created and updated privately were made public and normative in the new document. Some material was moved from the Process Document into the EC Standing Rules.

Definitions that had been scattered throughout were consolidated near the beginning of the Process Document. A new General Requirements section was added to incorporate material that is not specific to any particular phase of the process.

The entire Executive Committee served as the Expert Group for JSR 348. The JCP community signaled its appreciation for work on JSR 348 by granting awards to the two people most responsible for the effort. Patrick Curran was awarded an honorary Community Leadership Award for serving as the Spec Lead, and Mike DeNicola, received the JCP Member/Participant of the Year award for serving as JCP.next Working Group Lead, the informal extension of the JSR 348 Expert Group.

During the open face-to-face meeting with the EC at JavaOne 2011, Lincoln Baxter III of Red Hat said he appreciated the work done on 348. He admitted to feeling pessimistic at first, but after hearing more about the changes, he ?feel[s] good about what has come out of it.?

Now that JSR 348 is final, Oracle will model what the EC wants all Spec Leads to do: adopt the new JCP 2.8 version for all in-flight JSRs. ?We cannot impose this ? only strongly encourage,? said Patrick. An overview of the changes for Spec Leads is available and a call with the PMO is scheduled for 27 October at 8:30AM PDT.

The work to revise the JCP Program isn?t over yet. The EC is already planning for follow-on JSRs to finish the work started with JSR 348. The next step will be to rearrange the two Executive Committees. A final step will address the complex, legal issue of modifying and refactoring the JSPA. Members and potential members look forward to having these changes made. The refactoring will make it so the agreement is made less complicated for those who prefer simpler roles within the JCP community, and retain the necessary level of complexity needed for those, such as Spec Leads, who want to wade in deeply.

Keep watching jcp.org for news of these upcoming JSRs, and be ready to provide feedback on them when they start.