JavaOne Feature Article
JCP 2.7 Brings Welcome Changes in Transparency and Agility to the Process
The JCP program version 2.7 is here, and the resulting changes were worth the wait. More than ever before in the history of the Java Community Process (JCP) program, transparency and agility are the watchwords.
Over the years, the Program Management Office (PMO) and representatives who serve on the Executive Committee (EC) that oversees the JCP program have made themselves available to the community. Their email addresses are published on the JCP.org website. They have appeared in public events such as press roundtables and panel discussions at the JavaOne Conference and at other formal and informal venues. They and their colleagues have served on Expert Groups. Through all of these means, they heard the repeated wish of the community and the public to make the process more transparent and agile.
Any change to the program as a whole undergoes the same process that a technical specification or JSR goes through. Therefore, Patrick Curran, chair of the JCP program, became the Spec/Maintenance Lead for JSR 215, whose stated goal is “to make the process more transparent and efficient.” The Executive Committee constituted the Expert Group to produce a Maintenance Release for the JSR in May 2007, thereby introducing JCP version 2.7 to the community. The EC hammered out the changes, submitted the enhancements for public review, and got comments and approvals in the same way that any JSR would.
More Open and TransparentIn the interest of making every aspect of the program more transparent, Expert Groups must fully disclose the licensing terms for the specification, Reference Implementation (RI), and Technology Compatibility Kit (TCK). They are now obliged to state publicly the transparency techniques they plan to employ and these methods are included on EC ballots. The terms of service for any of the transparency methods must also be included by the Spec Lead. Expert Groups are now discouraged from labeling material “Confidential.” They also must publish and respond to public comments before the EC ballots are started. Requests for Maintenance changes to a JSR must also be publicly viewable and addressed by the Maintenance Lead.
More Efficient and AgileIt’s not so hard to see that whatever is opaque to public view could be made more transparent. However, it’s a little more difficult to figure out what would make the process move in a smoother, more efficient way. To improve the agility of the program, various components are addressed. The process for replacing uncooperative or inactive Spec Leads is clarified, and a quick look at some of the unfinished JSRs will show that the new standard is already being implemented and enforced. After the Final Approval Ballot concludes, Final Release materials are expected to be posted promptly. The role of Expert Group members during Maintenance is clarified, and Maintenance Review exception deadlines are changed to allow more time for review. In addition, upon completion of the Maintenance Review, updated specs are required to be published.
The duties of the EC in providing guidance to the PMO are expanded to include white papers, reports or comments. The EC Elections process is compressed and the timing for requiring and EC Special Election is lengthened to reduce confusion and improve participation.
All JCP 2.6 JSRs will automatically migrate to JCP 2.7 in June 2009 and the PMO is actively working with Spec Leads to assist them with the transition. The JCP program is dynamic, so it is unlikely that this will be the last word on the program. As always, feedback from the community is appreciated as the EC seeks continuous improvement.