In this editorial, we argue that greater individual involvement in the JCP would lead
to better specifications, and that more individual developer members could provide a
healthy balance between vendor perspectives and those of users.

In his JavaOne keynote, Sun's new CEO Jonathan Schwartz credited the Java Community
Process (JCP) for Java's widespread use and industry acceptance, but lamented that
there are not enough individual members of the JCP:

This is not a heavy-weight corporate kind of environment. You go to JCP.org, you
register as an individual . . . We want to make sure that all voices are heard in the process
. . . This is not about corporations defining a technology platform, this is about users and
citizens and developers defining that platform.

In a recent blog entry, Ken Arnold responded that the JCP is still a corporate-heavy
organization, and pointed to lack of individual representation as an important reason for
the relatively few individual JCP members:

Obviously there are simply too few actual individuals on the EC [executive committees] . .
. . Two of sixteen [executive committee members] in one case, and zero of sixteen in
another, isn't much representation for us individuals who are being pushed to sign up. If
we sign up, where is our practical representation as major stakeholders? . . . In political
terms, this is an oligarchy, a governing system where the final decisions are in the hands
of an elite . . . As individuals we should join, but the JCP needs a more open system that
allows all stakeholders, not primarily the largest, a part in the final decisions.

While joining the JCP as an individual member is free, Arnold suggests
the eleven-page legal document individual applicants must sign is an impediment.
Even if that barrier were lowered, how would an individual
developer benefit by joining the JCP? And how would the JCP benefit from more
individual members?

Time Demands of the Reference Implementation and TCK

We gained some insights into the issue of individual JCP membership while moderating a
JavaOne panel on the JCP. The panel included several members of the JCP executive
committees and a few spec leads, and among the topics discussed was the JCP's
relationship to other Java communities and individual developers.

According to JCP chair Onno Kluyt about 65% of the 1050 members are individuals,
the rest represent commercial or non-profit organizations. While an individual's most obvious
benefit of joining the JCP is the ability to vote on executive
committee members, a more exciting reason is to participate on expert groups that
develop the JCP specifications.

Each expert group specification lead is free to decide the manner in which his or her JSR specification
work is conducted, as well as the license for the expert group's end products (which may
be an open-source license). What the specification lead is not free to decide, though, is just
what those products are. For every specification, the JCP mandates a reference
implementation (RI) as well as a technology compatibility kit (TCK)—a set of automated tests used to verify
the conformance of other implementations to the spec.

The requirement for a working RI and TCK distinguish the JCP
from other standards bodies, and ensure that the specification defines a realistic and
useful system. The result is that for every finished JSR, there is a working
implementation—something you can test and download, provided the expert group's
license allows for free distribution. However, this requirement also puts the onus on the
expert group members to produce the RI and TCK along with
the specification document.

The RI and TCK requirements are probably the biggest impediment against individual members.
JCP members representing themselves on expert groups seldom have the time to dedicate
to writing the large amounts of code often required for the RI and
TCK. One of the panelists, Hani Suleiman, CTO of Formicary and one of the two individual
executive committee members, noted that:

Joining an expert group . . . is a much bigger investment [than joining Java.net, for
instance]. There's a much higher barrier to entry [and] most developers will not want to
do that because it expects a lot of them. It's a big investment personally. For a company,
they need to dedicate resource to it, towards furthering a spec. Which is why the JCP will
always be much smaller than Java.net.

Because not just discussion, but real work is expected of the expert group members, the
JCP's requirements for a RI and TCK may seem to favor large
companies with significant resources to dedicate to the process. More recently, however,
expert groups increasingly take advantage of open source communities to develop the
reference implementation.

Glassfish, for instance, is the reference implementation of Java EE 5 (JSR 244), and is
developed as an open-source project on Java.net.
According to the project's online
documentation, the Glassfish community has over 100 contributors, noting that "The
number of Sun and Oracle engineers working on this product is comparable in size to
other application server developer communities today." Anyone, including individual
java.net members who are not JCP members, can request a contributor account from the
project lead.

JAXB and JAX-RPC are other examples of JSRs that develop their reference
implementations that way. JSR 170, the Java Content Repository API, in turn, chose the
Apache community to develop its reference implementation and TCK. And perhaps the
best-known Apache-developed reference implementation is Tomcat, which serves as the
official reference implementation for the Servlet and JSP specs.