Matching JDK and JCK Versions
By Darcy-Oracle on Mar 06, 2008
For those interested in verifying conformance of a JDK, from engineers working on the code base to porters and independent implementors, it is important to pair a JDK with the proper version of the compatibility tests.
Generally in the JCP, a JSR has three deliverables, a specification, a reference implementation, and a technology compatibility kit (TCK). For the Java SE platform umbrella JSR, Sun's JDK is the reference implementation and the Java compatibility Kit (JCK) serves as the TCK.
In this context, the reference implementation refers to a specific binary and, more colloquially, to the code used to produce that binary. The reference implementation of a JSR may or may not change over time. The JDK updates that do come out are improvements to the same specification, with better performance, more bugs fixed, occasional upgrades to select APIs, and additional non-platform APIs, but do not necessarily become the new reference implementation of the Java SE platform specification. Currently, the original JDK 6 remains the reference implementation for Java SE 6, JSR 270, although several JDK 6 updates have been release since then and more are on the way. One pathway for the reference implementation to be upgraded (along with small changes to the specification) is a JCP maintenance update, but to date such a maintenance update has not been done for a Java SE platform JSR. Another way the reference implementation for a specification can be changed is by the release of a new JCK version which cites a different RI. The cited RI must pass the corresponding JCK version. Just as JDK updates are a better implementation of the same specification, JCK updates are a more thorough test of the same specification. For example, when JDK 6 first shipped, JCK 6 was available. Since then, JCK 6a has been developed and one improvement in was the addition of many tests for annotation processing and the language model of JSR 269.
When a new JCK version is shipped, it obsoletes the previous version. JDK implementations which first ship 120 days after a new JCK is released must test against the new version for compliance rather than the old one. For example, JCK 6a was released in June 2007. 120 days after it shipped, it became the JCK suite that must be passed for Java SE 6 compatibility so JCK 6a is now the version of the JCK in force. JCK 6b is in the works and will likewise supplant 6a in due course. Besides adding new tests, JCK updates can also delete invalid tests or place them on the exclude list.
For JCP technologies that are standalone as well as bundled with the platform, the version of the standalone technology in use can be upgraded and with such an upgrade the corresponding TCK may need to be upgraded too. For example, JDK 6 originally shipped with JAX-WS 2.0, but both JDK 6u4 and OpenJDK 6 have been updated to JAX-WS 2.1. There is an alternate bundle with tests specific to JAX-WS 2.1, including signature tests covering new API elements.
So as of March 2008, the proper JCK version to test OpenJDK 6 is JCK 6a with the alternate bundle for JAX-WS 2.1. After JCK 6b ships, we'll start running tests using that version, which assumes JAX-WS 2.1 by default. (The JAX-WS version is simply a configuration option in JCK 6b). If you're interested in running the JCK in context of OpenJDK projects, a license is available.