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?
> <p>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?</p>
The TCK is essentially a large unit test suite - a good thing to have. And the spec is essentially nice documentation, also a good thing.
If open source developers aren't used to developing such things, then they should get used to it, if they want to work on a JSR. There's no reason to relax the requirements of the JCP. Experience has shown that TCKs and specs are worthwhile, otherwise, they'd be gone by now.
If some individual open source developer doesn't think these things are worthwhile, he can simply develop his own implementation outside the JCP. If it survives on the merits, the JCP will eventually adopt it.
I think that TCKs and RIs are important. That's the difference between paperware and a specification that works. RIs are useful to make sure that specifications can be implemented. TCKs are useful to make sure that an application based on the spec is portable across products compliant with that spec.
Note that it's always possible to develop a bad specification even if there is a TCK and a RI available.
I think it should be a best practice for open-source developers to use test-driven development. The TCK would be then much less of an effort. Whenever a developer tells me that creating tests for his application are going to increase the cost, then I will tell him that he hasn't understood anything to Agile development.
That's a little bit the problem with these JSRs, I don't feel the agility. I would like to see everyday what's happening in these projects, and have early access to RI beta code. Like for open-source projects.