---

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.

The Value of User Feedback

Even when a JSR expert group chooses a not strictly open-source license for release of its source code and other artifacts, the expert group benefits from early feedback. Graham Hamilton, Sun's JCP Executive Committee representative, noted the value of community feedback to the Mustang community on java.net, built around the early release versions of JDK 6:

With the Mustang community . . . we're able to make early-access implementations [of Java SE 6] available . . . and we get feedback about the spec as it's evolving. Sometimes developers give us very direct feedback, that's very valuable to an expert group. I guess one benefit is for a broader group of people giving feedback, rather than just [getting feedback from] an expert group.

If non-JCP member developers can already partake in creating the code for a JSR reference implementation and TCK—arguably the most labor-intensive components of a JSR--how would developers benefit from joining the JCP proper? JCP chair Kluyt put it this way:

There are two kinds of developers. Those that are interested in what the plumbing looks like and [want to] help create the plumbing; and those that want to build solutions on top of [that plumbing] . . . I don't think it's practical to assume that half a million developers will be personally motivated to help develop the EJB spec [for instance]. There is some natural filtering that happens [between] developers who want to be active developing the standard versus those developers that are primarily interested making use of the standard.

Asko Komsi, Director of Industry Relations for Nokia, and lead of several Java ME JSRs, pointed out the different roles various Java communities play:

If you really want to work on plumbing, then it's a good idea to join the JCP. [Otherwise] there are organizations like, for instance, Nokia's developer community supporting developers from an application developer's point of view, and we have about 2.5 million members. We can handle that many people.

But could the JCP handle a large influx of new members? Ken Arnold ponders how the JCP could make a standard with, say, 1.5 million JCP members: "While it is a smart question, it will only actually matter when the JCP's question is: 'Given that we need to have smaller companies and individuals, how will we make a standard with 1.5 million JCP members?' When posed that way, it will be solved." JCP chair Kluyt is not so sure: "Just as no open source software project can tolerate millions of committers, neither can the Java community survive with a 1.5 million spec leads."

Whether the JCP can scale up is an open question. What all current JCP members seem to agree, though, is that more individual participation will benefit the JCP. Sun's Hamilton put it this way:

A large number of fairly active practitioners [are] participating. These are the people actually using the technologies they're helping to create. That ultimately leads to a very focused set of advice. These people are very passionate about how they want to use the technology.

EC member Suleiman noted that:

You can see that in a lot of the expert groups now that there is a very active search by the spec leads who will go out to make sure that a number of expert group members are practitioners: people who have an expertise in this area in terms of users, people who adopt the technology, not just people who provide it.

Sun's Hamilton agreed:

We also want technical experts who come at it more from a technology user perspective as opposed to just the vendors who will be creating the technology. Having individual experts who are willing to commit time to JSRs is incredible valuable. But it's quite hard to find people who are willing to spend the time to really impact a JSR.

Indeed, having too many experts providing input into a specification runs the risk not only of producing a result resembling a camel (a horse designed by committee), but also of producing specs that don't address the average user's needs. Hamilton put it this way:

We have to remember that we're designing specs for non-experts . . . You have to consciously think that not everyone is interested in the most exotic corner cases. Most people are interested in the simple cases. Our job as experts is actually to make things simple for common use-cases. Yes, we can have fun worrying about the corner cases, but making the simple cases simple is a big challenge as experts.

In our opinion, more such user-experts would result in better specifications. The communities built around the implementation are really about those implementations, not so much about the specifications. For instance, one would join the Glassfish community to download and use the Java EE 5 reference implementation, not necessarily as a means to provide feedback into some of the Java EE 5 specifications.

We're confident that the spec leads we met during this JavaOne look after the business interests of their employer on their respective expert groups. That's their job. But each one of them also impressed us as smart, competent engineers who care about technology. In our opinion, the value of greater individual involvement in the JCP may not be so much to improve the balance between commercial and purely technical interests, but more to improve the balance between vendor perspectives and those of users.

The JCP's next task is to become more inclusive, and allow for early feedback from users of JSRs, not just for expert feedback. This can be accomplished by expert groups giving greater visibility into discussions taking place among experts, and by having mechanisms for user feedback and comments on those discussions.

Conclusion

In his blog post, Ken Arnold noted that:

People seem more worried about the possibility of pointless feedback than about missing valuable feedback. That's just weird. I've lived in many public design situations, and the occasional problem child is many times overweighed by the value of the feedback of passionate people you didn't think to involve, or the massive feedback of casual users who, as outsiders, can tell you when you aren't doing things that serve them.

While it is true that too many cooks in the kitchen can slow down the development of JSRs and place a bigger burden on already busy spec leads, expert groups would still benefit from members that provide user feedback on the specification itself.

Resources

Ken Arnold's blog post about the JCP, JCP Wants You, Sort of, It Thinks...:
http://weblogs.java.net/blog/arnold/archive/2006/05/jcp_wants_you_s.html

JCP.org
http://www.jcp.org

Talk back!

Have an opinion? Readers have already posted 5 comments about this article. Why not add yours?

About the authors

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. He is an elected member of the Jini Community's Technical Advisory Committee.

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima Developer. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.