A Technology Compatibility Kit (TCK) is a suite of tests that at least nominally checks a particular alleged implementation of a Java Specification Request (JSR) for compliance. It is one of the three required pieces for a ratified JSR in the Java Community Process, which are:the JSR specification
the JSR reference implementation
the Technology Compatibility Kit (TCK)
TCKs tend to be obtained from the Specification Lead of a given JSR. They usually (but not always) consist of a graphical host application which communicates over TCP/IP with the device or Java virtual machine that is under test. Tests are typically obtained by the device over HTTP, and results are posted back to the host application in a similar way. This decoupling enables TCKs to be used to test virtual machines on devices such as CLDC mobile phones which do not have the power to run the full TCK host application.
The tests contained in the JSR are supposedly derived from the statements in the JSR specification. Any given API will have a set of tests to ensure that it behaves in the intended way, including in error conditions.
In order to state conformance with a given JSR, a Java implementation has to pass the associated TCK. Any (rare) exceptions have to be negotiated with the specification lead. Because of this, TCKs are of great importance when implementing a JSR. The first great milestone is to get the TCK running in the first place, which necessarily involves the Java implementation and underlying networking stack having a certain level of maturity. Next, the TCK must be properly configured - because they must be flexible enough to cope with any implementation, there are many options. (For example, listing all the supported media formats and associated optional controls for JSR135). Particular tests also require some setup activity - this tends to be particularly complex for the tests which ensure correct behaviour in error conditions, because the Java implementation must be put in the right state to cause each error. Finally, each failing test must be fixed, which is usually handled by the usual defect tracking mechanisms.
Some Java implementors consider their product to be mainly complete once the TCKs pass. Whilst it's true that the TCKs are quite comprehensive, there are many areas that they do not cover. These include performance, as well as the optional features. There's no alternative but to do lots of real-world testing to address these shortcomings, although additional test suites such as JDTS may help.
The Technology Compatibility Kit for a particular Java platform is called Java Compatibility Kit (JCK). It is an extensive test suite used by Oracle and licensees to ensure compatible implementations of the platform.
The JCK for Java 6.0 source code has been released. The associated license did not initially allow users to compile or run the tests, but the right to see the code is not associated with tainting concerns, and public comments on the source code are allowed. However, since the release of OpenJDK, a specific license allows running the JCK in the OpenJDK context, that is for any GPL implementation deriving substantially from OpenJDK.
The OpenJDK Community TCK License Agreement v 2.0 has been published for the Java SE 7 Specification since December 2011.
The JavaTest harness tool is today the most common unit testing framework used to verify the implementation compliance. It is a general purpose testing framework designed to run TCK tests. However, some specifications are also using JUnit or TestNG.
Subsequent to Sun's release of OpenJDK, Sun released a specific license to permit running the TCK in the OpenJDK context for any GPL implementation deriving substantially from OpenJDK.
This requirement denies the Apache Harmony project an Apache License-compatible right to use the TCK. On November 9, 2010, the Apache Software Foundation threatened to withdraw from the Java Community Process if they were not granted a TCK license for Harmony without additional restrictions.
On December 9, 2010, the Apache Software Foundation resigned its seat on the Java SE/EE Executive Committee.