Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartaee-tck-dev] EE versus SE TCK tests, asking why we have Java SE TCK tests in our Jakarta EE TCKs and planning for EE 11 TCK Refactoring

Hi,

From a definition point of view, what defines a Java SE TCK test versus a Jakarta EE TCK test? 

IMO, a TCK test can be:

  1. A Jakarta EE TCK test which means deployed + run with a Jakarta EE container.
  2. A Java SE TCK test which means run directly with Java SE (doesn't require a Jakarta EE container.)
  3. Both #1 (EE) + #2 (SE) ways of being run.

What other definitions come to mind when explaining the difference between Java SE versus Jakarta EE tests?

Why do we have Java SE TCK tests in our Jakarta EE TCKs?

IMO, we need the Java SE TCK tests during the respective owning Specification API Ballot process and later for validating implementations as being compatible.  For example, the Jakarta Persistence 3.1 SPEC API (using EclipseLink) initially passed the Ballot process using the Jakarta Persistence 3.1 TCK (which contains only Java SE TCK tests) and Hibernate ORM also passed the Jakarta Persistence 3.1 TCK proving that it is Persistence 3.1 compatible.  We also have specifications that do not require testing against an EE container to meet the Specification requirements (e.g. JSON Binding).  We do have the freedom to add further Jakarta EE TCK tests for validating that technologies like JSON Binding work with particular EE containers (as previously discussed, that is an itch that implementations want to scratch).

Platform TCK issue#1126 [3] is for planning the (remaining) Jakarta EE 11 Platform TCK refactoring effort.  It is a work in progress for the initial EE 11 refactoring work.  The milestone one goal is to establish a small number of refactored Jakarta EE TCK tests for each different test bucket to serve as examples that can be extended with the remaining tests and also allow interested EE 10 implementations to validate that they can pass the initial TCK tests.  The milestone two goal is to do the same for adding a small number of refactored Java SE TCK tests for the test buckets that have such SE tests that can be validated against interested implementations of the relevant specifications.  The milestone three goal is to add some `hard to refactor` tests to each test bucket (should still be using EE 10 specifications).  The milestone four goal is to complete the TCKs needed for the first wave of EE 11 Specification Ballots (with EE 11 TCK tests being added in time for that to happen).  Everything mentioned here is subject to change as we further define the Jakarta EE 11 release.

Scott

[1] https://jakarta.ee/committees/specification/tckprocess

[2] "How Tests May be Added to a TCK
      The only time tests may be added to a TCK are in a major or minor release. A service release which updates the exclude list MUST not have test additions or updates (see exception below for addressing newer Java SE versions).
"

[3] https://github.com/eclipse-ee4j/jakartaee-tck/issues/1126. 

Back to the top