El kit de compatibilidad tecnológica, más conocido por sus siglas en inglés TCK (Technology Compatibility Kit), es una suite de pruebas que, al menos nominalmente, comprueba una implementación particular de una supuesta Java Specification Request (JSR) para su cumplimiento. Es una de las tres piezas necesarias para una ratificación de una JSR en el Java Community Process, que son:
Los TCKs tienden a ser obtenidos del Líder de la Especificación (Specification Lead) de un determinado JSR. Por lo general (pero no siempre) consisten en una aplicación host gráfica que se comunica a través de TCP/IP con el dispositivo o máquina virtual de Java que se encuentra bajo prueba. Las pruebas se obtienen típicamente por el dispositivo a través de HTTP, y los resultados se devuelven a la aplicación host de una manera similar. Este desacoplamiento permite que los TCKs sean utilizados para probar máquinas virtuales en dispositivos como teléfonos móviles CLDC que no tienen la potencia para ejecutar la aplicación host del TCK completa.
Las pruebas contenidas en el JSR se derivan supuestamente de las declaraciones contenidas en la especificación JSR. Cualquier API determinado tendrá un conjunto de pruebas para asegurar que se comporta de la forma prevista, incluso en condiciones de error.
Con el fin de establecer la conformidad con un determinado JSR, una implementación de Java tiene que pasar el TCK asociado. Cualquier excepción (rara vez) tiene que ser negociada con el líder de la especificación. Debido a esto, los TCKs son de gran importancia cuando se implementa un JSR. El primer gran hito es conseguir que el TCK se ejecute en primer lugar, lo que necesariamente implica la implementación de Java y la pila de red subyacente teniendo un cierto nivel de madurez. A continuación, el TCK debe estar correctamente configurado puesto que hay muchas opciones, debido a que deben ser suficientemente flexibles para hacer frente a cualquier aplicación (por ejemplo, listando todos los formatos multimedia soportados y los correspondientes controles opcionales para la JSR 135). Algunas pruebas particulares también requieren algún tipo de actividad de instalación - esto tiende a ser especialmente complejo para las pruebas que aseguran el correcto comportamiento en condiciones de error, debido a que la implementación de Java debe ser puesta en el estado correcto para provocar cada error. Finalmente, cada prueba fallida debe ser corregida, lo cual suele ser manejado por los mecanismos de seguimiento de anomalías habituales.
Algunos implementadores de Java consideran que su producto está prácticamente completo una vez que se pasan los TCKs. Si bien es cierto que los TCKs son bastante exhaustivos, hay muchas áreas que no cubren. Estas incluyen el rendimiento, así como las características opcionales. No hay más remedio que hacer un montón de pruebas reales para hacer frente a estas deficiencias, si bien suites de prueba adicionales como JDTS pueden ayudar.
El kit de compatibilidad de tecnología para una determinada plataforma Java se denomina Java Compatibility Kit (JCK). Se trata de un amplio conjunto de pruebas utilizado por Oracle y titulares de licencias para garantizar implementaciones compatibles de la plataforma.
El código fuente del JCK para Java 6.0 ha sido publicado.[1][2] La licencia asociada no permitía, inicialmente, a los usuarios compilar o ejecutar las pruebas,[3] pero el derecho a ver el código no está asociado con problemas y los comentarios públicos sobre el código fuente están permitidos.[1] Sin embargo, desde el lanzamiento de OpenJDK, una licencia específica permite ejecutar el JCK en el contexto de OpenJDK, que es para cualquier implementación GPL que derive sustancialmente de OpenJDK.[4][5]
El OpenJDK Community TCK License Agreement v 2.0 ha sido publicado para la especificación Java SE 7 desde diciembre de 2011.[6]
La herramienta JavaTest harness es hoy el framework de pruebas unitarias más común usado para verificar el cumplimiento de la implementación. Se trata de un framework de prueba de propósito general diseñado para ejecutar pruebas de TCK. Sin embargo, algunas especificaciones también están utilizando JUnit.
Con posterioridad al lanzamiento de Sun de OpenJDK, Sun lanzó una licencia específica para permitir ejecutar el TCK en el contexto de OpenJDK para cualquier implementación GPL que derive sustancialmente de OpenJDK.[5]
Este requisito niega al proyecto Apache Harmony un derecho compatible con la Apache License para utilizar el TCK. El 9 de noviembre de 2010, la Apache Software Foundation amenazó con retirarse del Java Community Process, si no se les concedía una licencia TCK para Harmony sin restricciones adicionales.[7]
El 9 de diciembre de 2010, la Apache Software Foundation renunció a su puesto en el Comité Ejecutivo de Java SE/EE.[8]