[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [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
|
Title: Re: [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
On 10/26/22 9:59 AM, Tracy Burroughs
wrote:
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?
In the past the answer has been yes as the Persistence SPEC
ballot was done early (e.g. with only a Persistence Provider
implementation). Also in the past, the Jakarta EE Container
testing with Persistence was covered during the last Spec Ballot
wave. That was in the past though, we should be looking forward
to what we can improve for EE 11+.
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?
Some possible options for improving process around specifications
that have both Java SE + Jakarta EE TCK tests:
1. Fold all of the Specification API ballots into a series of
public milestone releases that all implementations can use. Such
that the Core Profile/Web Profile/Full Platform Specification
Ballot will include releasing all of the standalone Spec APIs.
2. Or refactor the various standalone Spec APIs to improve our
layering (not sure if this helps with the Java SE vs Jakarta EE
TCK test concern but we could discuss further if there is
interest).
3. Or create separate Java SE + Jakarta EE TCKs such that the
Java SE TCK can be complete very early (for the early Spec Ballot
waves) and the EE TCK complete very late (for the last Spec Ballot
wave).
4. Or update TCK Process to allow test changes to be made in a
service release as mentioned in
https://github.com/jakartaee/specification-committee/issues/63
(this is a work in progress).
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.
Historically, in the case of Persistence, the early Persistence
Provider implementations are not required to test with an EE
implementation as that level of testing (and the bug fixing that
goes with it) is covered later during EE Platform level testing.
Persistence is a special case also as it doesn't really have to be
balloted during the first Spec API Ballot wave, it could be later.
Scott
Tracy Burroughs
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.
|
This
Message Is From an External Sender
|
|
This
message came from outside your
organization.
|
|
|
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.
-
A Java SE TCK test which
means run directly with Java SE (doesn't require a Jakarta
EE container.)
-
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.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
