The Java Community Process (JCP) today announced the submission of JSR 306, "Towards a new version of the JCP," a new JSR that proposes changes to the way Java standards are defined.

The expert group for JSR 306 consists of JCP executive committee member companies and individuals. Artima spoke with Sun's JCP Chair Onno Kluyt, and JCP program manager Heather VanCura, about the proposed changes.

According to VanCura, the next version of the JCP will improve on the current process in five main areas:

• Increasing the transparency of how a JSR's expert group conducts its business, and how developers may participate in a JSR's work.
• Influence the time an expert group takes in reaching JSR milestones.
• Allow non-Java implementations of JSRs.
• Define how Java standards efforts work with related standards organizations.
• Provide a way for existing technologies to be brought into the JCP.

VanCura pointed out that the changes are not radical, and instead aim to optimize how Java standards are currently defined:

Some of the changes are an optimization of how JSRs are developed, especially how individuals can participate in, and have more insight into, JSRs. Those changes will increase the transparency of the process, and improve the experience of Java developers with the JCP.

JCP Chair Onno Kluyt told us that these changes are part of Sun's ongoing effort to tweak the JCP in order to make it both more efficient as well as more inclusive:

There was no single trigger [for these changes]. In March, 2004, we finished what is now JCP 2.6, the current version of the JCP process. We made some changes then that encouraged greater transparency and better access to the work done inside JSR expert groups. We then took a step back to assess the impact of JCP 2.6. The current changes are part of an ongoing effort to further refine the JCP.

Kluyt noted that some of the changes will involve how expert group members communicate, and how expert groups share working drafts and ideas with non-JCP members, as well as with related standards organizations:

Currently the work of an expert group is confidential by default. The expert group lead has to do something specific to share that work [with non-expert group members]. That confidentiality aspect of an expert group's work may be an illusion, however. [With JSR 306,] we might potentially flip this around: Unless otherwise labeled, the expert group's discussions will not be confidential. The expert group will still have the option to have confidential conversations, but the default may be for conversations to be publically accessible.

Other changes may require expert group leads to give up some of their current freedoms in the name of greater transparency, according to Kluyt:

By design, a spec lead has some freedom in how to run a JSR. That freedom, for instance, allows a spec lead to break through deadlocks. Within a JSR expert group, we don't have a requirement for full consensus: a 51% majority suffices for a spec lead to affect changes and move the effort forward.

Also, because a spec lead is responsible not only for the specification, but also for the delivery of two major pieces of software—the reference implementation and the compatibility kit, or TCK—you have to give the spec lead's company the ability to manage its own engineering resources.

Those freedoms are balanced by requirements, such as licensing, and also by the executive committee that votes several times in the life of a JSR. It has, indeed, happened that a JSR was voted down over the behavior of the spec lead [Editor's note: That was JSR 96.] One possibility we're looking at in JSR 306 is to restrict some of the freedoms of a spec lead, to say that we want a spec lead to behave in a way that serve's the communities interests.

Currently, the JCP imposes few requirements on a spec lead to communicate the status of a JSR to the larger community, or even to the JCP program office. That presents a problem for the JCP program office in deciding between stalled JSR and JSRs that take a long time to finish:

While of the over three hundred JSRs, only a handful are currently stalled, it is often hard even for the JCP program office to determine if expert group members are working too hard [on their spec] to communicate with us, or if no work on a JSR is taking place... It can also be that progress doesn't occur because a major stand-off took hold between members of the expert group. Making the conversations of expert groups more accessible would have a positive effect here, too.

The final set of proposed changes to the JCP address bringing existing technologies into the Java standardization process, and creating non-Java implementations of JSRs. While the former has been possible, albeit cumbersome, the JCP's rules currently prohibit the latter:

There are many existing technologies, some that were developed by a company, that could either be standardized in the JCP, or serve as starting points for JCP standards.

Bringing an existing technology to the JCP has happened before, but it's a cumbersome process now from a perspective of managing IP. The main issue is that while a company may contribute its technology to a JSR, the outcome of the JSR is not certain at the outset of the process, and claims by other expert group members can be made about technologies that would be shipping in a company's products.

One solution has been for a company to wait with a product release until a JSR is done. Sun has done that several times in the past. Another option is to build a Chinese wall around your expert group and product development teams. That tends to be rather expensive. The third option is to not bring the technology to the JCP... We're looking at things we can do to make this a palatable effort for a potential spec lead.

Java technologies do not operate in a vacuum. In the enterprise world, they live with many other architectures. There is value to enable implementations of JCP specs that are not specifically Java. While that doesn't make sense for Java language features, for more protocol-oriented specs, there can be value to do non-Java implementations.

The rules of the JCP currently aim at creating compatible implementations of Java, and do not allow non-Java implementations of JSRs. We're looking at changing that in JSR 306.

The JCP has always been keen on ensuring compatibility. We asked Kluyt what would compatibility of JCP standards mean for non-Java implementations:

To be blunt, Sun cares about our world: We care about Java implementations being compatible. The outside world.. well, they're already "unwashed." If the [non-Java technologies] want to stay unwashed, let them stay unwashed. We actually don't care too much about that. The rules for the Java side stay the same. Outside the Java world, there is no sense of compatibility in a similar sense. There is no mechanism to try to go and design one for that other world, if only because you then get into the issue of how many languages and platforms you have to develop a TCK for. That's cost-prohibitive.

What do you think of these proposed JCP changes? Do they address your current concerns about the JCP?