The Java platform grows and is maintained by the Java community through the Java Community Process (JCP) program. This effort is represented by Java Specification Requests (JSRs) through the JCP program.
Each JSR represents the persistent work of a team leader (Spec Lead) and a small group of dedicated developers (Expert Group members). The entire team is often an average of a dozen Java specialists. There are over three hundred JSRs that bring the Java platform to life.
The JCP is governed by the Executive Committee (EC) and entire process is overseen and guided by the Java Program Management Office (PMO) Chair and Staff.
JCP.next is a series of three JSRs designed to bring significant benefits to all of the above, and more.
Patrick Curran is the Director of the PMO, Chair of the JCP, and the Spec Lead for all three JCP.next JSRs (JSR 348, JSR 355 and JSR 358). "These JSRs modify the JCP's processes - the Process Document and Java Specification Participation Agreement (JSPA) - and will apply to all new JSRs and to future Maintenance Releases of existing JSRs for all Java platforms," he says.
Curran explains that the first - JCP.next.1, known formally as JSR 348, Towards a new version of the Java Community Process - was completed and put into effect in October 2011 as JCP 2.8. It created a small number of simple but important changes to make the JCP's process more transparent and to enable broader participation. "We're already seeing the benefits of these changes as new and existing JSRs adopt the new requirements."
The second - JSR 355, Executive Committee Merge, is also Final. It contains revisions to the JCP Process Document (version 2.9) and the EC Standing Rules (version 2.2). These changes went into effect following the 2012 EC Elections in November, detailed on the Elections page.
The third - JSR 358, A major revision of the Java Community Process, was approved in July 2012 by the EC. This JSR is in its beginning stages and will modify the Java Specification Participation Agreement (JSPA) as well as the Process Document, and will address a large number of complex legal issues.
Next: Let's take a closer look at the two JCP.next JSRs that have reached Final Release before exploring the "major revision" challenges ahead.
The three themes of JSR 348, transparency, participation and agility, are designed to give the JCP community, Java community, and public a way to observe and be more involved with the Java platform's development and governance. At the same time, it creates a process for the JCP that both encourages and enforces rapid platform progress through agility.
JSR 348's transparency provisions require EG members and Spec Leads to conduct their work in the open and address all public comments. In years previous, an EG's process and progress was hidden, or at best difficult to find.
Now, JSR 2.8 EGs post all of their activities and decisions on a public mailing list. Their deliberations are copied to a public Observer Alias, and all of their documents (meeting agendas and minutes, task lists, and working drafts) are published in the JCP Document Archive.
They must also track the JSR's issues in a publicly available issue tracker such as JIRA, or others, such as Bugzilla.
The EC has already adopted the changes it is required to make, for example, publishing its minutes and meeting materials and providing a public mailing list for community feedback.
JCP 2.8 also requires the EC to hold semiannual public-participation teleconference meetings
Heather VanCura, manager of the PMO, confirms that they're on track: "In 2012 we had our first semiannual meetings in June and November, a one-hour teleconference with questions submitted by the community. Our live JavaOne gathering in October was the second event, and one-hour teleconference in November makes three public meetings in one year. These meetings are open to all JCP members, and anyone can suggest topics for discussion."
Finally, there are new transparency provisions that give the community more visibility into licensing, TCK testing and the election process.
Curran and his EG wanted to create an example of the new, "expected" transparency mode in developing and maintaining the JSR itself. They created a public java.net project where anyone can follow and participate in the work, now in Maintenance.
"Overall, I think these transparency changes have been received well," says VanCura. "We're seeing the vast majority of Spec Leads and EGs migrating to JCP 2.8 or above and using java.net or other collaborative sites. Most have started java.net projects, they have complied with the rules for establishing aliases for the public, and they're using online issue trackers as well."
In December 2012, the JCP introduced a new communication channel where the public can comment on the progress of any JSR's EG. In addition, the community will have a method to evaluate and provide feedback on EG and EC transparency. That information will help the JCP Program Management Office conduct transparency audits for each JSR and work with the Spec Lead to make improvements in their process. The audit results will also be available to the public.
Active participation is encouraged, streamlined, and designed to support transparency in the JCP program.
For example, now, any JCP member can make a request to be added to an EG, and the Spec Lead must respond to the request. Both the request and the EG response are posted publicly. Similarly, Spec Leads are required to post notification of any EG member changes, and the reasons for adding, losing or removing a member. There is also an enforceable process for dealing with Spec Leads, EG members, and EC members who don't actively participate.
The EC members in particular can lose voting privileges for missing meetings. They can lose their EC seat altogether if the miss five meetings in a row, or two-thirds of the meetings in a twelve-month period. In 2012, three EC members "forfeited" their seats under the new rules of JCP 2.8: Samsung, ST Telecom and RIM.
"EC members have to take the time to be informed before they come to the table to make decisions, and it requires a large commitment on their part," says VanCura. "We don't want people holding a seat on the EC if they aren't participating advancing the platform. As the EC process has become more transparent to the community, our members have learned to see who on the EC is contributing, attending, and making progress. They now have the tools to track and evaluate JSR progress, and they are using them to voice their opinions."
In the October 2013 election, all current ratified and elected EC members will have to run for re-election, and the community at large will be watching their progress closely.
In 2009 the JCP instituted an informal process labeling a JSR "inactive" if it shows no activity in any 12-month period. It was simply labeled, with no consequences or means of progress enforcement. Now, JCP 2.8 introduces means of progress enforcement: Time-outs for JSRs. The time-out provisions require EGs to reach various stages of the process within a defined time period, or face the possibility of being shut down.
Learn more about JSR 348 in the JCP 2.8 Ushers in a New Era of Complete Transparency article.
The second JSR in JCP.next is JSR 355, Executive Committee Merge. It combined the two edition-centric ECs (ME and SE/EE) into one EC to govern the entire Java platform as one body, and all JSR ballots will be voted on by one EC.
The PMO's VanCura says, "As the previously distinct editions of Java converge to become 'one Java,' it has increasingly made sense to merge the two committees into one governance body that reflects that natural evolution."
"It's encouraging to see so many Spec Leads embrace JCP 2.8 and 2.9," says VanCura. "Most of the in-process JSRs have migrated to the new process - only a handful haven't done so yet. And all new JSRs must follow the provisions of JCP 2.8 or JCP 2.9."
"So far, JCP 2.8 has made it easier for JCP members and the public to observe and participate in the work of the EGs," she says. "And it has made transparency the default, expected mode of operation, rather than an anomaly."
The first two of the three JCP.next JSRs were completed in a reasonable time and efficient manner. Now, with the new unified EC in place, the community turns its focus to the third and most complex installment: JSR 358: A major revision of the Java Community Process.
It will revise long-standing agreements between the JCP and its members to shape the way the JCP is governed for the foreseeable future.
JSR 358 will modify both the Java Specification Participation Agreement (JSPA) and the JCP Process Document to address a large number of complex issues, many of them postponed from JSR 348.
For these reasons the EG members expect to spend a considerable amount of time working on it. Several members estimate, "at least a year, and probably more."
Patrick says, "We have to make sure JSR 358 is absolutely right, and fulfills all of the legal needs." He says, "The attorneys representing each of the stakeholders will be involved to finalize the agreements in both documents. It will take a while."
The current list of revisions to be made includes:
- The role of independent implementations (those not derived from the Reference Implementation)
- Licensing and open source
- Implementing full transparency
- Compatibility policy and TCK responsibilities
- The role of individual members
- Patent policy and IP flow
A complete list is available.
Follow JSR 358 on java.net.
EC Members and Spec Leads Voice Their Opinions.
Patrick Curran's blog, The Fine Print, extends an open invitation to become involved in the process, and he maintains a forum for updates and your input at the java.net JSR 358 project homepage. Everyone is welcome.