The JCP evolves in much the same way as software: we gain experience with the current implementation, gather ideas from many sources, give an initial ordering to the many ideas, write a draft, get initial feedback, write another draft, get more feedback and so on, towards a reasonable consensus of what the next version of the product or process shall become.

No successful, sustainable efforts operate in a vacuum, and the Java Community Process is no different. Technological advancement, shifting business models, and changing markets all contribute to ever-changing environments in which our community lives. To adapt to existing changes, and/or to build responsive capabilities for the future, JCP evolves. We are at such an evolutionary turn, and along with the two Executive Committees, I am working to shape the next chapter of the community.

By the time you read this column, the process change specification will have already been submitted to JCP.org, as JSR 306. Change in the process happens by using the JCP mechanism itself, a JSR. The Executive Committees form the expert group for such a JSR with Sun as the spec lead. The process has been evolved several times, until now, in a similar manner; JSR 913 led to JCP 2.1, JSR 99 created JCP 2.5 and the current Java Specification Participation Agreement(JSPA), and JSR 215 gave us the current version JCP 2.6. You can find these on the JCP.org site - a road map of the evolution of the JCP to date.

For this iteration of the process rules, I anticipate that both the process document (http://jcp.org/en/procedures/jcp2) and the JSPA (the membership agreement and IP policy) will change. As with any JSR, the eventual specifications are subject to expert group deliberations and EC approval, but here are some of the things we will be working on.

Let's start with this question: should it be possible to implement certain specifications outside the Java platform? Yes, one can envision scenarios in which it makes sense to do this. In enterprise environments where technically different architectures need to inter-operate through Web services, service oriented architectures, or other protocols, it can be valuable to enable this standardization work to take place directly in the JCP, or for example, to enable the implementation, in environments besides Java, of some of the specs related to XML.

Many JSRs perform Java standardization work that is based on or related to external specification work. For example, some of the Java ME JSRs relate to OSGi; there are the OMG CORBA specs in Java SE and Java EE; and the JAX* JSRs depend on work in W3C, OASIS and elsewhere. Often the spec leads and expert groups like to exchange working drafts or ideas with the working groups at these organizations. This new process JSR will explore how best to facilitate these interactions, which are called liaisons in the standards world. Initial investigation indicates that working on the JSPA confidentiality statement may address such needs, which leads me to the next group of topics that the expert group will be focusing on: transparency, duration of JSRs, and individual members.

Open source software influenced the evolution of the JCP in the past. When the JCP first started, open source software did exist, but was not generally accepted as a development method or a business model until a few years later. The Apache Software Foundation, through its expertise (and persistence!), along with many others, helped Sun understand how Java specification standardization and open source can co-exist and co-operate. Over the years, many developers and IT departments had become accustomed to using open source methods to develop and market software. The JCP adjusted to ensure that open source efforts could build compatible implementations of its specs. Since then, a new trend has been emerging: it is not only commonly accepted to use open source methodologies to develop software, but also to apply this life style to the development of specifications. This encourages us to evaluate whether community members and the general public alike have sufficient insight into the work and progress of an expert group and whether the expert group has the right tools to inform the community of its progress and design decisions.

In October 2002, JCP 2.5 was launched, enabling the compatibility of open source and Java. Since then I have seen a significant and continuing increase of individual participation in the JCP (although I just can't shake the feeling that making the membership free had some effect too). Individual members (developers participating under personal titles) are highly valued in the community. Individuals serve on the EC, various JSRs are led by individuals (among them concurrency and Groovy), and many participate on key JSRs, such as the Java SE and Java EE umbrella JSRs. The expert group will explore how best to ensure a continued, mutually effective, and efficient engagement.

As you can see from JSR 306's description on the jcp.org Web site, I proposed a rather aggressive schedule. My fellow spec leads know how hard it is to keep to such a schedule. We may not finish in May 2007, as the schedule proposes, but my goal for the year is to be as far along in the process as possible, as I know that many community members are eagerly awaiting some of the changes we are proposing here.

These are just a few of the topics that this process JSR will explore. If you read the JSR proposal on JCP.org, you'll discover more. The Executive Committee members and I are very interested to learn your opinions on the JCP and its evolution. Stay tuned for further updates on JSR progress and more news from the JCP.