Similar techniques are used by other Spec Leads.

JSR 311: JAX-RS: The Java API for RESTful Web Services, led by Mark Hadley and Paul Sandoz from Sun, also uses separate java.net projects for spec and RI development. They track issues publicly, and even though the spec is not yet complete there are already several implementations in progress. The active involvement of the broader community has had the effect, Mark Hadley argues, of inspiring the Expert Group to greater involvement, and the result will be a higher-quality specification.

While many (probably the majority) of otherwise open JSRs still maintain the concept of a separate Expert Group that communicates through private email aliases and phone conferences, some have chosen to erase that distinction. For example, all significant work on JSR 310: Date and Time API, led by Stephen Colebourne and Michael Nascimento Santos, is carried out through their public mailing list and Expert Group members have no special status or privileges. As their java.net project page explains, "the main activity of the JSR [is] on the public mailing list. If you are interested in observing or contributing to the discussion of this JSR, please feel free to join. Anyone can sign up for the dev mailing list."

JSR 308: Annotations on Java Types, led by Alex Buckley from Sun and Michael Ernst, is another JSR that prefers broad consensus to making decisions within a small Expert Group. As they explain, "the expert group is by necessity small, but we expect that the broader public discussions will hash out most issues. The expert group members will participate in those discussions, and will only decide issues on which the group cannot obtain consensus" (http://groups.csail.mit.edu/pag/jsr308/). They are in the process of migrating their public web-presence from MIT to java.net.

JSR 283: Content Repository for Java technology API 2.0, led by David Nuescheler of Day Software, is an example of a JSR that still maintains a private Expert Group alias despite performing the majority of its work in public. The Reference Implementation and TCK for this JSR are being developed in open source through the Apache Foundation Jackrabbit project. David believes, as Doug Lea and others have suggested, that the open source development model is the best way to ensure a high-quality specification, implementation, and TCK.

So - if the JCP is so open and transparent why do people think that we do our work in smoke-filled rooms? One reason is probably historical - in the past we used to be more secretive. Indeed, the Process Document still contains language about "Confidentiality," and only on close reading does it become apparent that there are no requirements that anything be kept secret - this is simply an option that Expert Groups are free to adopt, if they wish, by explicitly labeling some materials as confidential. (This is seldom, if ever, done.)

More important, we don't do a very good job of letting people know that we operate in this manner. It's difficult to ascertain from a reading of the JSR pages on jcp.org whether an Expert Group is working in the open and, if so, how to participate. We're working to fix this.

Another change that we're working on is to provide collaborative tools such as Wikis and discussion forums on jcp.org. While many Expert Groups are happy to use existing facilities such as those provided by java.net, others have suggested that they would like to take advantage of tools provided by the JCP. We're working hard to answer this demand, and will begin to roll out new facilities soon.

This Month's Active JSRs
Once again there are more active JSRs than I have room to discuss here. (For full details, see the Focus on JSRs section on the JCP homepage or subscribe to our mailing list.) Here are some highlights.

It's always good news when new JSRs are approved for development. This month we have a new JSR from IBM: JSR 326: Post mortem JVM Diagnostics API, which will define APIs to process output files that are generated when Java Virtual Machines fail. This JSR will enable the development of a variety of diagnostic tools that will improve the quality and stability of Java VMs, helping to ensure Java's continuing adoption in the enterprise market.

JSR 240: JAIN SLEE v1.1, led by Open Cloud Limited, made its Final Release. This update to the JAIN Service Logic Execution Environment specification for telecommunications services defines Resource Adaptor Architecture APIs and semantics - areas that were excluded from the original spec in the interest of simplification and time-to-market.

JSR 258: Mobile User Interface Customization API, led by Star Spec Lead Jere Kapyaho from Nokia, also made its Final Release. This JSR defines mechanisms for customizing the user interface on mobile devices, supporting the development of themes and skins that enable carriers to brand their applications with a common look and feel, and users to personalize applications with customized skins.

JSR 293: Location API 2.0, again led by Nokia, reached Final Ballot Approval status. This JSR builds on the low-level location APIs defined by JSR 179: Location API for J2ME, standardizing access to location-based services such as geocoding, mapping, and navigation.

Two other Java ME JSRs advanced this month. JSR 297: Mobile 3D Graphics API 2.0 reached Public Review, and the Public Draft of JSR 300: DRM API for Java ME was approved. Java ME is alive and well.

Until next month...