Community Hub0 Subscribers
Community hub
Technology Compatibility Kit
View on Wikipediafrom Wikipedia
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)
Contents and architecture
[edit]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 much real-world testing to address these shortcomings, although additional test suites such as JDTS may help.
TCK for the Java platform
[edit]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.[1][2] The associated license did not initially allow users to compile or run the tests,[3] but the right to see the code is not associated with tainting concerns, and public comments on the source code are allowed.[1] 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.[4][5]
The OpenJDK Community TCK License Agreement v 2.0 has been published for the Java SE 7 Specification since December 2011.[6]
TCK framework
[edit]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.[7]
License and controversy
[edit]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.[8]
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.[9]
On December 9, 2010, the Apache Software Foundation resigned its seat on the Java SE/EE Executive Committee.[10]
See also
[edit]References
[edit]- ^ a b Hamilton, Graham (2004-12-13). "J2SE Compatibility Test Sources Released". Archived from the original on 2004-12-16. Retrieved 2008-03-08.
We have tried to make sure the license meets the reasonable needs of developers who want to evaluate the JCK sources: It's available at zero cost, through a click-through license; There is no "tainting". Once you delete your copy of the JCK, you aren't constrained in your future actions. To try to make this really clear, we included a section explicitly granting what the lawyers call "residual rights", which basically means that stuff that sticks in your head is OK to use in the future; You can publish feedback and comments publicly.
- ^ JCK project Archived July 8, 2007, at the Wayback Machine
- ^ ""READ ONLY" SOURCE LICENSE AGREEMENT, v1.0 JAVA (TM) COMPATIBILITY KIT 6a". Sun Microsystems. June 2007. Archived from the original on 2010-12-31. Retrieved 2008-03-08.
- ^ Darcy, Joseph (2008-03-06). "Matching JDK and JCK Versions". Archived from the original on 2011-08-12. Retrieved 2008-03-08.
If you're interested in running the JCK in context of OpenJDK projects, a license is available.
- ^ "OPENJDK COMMUNITY TCK LICENSE AGREEMENT V 1.1" (PDF). Sun Microsystems. Retrieved 2008-03-08.
Subject to and conditioned upon its Licensee Implementation being substantially derived from OpenJDK Code and, if such Implementation has or is to be distributed to a third party, its being distributed under the GPL License, Sun hereby grants to Licensee, to the extent of Sun's Intellectual Property Rights in the TCK, a worldwide, personal, non-exclusive, non-transferable, limited license to use the TCK internally and solely for the purpose of developing and testing Licensee Implementation.
- ^ "OpenJDK Community TCK license agreement V 2.0" (PDF). openjdk.java.net.
- ^ "Source Code Browse: jsr-352-git-repository". Archived from the original on 2013-03-05. Retrieved 2014-02-12.
- ^ "OPENJDK COMMUNITY TCK LICENSE AGREEMENT V 1.1" (PDF). Sun Microsystems. Retrieved 2008-03-08.
Subject to and conditioned upon its Licensee Implementation being substantially derived from OpenJDK Code and, if such Implementation has or is to be distributed to a third party, its being distributed under the GPL License, Sun hereby grants to Licensee, to the extent of Sun's Intellectual Property Rights in the TCK, a worldwide, personal, non-exclusive, non-transferable, limited license to use the TCK internally and solely for the purpose of developing and testing Licensee Implementation.
- ^ Statement by the ASF Board on our participation in the Java Community Process, Apache Software Foundation blog, 2010-11-09
- ^ The ASF Resigns From the JCP Executive Committee, Apache Software Foundation blog, 2010-12-09
External links
[edit]| Platforms |
| _waving.svg) | |||||
|---|---|---|---|---|---|---|---|
| Technologies |
| ||||||
| History | |||||||
| JVM languages | |||||||
| Community |
| ||||||
Technology Compatibility Kit
View on Grokipediafrom Grokipedia
Definition and Purpose
Overview of TCK
The Technology Compatibility Kit (TCK) is a suite of tests and associated tools used to certify that an implementation of a Java technology conforms to its corresponding specification and the Java platform. Developed under the Java Community Process (JCP), the TCK verifies compliance with Java Specification Requests (JSRs), ensuring that certified products adhere to defined APIs, behaviors, and compatibility requirements. This process supports the Java platform's core principle of interoperability across diverse environments.[9][3] TCKs are tailored to specific Java technologies, such as Java SE (where it is known as the Java Compatibility Kit or JCK) or Jakarta EE, and include automated test harnesses that exercise implementation features against specification-defined criteria. Successful completion of TCK tests allows vendors to claim compatibility, fostering ecosystem trust and enabling "write once, run anywhere" portability. The kits typically encompass thousands of test cases covering functional correctness, error handling, and optional features.[4][5] Originating from Sun Microsystems, the TCK framework has been integral to Java's standardization since the platform's early days, with ongoing maintenance by Oracle and community efforts ensuring relevance to evolving specifications. Access to TCKs, such as the JCK, is provided to qualified developers intending to produce compatible Java SE distributions, often under license agreements.[6][4]Role in Ensuring Compatibility
The Technology Compatibility Kit (TCK) functions as a comprehensive suite of automated tests and tools that verifies whether an implementation of a Java specification adheres to its defined requirements, thereby enabling certification of compatibility across multiple vendor products.[10] This verification process confirms that the implementation supports the specification's APIs, behaviors, and semantics without proprietary extensions that could fragment the ecosystem.[9] By establishing a common benchmark, the TCK mitigates interoperability risks, ensuring that applications and libraries portable to one compliant runtime will execute predictably on others.[3] To achieve compatibility certification, implementers must execute the full TCK against their platform, achieving 100% pass rate for all applicable tests, which include unit tests, integration tests, and performance validations tailored to the specification's scope.[10] Failure to pass even a single test disqualifies the implementation from claiming conformance, enforcing rigorous adherence to the Java Community Process (JCP) standards.[11] This mechanism has been integral since the JCP's inception, with Oracle maintaining oversight for Java SE TCKs, while community-driven efforts under the Eclipse Foundation handle Jakarta EE equivalents to sustain open-source compatibility.[12] The TCK's role extends beyond binary pass/fail outcomes by providing detailed reporting on test coverage, assertions mapped to specification clauses, and diagnostic tools for debugging failures, which facilitate iterative refinement during development.[13] In practice, vendors like Azul Systems and Red Hat have leveraged TCK compliance to certify alternative Java distributions, demonstrating that non-Oracle implementations can achieve equivalent reliability without altering core behaviors.[3] This certification is often formalized through licensing agreements with Oracle for trademark usage, underscoring the TCK's position as the definitive arbiter of Java ecosystem cohesion.[6]Historical Development
Origins Under Sun Microsystems
The Technology Compatibility Kit (TCK) emerged at Sun Microsystems during the mid-1990s as an essential tool for validating compliance with Java specifications, coinciding with the platform's initial public rollout on May 23, 1995. Sun developed the TCK—initially known as the Java Compatibility Kit (JCK)—to enforce the "write once, run anywhere" principle by testing implementations against the Java Virtual Machine (JVM), core class libraries, and language features defined in Sun's reference specifications. This suite of automated and manual tests addressed the risk of incompatible variants proliferating through third-party vendors, which could fragment the ecosystem and erode portability across operating systems and hardware. By requiring licensees to pass these tests for branding rights like "Java Compatible," Sun established a rigorous certification process that prioritized empirical verification over self-reported adherence.[4][14] Sun's TCK development was driven by the need to monetize Java indirectly while distributing the runtime and development tools freely, often charging fees for TCK access and certification to offset development costs estimated in the millions annually. Early versions focused on Java SE (Standard Edition) equivalents, with tests covering API behavior, bytecode execution, and security constraints, ensuring causal consistency in program outcomes regardless of the underlying implementation. This approach stemmed from first-hand experience with early adoption challenges, such as Microsoft's partial Java support in Internet Explorer, which prompted Sun to litigate over compatibility breaches in 1997. The TCK's architecture emphasized exhaustive coverage, including negative testing for edge cases, to minimize runtime discrepancies that could arise from vendor-specific optimizations.[15][7] With the formalization of the Java Community Process (JCP) in December 1998, Sun integrated TCK requirements into Java Specification Requests (JSRs), mandating test suites for each new feature or edition to accompany reference implementations. This evolution under Sun's stewardship until 2009 solidified the TCK as a gatekeeper for ecosystem integrity, influencing over a dozen specifications by the early 2000s and enabling licensed implementations from vendors like IBM and BEA Systems. Sun's proprietary control over TCK licensing, while enabling revenue, later drew scrutiny for hindering open-source efforts, but it undeniably preserved Java's uniformity during its formative years.[16][17]Transition to Oracle and Key Milestones
Oracle Corporation completed its acquisition of Sun Microsystems on January 27, 2010, for $7.4 billion, thereby assuming stewardship of the Java platform and associated technologies, including the Technology Compatibility Kits (TCKs) used to certify implementation compatibility with Java specifications.[18][19] This transition integrated TCK management into Oracle's operations, with the company continuing Sun's practice of licensing TCKs under agreements that required passing all tests for branding as Java-compatible, while restricting use to maintain specification fidelity.[20] Post-acquisition, Oracle updated the Oracle Binary Code License Agreement (BCLA) in 2010, which influenced the terms under which TCK-licensed implementations could be distributed and commercialized, emphasizing commercial support models over purely free usage.[21] A significant early milestone occurred in October 2010, when Oracle refused to license the Java SE TCK to the Apache Software Foundation for its Harmony project without field-of-use restrictions excluding mobile environments, leading Apache to withdraw from the Java Community Process (JCP) Executive Committee and accelerating industry adoption of OpenJDK as an alternative base.[22][23] This decision, consistent with prior Sun policies, prioritized preventing partial compatibility claims that could fragment the ecosystem but drew criticism for limiting open-source alternatives.[24] Subsequent milestones included the July 28, 2011, release of Java SE 7 and its accompanying TCK, the first major platform update under Oracle's full control, which introduced features like the invoke dynamic instruction and required extensive TCK validation for certified vendors.[25] In 2018, Oracle reaffirmed support for the OpenJDK Community TCK License Agreement (OCTLA), originally launched by Sun in 2007, enabling non-commercial OpenJDK builds to undergo TCK certification under community terms, thereby facilitating verified compatibility for distributions like those from Adoptium and Azul.[20] These developments sustained TCK's role in the Java ecosystem, with Oracle licensing the suite to third parties—such as IBM and Red Hat—for ongoing compatibility assertions amid rising OpenJDK adoption.[26]Technical Components
Contents and Architecture
The contents of a Technology Compatibility Kit (TCK) primarily comprise a suite of automated tests designed to verify compliance with a Java specification, including API signature tests, behavioral tests, and coverage of specification assertions. These tests are often implemented using frameworks like TestNG or JUnit and may incorporate annotations such as@SpecAssertion to link individual tests directly to requirements in the specification document.[9][27] Additional contents include supporting resources like test descriptors (e.g., tck-tests.xml), supplemental data files, and tools for execution and reporting, ensuring comprehensive validation of an implementation's conformance to both functional and non-functional aspects of the specification.[27] Documentation forms a critical part, encompassing user guides for running tests, configuration instructions, and coverage reports that map tests to specification sections, often delivered via templates from the Java Community Process (JCP).[5]
The architecture of a TCK is modular and harness-centric, typically built around a test execution framework such as the JT Harness (formerly JavaTest), which provides a flexible structure for configuring, sequencing, and running large numbers of independent tests.[9][5] This harness integrates plug-in components for test discovery, execution, and result logging, with architects defining the overall framework—including test directory structures, indexing of precompiled tests, and site-specific configuration mechanisms like interviews that gather implementation details (e.g., Java launcher paths).[9] Specialized tools, such as SigTest for API signature verification and APICover for coverage analysis, extend the core harness to handle compatibility checks, while container-specific adapters (e.g., Arquillian for in-Jakarta EE testing) enable portable execution across environments.[5][27] The design emphasizes scalability and repeatability, with tests organized hierarchically in directories and executed via command-line or GUI interfaces, producing standardized reports for certification.[9] This structure allows expert groups under the JCP to develop TCKs that rigorously enforce specification fidelity without vendor-specific biases.[5]
TCK Framework and Testing Mechanisms
The TCK framework encompasses a test harness, suite of executable tests, configuration tools, and reporting mechanisms engineered to validate an implementation's adherence to a Java specification's behavioral and functional requirements. Central to this is the JavaTest harness, a Java-based execution engine that automates test discovery, invocation, and outcome logging across diverse runtime environments. Developed under the Java Community Process (JCP), the framework ensures comprehensive coverage by structuring tests as modular Java programs that systematically probe APIs, classes, and runtime behaviors against spec-defined assertions.[28][11] Testing mechanisms operate through a phased process: initial configuration via interactive "interviews" or XML files to parameterize the target implementation (e.g., specifying JVM paths, test subsets, or exclusion filters), followed by test execution where the harness launches isolated test instances within or against the candidate runtime. Each test case employs assertions to verify outputs, exceptions, and resource handling match specification mandates, with support for parameterized variations to probe edge cases like concurrency or resource constraints. The framework integrates result aggregation into HTML or XML reports, categorizing outcomes as pass, fail, or unsupported, while generating verbose logs for diagnostic purposes.[11][28] For specialized implementations, such as embedded or device-oriented Java profiles, the framework extends via deployable agents that bridge host-based harnesses with target systems, enabling remote test dispatch and telemetry collection without direct console access. This architecture prioritizes determinism and repeatability, mandating that all tests be self-contained, non-destructive, and independent to minimize environmental interference during certification runs. Documentation accompanying the framework details harness extensions for custom assertions or plugins, ensuring adaptability across JCP specifications while upholding portability invariants.[29]Applications in Java Ecosystem
TCK for Java SE
The Technology Compatibility Kit (TCK) for Java SE, formally known as the Java Compatibility Kit (JCK), consists of an extensive suite of automated tests that validate an implementation's adherence to the Java SE platform specification.[6] It encompasses tests for core APIs, class libraries, language semantics, virtual machine behavior, and other components outlined in Java Specification Requests (JSRs) ratified by the Java Community Process (JCP).[3][4] For instance, the JCK for Java SE 8 includes approximately 126,000 tests, while the version for Java SE 11 features around 139,000 tests, ensuring comprehensive coverage of specification requirements.[3] To achieve certification as Java SE compatible, an implementation—such as a JDK distribution derived from OpenJDK—must execute the full JCK without failures or exclusions, confirming behavioral equivalence to the reference implementation.[3][6] Vendors integrate JCK testing into continuous integration pipelines, with full test runs typically requiring about one day, augmented by manual oversight for interactive components like printing or audio output.[3] Successful completion enables the use of official compatibility branding and provides patent protection grants from Oracle for the covered specifications.[3] Access to the JCK is granted at no cost to developers or organizations planning to deploy production-ready, compatible Java SE implementations, subject to the OpenJDK Community TCK License Agreement (OCTLA).[6] Qualification involves submitting a request form, signing the OCTLA (such as version 4.0 for Java SE 21), and optionally the Oracle Contributor Agreement for potential OpenJDK contributions.[6] The agreement restricts usage to compatibility verification, prohibits test suite redistribution, and limits support to a private mailing list, with additional branding services available via Oracle.[6] Distributions from vendors like Azul (Zulu), Adoptium (Temurin), and Amazon (Corretto) routinely pass JCK tests to substantiate their compatibility claims, fostering ecosystem interoperability.[3]TCK for Java EE and Jakarta EE
The Technology Compatibility Kit (TCK) for Java EE and Jakarta EE verifies that application server implementations adhere to the platform's specifications, ensuring portability of enterprise Java applications across certified runtimes. Developed initially by Sun Microsystems under the Java Community Process (JCP), the Java EE TCK evolved through versions from Java EE 5 (2006) to Java EE 8 (2017), testing compliance for APIs such as Enterprise JavaBeans (EJB), Java Persistence API (JPA), and Servlets.[10] Oracle maintained the TCK during its stewardship, requiring vendors to pass all tests for compatibility branding, with suites encompassing compile-time checks, API verifications, and runtime behavioral tests.[30] In November 2017, Oracle donated Java EE to the Eclipse Foundation, leading to its rebranding as Jakarta EE; the TCK was subsequently updated to align with this transition, including namespace changes fromjavax.* to jakarta.* and adaptations for open governance.[12] The Jakarta EE TCK, hosted as open-source projects under Eclipse, covers the full platform and Web Profile for releases like Jakarta EE 8 (2019), 9.1 (2022), and 10 (2022), incorporating tests for over 20 specifications including Jakarta CDI, Batch, and RESTful Web Services.[31] It features modular test harnesses, such as Arquillian for integration testing, and requires execution of Type 1 (compilation), Type 2 (API signatures), and Type 3 (behavioral) tests.[32]
Vendors like Oracle (GlassFish), Red Hat (WildFly), and Payara achieve certification by running the full TCK—often comprising 40,000 to 50,000 test cases—against their servers, targeting 100% pass rates; for instance, Payara reported executing 49,850 tests for Jakarta EE 8 compatibility in 2019.[33] Under the Eclipse Foundation's TCK License, certified implementers must publicly report results and grant interoperability rights, fostering multi-vendor ecosystems while prohibiting use of the Jakarta EE logo without verified compliance.[12] This process supports Java SE 11+ runtimes in later versions, enhancing modern deployment options like containers.[34]