adam bien's blog

Heather please introduce yourself.

I lead the JCP Program Management Office (PMO) at Oracle, and am responsible for the day-to-day nurturing, support, and growth of the community, including the JCP.org web site, JSR management, community building, events, marketing, communications, and membership. I am also a leader of the global Adopt-a-JSR programs, working with Java User Groups (JUGs) around the world. In 2014, I took on the role of serving as Spec Lead of JSR 364, Broadening JCP Membership, which is evolving the JCP program itself. For JCP updates follow @jcp_org on Twitter. You can also find me @heathervc.

What is the relation between JCP and Oracle?

Oracle has a permanent seat on the JCP Executive Committee (EC), and together with the other EC members, the EC votes on the work of the Expert Groups and evolves the JCP itself. The EC is led by a non-voting Chair from the PMO; the PMO is the group within Oracle that is responsible for administering the JCP and chairing the EC. The EC does not micro-manage the day-to-day workings of Expert Groups - the EC has the opportunity to review the work of each Expert Group at well-defined points as their specifications proceed through the JCP program. The primary function of the EC is to ensure that specifications do not overlap or conflict with one another and that the specifications meet the needs of the industry segment for which they are being written.

How democratic is JCP? How much power has the community?

Anyone with an internet connection can review and comment on draft specifications and JSR proposals on JCP.org. Anyone with an internet connection and an e-mail address can register as a user of the site. Any registered user can nominate himself for an Expert Group (but must be JCP Members to serve), maintain a watch list of JSRs of interest,request to be associated with an existing JCP Member, or become a JCP Member. Any organization or individual which has signed a Java Specification Participation Agreement (JSPA) has become a JCP Member.

JCP Members can propose new JSRs, serve on Expert Groups, vote in the annual Executive Committee elections process, and run for a seat on an Executive Committee.

How hard is the introduction of a new JSR by an individual?

Any full JCP Member can submit a Java Specification Request (JSR) for approval by the EC. The Specification Lead is a representative of a JCP Member who leads a group of experts in developing a specification described in a JSR, and is responsible for delivering the Specification, the Reference Implementation (RI), and the Technology Compatibility Kit (TCK) for the JSR. These things together are a substantial software deliverable, and it does take quite a bit of effort on the part of the Individual, but there are a few Individuals that have successfully led JSRs to completion.

Some JSRs are in "maintenance mode". How much changes or additions are allowed? When it is better to introduce a new JSR?

Maintenance is for making minor changes to a JSR once it has completed the Final Release of the specification. Maintenance is an optional stage, since Spec Leads may choose to complete work at Final Release or present major changes or features to the specification in a new JSR. If significant changes are desired, a new JSR should be submitted by the Spec Lead. The community may submit requests for clarification, interpretation, and enhancements to the Specification by logging issues through the JSR's Issue Tracker. All changes proposed make their way into the Specification either through the Maintenance process or through a new JSR. Changes appropriate for Maintenance include bug-fixes, clarifications of the Specification, changes to the implementation of existing APIs, and implementation-specific enhancements.

Is it possible to take-over an "abandoned" or inactive JSR? Which steps are to take in such a case?

This is addressed in the JCP Process document section 1.2.4:

"There may be rare instances when members of the Expert Group feel that the Spec Lead is not acting in ways that advance the work of the Expert Group and is being unresponsive or inactive. The EG is expected to make a reasonable effort to resolve any such issues in a timely manner. However, if the situation cannot be resolved these concerns should be brought to the attention of the EC as quickly as possible so they may be proactively addressed and resolved. If the problems cannot be resolved informally, any three members of the EG may request the EC to replace the Spec Lead. All such requests must clearly state the cause of the concern and provide all necessary evidence. If the EC agrees that there is cause, it may ask the PMO to replace the Spec Lead. In the case where the Spec Lead is a Member Representative the PMO shall ask the Member to replace the Spec Lead. If the Member refuses to do so, the PMO shall seek to put in place an alternative Spec Lead, in which case the EC must conduct a transfer ballot as specified in section 5.1.2 of the JCP Process document: If no Spec Lead replacement can be found, the EC shall initiate a JSR Renewal Ballot to determine whether the JSR should be shut down. If the Maintenance Lead decides to discontinue his or her work at any time (including discontinuing maintenance activities or declining to take on the role of Spec Lead during a significant revision initiated by a new JSR) the ML, with the assistance of the PMO, should make a reasonable effort to locate another Member who is willing to take on the task. If a replacement is identified the PMO must initiate a Transfer Ballot within 30 days to enable EC members to approve the transfer of responsibilities. If the ballot succeeds, the new ML must assume his or her responsibilities within 30 days. If no replacement can be found, or if the Transfer Ballot fails, then the PMO shall declare the Specification to be Dormant and no further maintenance can be carried out. No further Transfer Ballots will be initiated by the PMO unless a Member volunteers as ML, in which case the PMO will again have 30 days to initiate a Transfer Ballot."

The JCP process is continuously changed and versioned. Who decides when it is time to introduce a new version? How frequently new versions are released?

We call this effort 'JCP.Next', and evolving the JCP program itself is addressed in Appendix A of the JCP Process Document:

Revisions to the Java Community Process (JCP) and the Java Specification Participation Agreement (JSPA) are be carried out using the Java Community Process with the following changes:

Only EC members can initiate a JSR to revise one of these documents.
The EC must approve the JSR.
The Expert Group consists of all EC members with a member of the PMO as Spec Lead.
There is no Reference Implementation or Technology Compatibility Kit to be delivered and no TCK appeals process to be defined.
There is not a specified time for new versions of the JCP program to be released, but we are listening and responding to the needs of the community over time. To give you an idea of the history, in June 2000, JCP 2.0 replaced the previous JCP 1.0 version for new submissions. Further refinements to the voting rules resulted in JCP 2.1, introduced in July 2001. A major revision of the licensing rules for the Spec, RI and TCK as well as IP policy changes and process changes was put in place by JCP 2.5, launched on October 29, 2002. The process was revised in May 2006 with the release of JCP 2.6, and in May 2009 with JCP 2.7. In October 2011 we introduced JCP 2.8 to open up the operations of JSR expert groups and increase transparency. The current version of the process is JCP 2.9, which was introduced in August 2012. We are now in the process of finalizing JCP 2.10 through JSR 364, Broadening JCP Membership.

This JSR is in Proposed Final Draft stage and is expected to complete in 2016 - a good topic for a future conversation :)!

How hard is it to change / improve the JCP process itself?

The JSR lifecycle process works very efficiently and transparently. As you can see from the timeline above, describing the evolution of the different versions of the JCP, it is an effort that takes some time working together with the developer community and the JCP EC Members, who serve as members of the JSR expert group. For minor changes, the maintenance process described earlier, can also be used for updates to the JCP program itself.

Are the differences in the governance / process / handling of the different platforms like Java EE, Java SE and Java ME?

In 2012, JCP 2.9 merged the two Executive Committees (Standard/Enterprise Edition and Micro Edition) into one single Executive Committee. The merged Executive Committee votes on all JCP 2.x JSRs now, regardless of which JCP 2.x version it is.

Heather, thank you for the interview!