Our new effort to improve and change the Java Community Process through JSR 306 is still young; however, developers and all those interested have already started to provide valuable feedback and share their opinions generously. One such place where opinions were expressed early was the poll on JCP change that the java.net site put up (http://today.java.net/pub/pq/123). "Improving involvement of individuals" was the top pick, closely followed by "Optimizing duration of JSRs." Also "Easing migration of existing technologies into standards" got a good number of votes. Acknowledging the comments provided by some of the voters in the poll, it serves us to look at the process of joining the JCP, making the expert group discussions more visible, and allowing members and non-members alike to participate in these. One commentator states that the JCP should look closely at various open source projects and accept some as standards. Artima.com reported on JSR 306 and readers there commented on the openness and transparency of discussions. The Java Posse took notice of the JSR as well, asking questions and requesting more information about the item on allowing non-Java implementations of some of the specs.

Joining the JCP as an individual is evidently possible, as proven by the 700 or so individual members out of the total membership number of 1100, but admittedly it is not a turnkey effort. When indeed the JCP first started in December 1998, it was aimed at enabling corporations and institutions to come together over the standardization of Java technology. The membership agreement might seem lengthy to some; it is because it needs to capture all the IP aspects due to the JCP's mandate that JSRs deliver a spec but also two pieces of software (the reference implementation and a technology compatibility kit). This makes the membership agreement complex to a degree that individuals are not used to dealing with. The Website (JCP.org) can play a role here. In parallel to JSR 306 my team will be working to improve the information provided on the site about the membership process.

Openness and the transparency of expert group discussions and other related communications at the JCP are topics that are frequently raised and they are very valid ones. From a developer's point of view, it's difficult to understand why public access is not granted on Java specification efforts that the developer is interested in. It is also difficult to explain! In earlier versions of the JCP, the first draft review, then known as the Community Review, was restricted to the JCP membership. Meanwhile we made all draft reviews public and rightly so. Nothing scary happened. Since JCP 2.5 the spec lead and expert group have had considerable freedom over how they conduct their work. Several spec leads have taken that freedom to run their JSRs in a very open manner with Doug Lea's JSR 166 often as the prime example. Again nothing scary happened. Many external standards organizations and many JSRs have a desire to work together (OSGi, OMG with CORBA, OMA and various Java ME-related JSRs are some of the examples). On previous occasions, when we looked at this, the solutions always seemed complex. Now, in JSR 306, it appears we may be able to build such liaison relationships and provide that much sought-after transparency with the same edit to the JSPA, the membership agreement.

The accessibility of expert group discussions has, of course, a direct relationship to the perception of involvement as experienced by members and by potential new members. While JSR 306 will bow over to the various legalities and process regulations that may be at play, involvement also has a strong usability aspect. This is an area where the Website can play a role. Since JCP 2.6, spec leads have had the ability to post whatever updates they want to share (notes, working drafts) with the community as a whole. These are the so-called Community Update pages for each JSR. How do you become aware of these pages? One option is to track your favorite JSRs and RSS feeds through Website features that enable users to do just that.

One other thing the process-change JSR sets out to explore and implement is allowing for non-Java implementations of specifications created by some of the JSRs. In EC talk, these have been labeled as "Hybrid JSRs." Sometimes our nicknames are a tad more fanciful. There is something called "Purple JSRs" but that' a different story. By "non-Java" we mean anything that is written and runs entirely outside the Java environment. It could be written in C, in Ruby, in COBOL, or Prolog for that matter. The point is that there are situations in which it makes sense to enable the JCP to specify APIs that can be implemented in a Java application and in other architectures. Web services interoperability can be one context, Java language features clearly not. "Hybrid" then describes a JSR that allows both: it still must do all the known Java work and may then also allow the gathered IP to be implemented in a different world than Java.

As always my expert group and I are very interested in your views, keep them coming. You can send your comments to me directly (onno@jcp.org) or to the expert group (jsr-306-comments@jcp.org).