Re: [jakartaee-platform-dev] EE versus SE TCK tests, asking why we have

[Tracy Burroughs <tkb@xxxxxxxxxx>]

Is a Java SE TCK really adequate to determine that an implementation is compatible?

For example, the Jakarta Persistence 3.1 specification contains requirements for when running in a Jakarta EE Container, but the Java SE TCK would not confirm an implementation could support these requirements.  Specifically, when a Jakarta Persistence implementation is used in a Jakarta EE Container it must support injection (@PersistenceUnit and @PersistenceContext) and must support extended persistence contexts for stateful beans, and none of this could be covered by a Java SE TCK. Those are just some of the Jakarta EE Container integration requirements.

If an implementation of the Jakarta Persistence API passes the Java SE TCK, but does not support integration with a Jakarta EE Container, then is it really compatible?

Perhaps a Java SE TCK would be adequate to take a specification to ballot?  However, what happens when a new version of the specification is released, and then we discover that some new Jakarta EE requirement in the new spec version isn’t feasible because none of the implementations that passed the Java SE TCK had tested the new Jakarta EE requirements?

For those specifications that do not contain extra Jakarta EE Container integration requirements, then a Java SE TCK works well to determine compatible implementations.  And it also seems like a good idea to support running that same (or similar) TCK in a Jakarta EE Container environment, to ensure the implementation continues to be compatible.  However, for those specifications that contain specific Jakarta EE Container integration requirements, relying on a Java SE TCK to determine compatibility seems questionable.

Tracy Burroughs 

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Scott Marlow
Sent: Wednesday, October 26, 2022 7:58 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [jakartaee-platform-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: A Jakarta EE TCK test which means deployed + run with a Jakarta EE container. ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

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.