Summary
A JavaOne 2008 roundtable focused on the potential conflict between the way open-source communities work and the JCP's requirement for a Java specification expert group to develop and maintain a compatibility test kit.

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?

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.