It's summer. JavaOne is behind us, and much of Europe is on holiday :) At this time of year life in the JCP slows down somewhat. Nevertheless JSRs continue to move through the process, and this month I'll discuss several of these, and demonstrate how their progress has been facilitated by some of the housekeeping changes we've recently made in our processes.

Before I go into the details, however, please note that the old JCP interest mailing list has been replaced by the jcp-announcements forum bulletin board on the new jcp.org web site. Please check this out for the latest news about active JSRs.

Inactive JSRs
Several months ago we started to label JSRs as "inactive" if they hadn't produce a revision of their spec or otherwise made progress through the system within 18 months. When we do this it sometimes encourages the Spec Lead to demonstrate that the JSR is still making progress, perhaps by publishing an updated version of the spec. Sometimes, however, it has the opposite effect, and the Spec Lead, recognizing that the JSR will never be completed (perhaps the need for it has declined, or an alternative solution has emerged), decides to withdraw it. Recently IBM chose to withdraw JSR 104: XML Trust Service APIs, which had been inactive for several years (they continue to work on the related JSR 106: XML Digital Encryption APIs.) This is a good thing - we don't expect all JSRs to reach completion. Circumstances change, and it's best to recognize when a JSR is no longer viable.

Changing the Spec Lead
Last year, Qisda - formerly BenQ - announced that they were withdrawing from their role as Spec Lead for several Java ME JSRs. Although a couple of these were jointly led by Motorola, who then simply took over as sole Spec Lead, several were left in a state of limbo, with no Spec Lead. The JCP's Process Document, which defines the organization's operating rules and the processes through which JSRs are developed, specifies the procedure to be followed in the case of an already completed JSR that loses its Maintenance Lead: the Executive Committee can vote via a Transfer Ballot to transfer that role to another member. It did not, however, clearly specify what should be done with "in-flight" JSRs.

A couple of months ago, Sun announced to the Executive Committees that it had acquired the rights to all of the "orphaned" Qisda JSRs, and that it wished to take over the role of Spec Lead and to drive these to conclusion. While the ECs welcomed this, they wished to ensure that the transfer was done according to our processes. Fortunately, in May of this year we made a Maintenance Release of JSR 215 to update our Process Document to version 2.7. (You can read the current version of the Process Document here.) One of the changes we made was to clarify what should be done if a Spec Lead became "unresponsive" or inactive. Specifically, we added language that permitted the Executive Committee to request that another member take over the role of Spec Lead.

The ECs therefore held two ballots to transfer the leadership role for various JSRs from Qisda to Sun. First, a Transfer Ballot approved the transfer of the Maintenance Lead role for the already completed JSR 229: Payment API. This important JSR provides a framework to support a variety of payment mechanisms for services provided to users of mobile phones. A second ballot approved the transfer of the Spec Lead role for the following JSRs which, when they are completed, will significantly enhance the power of Java mobile platforms.

• JSR 230: Data Sync API will enable data synchronization between a terminal device (typically a phone) and a server.
• JSR 246: Device Management API will provide APIs to support device management via natively implemented Device Management protocols such as SyncML/OMA DM and WAP/OMA Client Provisioning.
• JSR 259: Ad Hoc Networking API will enable communication between mobile devices in a peer-to-peer ad-hoc network environment.
• JSR 266: Unified Message Box Access API will define APIs for managing the "message boxes" that are used to store and send short messages (SMS), multimedia messages (MMS), email, ring tones, bitmaps and Vcards.

More Agile JSRs
Another change that we made in the recent revision of the Process Document was to require that all materials needed to publish the Final Release be provided to the PMO before the Final Approval Ballot starts, and to require that the PMO publish the final release materials within two weeks of the completion of the ballot. We introduced this change in order to deal with a problem that we've seen in several JSRs, whereby they go through the Final Approval Ballot process and then wait months - or even years - before actually making the final materials (the specification, RI, and TCK) available. For example, the Final Approval Ballot for JSR 225: XQuery API for Java closed in March 2008, but the JSR only reached the Final Release stage in June 2009. Hopefully we won't see this problem with future JSRs.

Other JSR Changes
A couple of other Java ME JSRs made progress recently. JSR 257: Contactless Communication API, led by Nokia, recently made a Maintenance Release. This JSR enables a mobile device to communicate over short distances with "contactless" targets such as RFID tags and barcodes. One obvious application - widely implemented in Asia - is the use of cell phones for ticketing in subways and other public transport systems. A newer JSR - 327: Dynamic Contents Delivery Service API for Java ME, led by SK Telecom, recently published its Early Draft Review. This JSR will facilitate push-based content delivery services. If you browse the detail page for this JSR you will notice that the original JSR proposal has been updated with at Transparency Plan which outlines the various ways in which the public can learn about, provide feedback on, and participate in the development of this JSR. The requirement to publish a Transparency Plan was another change introduced in the recent revision of our Process Document.

On the Java EE front, two JSRs intended for inclusion in the upcoming Java EE 6 release made recent progress. JSR 299: Web Beans, led by Red Hat, published its Proposed Final Draft while JSR 314: JavaServer Faces 2.0 made its Final Release. Congratulations to the Spec Leads, Ed Burns and Roger Kitain from Sun.

Finally, I have two new JSRs to report on. JSR 330: Dependency Injection for Java, led by Google and SpringSource, intends to define an extensible dependency injection API that can be used in both Java SE and Java EE. This goal can only be met if the JSR is included in Java EE 6, which is expected to ship within a few months. This means that the JSR will need to make its way through the entire process in a matter of three or four months - a very ambitious goal. Fortunately, extensive work has already been carried out in an open source project, and the scope of the JSR has been carefully controlled. So far, it seems to be on track to break the record for the fastest JSR to complete the process. We'll see. The second new JS - 331: Constraint Programming API has been proposed by Jacob Feldman, an individual member. The JSR was approved, but EC members expressed some concern about the need to ensure broad Expert Group participation. This too, will be an interesting JSR to watch.

That's all for now. Please visit the new jcp.org web site and check out the forums and Wikis. Until next time...