At JavaOne 2008, the Java Community Process (JCP) program office organized a press roundtable. Normally, such events would be of little interest to developers, since the JCP is more about process than about code. Few developers have cycles to spare for less-than-stimulating process-related discussions.

This year, however, the JCP roundtable discussion focused on a topic rather relevant to most Java developers: the intersection of open standards and open source, and by extension, de facto standards and de jure standards.

The JCP has in recent years encouraged JSR spec leads to be as open as possible in the manner a JCP standard is developed. JCP executive committee members—the group of JCP members overseeing the smooth operation of the Java ME, SE and EE standards—have nudged spec leads towards open-source licenses. Indeed, on several occasions, executive committee members voted down JSR proposals on the basis of a spec having an overly restrictive license. The JCP's new chair, Patrick Curran, noted several times during the roundtable that a fully open-source spec is the closest to the JCP's ideal in terms of both licensing and process.

And therein lies a certain tension between the JCP's process and open-source development. The JCP requires that each Java specification develop and maintain three distinct artifacts: the specification document, a reference implementation (RI), and a compatibility test kit (TCK). By contrast, many de facto open-source standards, such as Hibernate, Spring, the Apache web server, and so on, are widely-used open-source tools not backed by a formal spec or a compatibility test kit.

A JSR reference implementation often becomes the primary vehicle through which developers use a JCP standard: Tomcat, for instance, is the reference implementation for the Servlet JSR, and the Glassfish app server is the reference implementation of the Java EE standard. Having to develop a formal specification and a TCK is what makes a JSR spec a spec, however. Without passing the TCK, an implementation cannot claim to be compatible with a JSR spec.

That seems like a reasonable requirement. But developing and maintaining a good TCK is a huge task, and one few open-source projects are accustomed to. The JCP's Patrick Curran, who formerly headed up Sun's Java SE implementation team, mentioned that Sun has invested several hundred man-years in the Java SE TCK, for example.

The requirement for a comprehensive TCK has two implications: First, individual JCP members can hardly hope to complete a JSR without some serious dedication of time to the JSR. Without corporate backing—a company paying for the time to develop a TCK, in addition to a reference implementation—a JSR with only individual expert group members has a slim chance of success. Second, why would a corporation invest potentially many man-years' effort into a JSR TCK, if all of that code is given away in a open-source manner? The standard open-source business model of selling services on top of an open-source tool is not practicable in the case of developing and maintaining a TCK.

So far, the significant JCP JSRs all had major corporate backers. David Nuescheler, spec lead for the Java Content Repository API told me once that his company, relatively small Day Software, bore a significant burden in spearheading JSR 170. If the JCP wants to operate in a more open-source manner, and solicit the contributions of lots of individual developers, it may need to make some changes.

The JavaOne roundtable brought up this issue without a resolution. One option was to drop the requirement for a TCK. That would mean that JSR implementations would "self-certify" compliance, and the marketplace would sort out which implementations are trustworthy. Another path is to continue the practice of charging for most TCKs, giving open-source projects and non-profits a "scholarship," or some other form of a free license.

What do you think of the JCP's requirement to develop and maintain a TCK for each JSR? How would you reconcile the heavy burden of the TCK with the need to develop JSRs in a completely open-source manner?