OSCON Java: Here's to improving TCK transparency in JSR 348 and JCP.next

O'Reilly's OSCON Java in summary so far: Good crowd, high quality sessions, and an unbeatable rock star to attendee ratio. The new, all-Java track of O'Reilly's annual Open Source Convention may be off to a slower start this year, in attendance, but that opens the way for richer conversation and less conference overload -- a definite plus for this professional wallflower.

My day-one session schedule included Greg Luck's overview of Java caching and what looks to be a very exciting addition to Java EE 7, JSR 107, JCache; Tim Berglund's "7 things you'll love about Grails" (a beginner's introduction); Daniel Hinojosa's demo of using test cases to learn Scala; and the much-buzzed "Java Standards Annoyances" fishbowl session hosted by Java 7 developers Ben Evans and Martijn Verburg. While not quite the brouhaha that some had undoubtedly anticipated (and others dreaded), the forty-minute panel discussion did offer at least one important revelation: JCP Chair Patrick Curran's comment that Oracle has already begun "opening" the Java TCK.

According to the JSR 348 working draft, what this currently means is improved transparency. Current recommendations in progress are that (1) a list of compatible implementations be published; (2) TCK documentation be publicly available; (3) the TCK User's Guide include compatibility requirements; and (4) TCK implementors be permitted to discuss TCK test results.

These changes together would be a big step forward, said panelists Dan Allen and David Blevins. As experienced JCP wranglers, the two agreed that the historic lack of transparency in the TCK has been a hurdle to the open source process. Developers wishing to have their tools standardized had to pass the TCK test suite under non-disclosure agreement, making it impossible to benefit from community input in the code-hardening process.

Lack of transparency has also made it difficult to know on what grounds a product would be denied or allowed certification, said Allen. Whether intended or not, this lack of firm footing has had the effect of slowing down the certification process for emerging and competitive technologies.

"Obtaining certification is a long and very TCK-driven development process," said Blevins, sometimes taking a year or more for products requiring Java EE certification. "When those TCKs are closed and require non-disclosure of any details other than 'yes we pass' or 'no we don't pass'" the effect is to "push large and important aspects of the project into secrecy, making it all but impossible to keep openness in the development process," he said.

By increasing the transparency of the Java certification process, Oracle could alleviate the concern that it will use the JCP simply to drive a marketing agenda, said Allen.

Panel moderator Ben Evans, also a sitting member of the JCP's Java SE/EE Executive Committee, called updating the TCK licensing requirements simply "good housekeeping."

"Restrictions on discussing test suites and test results are just plain stupid and counter-productive. They're quite common in some parts of the financial industry, and we know the effect that they have there. What happens is that while firms may have no choice but to use products with NDA'd test suites, then they put up with them, but as soon as there's a more open alternative, customers vote with their feet."

Both Evans and Curran highlighted JSR 348 as an opportunity for community involvement in the re-evaluation of legacy structures in light of Oracle's new stewardship.

"That's one of the great things about the fact that JSR 348 is in play," said Evans, "we have an opportunity to go through the process and spring-clean -- get rid of any legacy restrictions which just don't make sense any more."

View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies