Protecting Technology's Integrity: The Java Community Process -- ADTmag

Protecting Technology's Integrity: The Java Community Process

By Timo Salo, Justin Hill
July 16, 2001

The Java™ Community Process is one of the more interesting aspects of Sun Microsystems' Java language. It is unusual for several reasons: It is an attempt by a language vendor to create a standardization process up front, instead of the process being created later, perhaps long after the language is in general use. It is also an attempt to avoid being the sole creator and owner of the language by opening up the process to the Java community, though still maintaining control of it in various ways. The Java Community Process is not as open as the open source community, where just about anybody is welcome. However, it does give organizations and individuals a formal way of providing input on the future development of the Java language and environment.

The goals of the Java Community Process, as stated in the process manual's executive summary,¹ are laudable, namely:

To promote development of high-quality specifications in "Internet time."
To allow entities who may not have licensed Java technology to participate in the process.
To allow entities to use the process with or without the direct involvement of Sun's engineers.
To require a reference implementation and conformance tests of the specification.
To have an independent entity audit the entire process.

We discuss the Java Community Process in some depth, giving both pros and cons. The discussion is relevant to (a) any cross-industry standardization process, (b) specific to the Java Community Process, and (c) relevant to an individual who participates in that process.

PROCESS DETAILS
To participate in the Java Community Process, one must sign a Java Specification Participation Agreement, which is a one-year renewable agreement between Sun Microsystems Inc. and the participant. The participant may be a company, an organization, or an individual. The participation fee is $5,000 for commercial entities and $2,000 for educational, government, and nonprofit organizations. Organizations that have licensed Java technology for commercial use are not required to pay the fee. Java Community Process participants may submit Java Specification Requests, nominate experts to groups that create Java specifications, and review specifications before their public review.

At each community process milestone, Sun's process management office initiates a milestone audit. The process does not proceed to the next stage until all auditing anomalies for the milestone have been corrected. Prior to completion of the process the process management office initiates a final audit. The final audit covers the entire specification development process and its results are posted on an independent third-party Website.

The community process begins with a Java Specification Request. The request identifies the submitter and the participants who support the request, describes the proposed specification and the reasons for developing it, and the existing documents or implementations that might be used as a starting point. Submitted requests are evaluated by the process management office. Each participant can have up to three submissions under evaluation at a time. The process management office verifies that the submitted specification request is relevant and that it doesn't conflict or overlap with other requests or existing specifications. The community process participants can also provide input to the evaluation process. There are currently three specification requests under evaluation. There are also 37 closed requests, 36 of which have been approved for the specification development process.

Once a specification request has been approved, the process management office issues a call to participants for experts to form an expert group for the specification. When the call closes, the process management office will select a specification lead among the nominated experts. The specification lead then selects the rest of the experts from the set of nominees. The specification lead can also invite experts from participants that did not nominate any experts during the call. There is typically no more than one expert per participant in the group. The specification lead does not have to be an employee of Sun Microsystems: There are currently eight specification leads from Sun and six leads from other companies.

The expert group's work begins with a kickoff meeting, where they review the requirements for the specification and draw an initial straw man of its contents. After the meeting most of the subsequent work is done via e-mail. The different sections of the specification are divided among the experts. Experts can provide input to any section via e-mail discussions. The specification lead coordinates the work and moderates the discussions. In areas where consensus cannot be reached, the lead can arrange straw votes or make decisions based on his/her technical expertise.

The experts provide their corresponding sections to the specification lead, who puts the draft specification together. The specification lead then iteratively distributes the draft versions to experts for comments and revisions.

When the draft is complete enough, it will be distributed to all community process participants. The participants can review and comment on the draft for at least 30 days. Based on the feedback, the expert group will iteratively revise the draft until the review period ends. Upon completion of the participant review, the draft is ready for public review and can be used as a basis for the reference implementation and compatibility test suite. The reference implementation is a proof of concept for the specification. The compatibility test suite consists of tests and requirements that an implementation must pass to be compliant with the specification. Both the reference implementation and the compatibility test suite will be made available upon the specification's release.

Like the participant review, the public review will last for at least 30 days. The draft is published on a public Website where anyone can review and comment on it. The purpose of the public review is to catch architectural and technological issues that might have been missed by the expert and participant reviews. If the public review results in major changes, the revised draft and a revision history will be reposted at the public Website.

Upon completion of the public review, the specification is released for the first time at the public Website. At this stage, the reference implementation and the compatibility test suite may still uncover areas that are incomplete. In such cases, the expert group will correct any problems found and repost the revised specification at least once a month. The corrections are subject to public comments that may result in revisions to the specification.

Once the reference implementation and the compatibility test suite are considered complete, the specification will be promoted to final release. Upon final release, the specification will be posted on the public Website and the expert group will be disbanded.

The maintenance of the specification is organized by an interpretation guru. The specification lead becomes the interpretation guru at the time of final release. During the life cycle of the specification, every release must have an assigned interpretation guru. The interpretation guru is responsible for drafting proposed changes to the specification in response to requests submitted by the community process participants and the public. The specification is maintained by either a lightweight process or, when a major revision is proposed, by the full specification development process.

ADVANTAGES AND DISADVANTAGES
Due to its nature, the Java Community Process removes the burden from Sun of developing specifications for all interest groups or industries. For example, various industry-specific niches might not normally warrant attention from a general language vendor. Within the community process, each industry can produce specifications unique to that industry, which then become part of the officially supported and maintained Java world.

The requirement that there be a reference implementation and a conformance test suite should help stop some of the empty specifications and limit the scope of a specification to something implementable and testable within a reasonable time frame.

The involvement of an independent auditor (currently Price-Waterhouse Coopers) to review the process at key milestones insures that the process is fair with regards to its own procedures. The independent auditor also helps assure the Java community that Sun is honest about the process, and that specifications that may not be popular in some respect with engineers at Sun are still handled fairly.

Even though the Java Community Process is innovative and has many advantages, it has its downsides. First, like most standardization processes, it is "design by committee." The entire process works by consensus building, which can take a long time. It can also mean that what began as an excellent solution to some problem will be altered or watered down to cover more general issues. The specification may become almost unrecognizable to its originators or so vague that conformance to it is trivial.

The process itself may not be open to everybody who wants to participate. Only entities paying the annual agreement fees can be participants. These fees may exclude small companies and universities. The lack of presence of the latter is particularly unfortunate, given the contributions of universities to computing in general. Also, given the amount of time that participation in the process can involve, only larger organizations with people to spare can really afford to participate.

While the notion of a reference implementation would seem to imply that the specification was created before the reference implementation, there is nothing in the process to stop somebody from creating a specification for an existing implementation to gain a marketing advantage.

With the current rate of specification request submissions, there is also the risk of creating multiple redundant or contradictory specifications. Avoiding this requires significant efforts in evaluating the requests and coordinating activities between various expert groups.

CONCLUSION
The advantages of the Java Community Process, as it stands, are great. Even though the process is, by just about any definition, semiopen, it provides a way for organizations and individuals to influence the future direction of Java specifications in a controlled manner. The fact that Sun maintains some control over the process helps to avoid the potential infighting, and general free-for-all associated with some standardization efforts. The benefits of this should not be underestimated. Without some control to decide what constitutes valid specifications, the integrity of the Java language environments would most likely degenerate into competing vendor dialects, which would be the end of "Write Once, Run AnywhereTM."

Reference