[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jakartaee-platform-dev] Compatibility Certification Requirements for EE 9.1
|
In the Jakarta EE Specification committee, we had a lengthy
discussion about compatibility certification requirements for
Jakarta EE 9.1. This e-mail is my attempt to describe the problem
and also describe a solution.
Jakarta EE 9.1 has explicitly set a requirement that it will
support JDK 11. Jakarta EE 9, explicitly required JDK 8. The 9.1
platform specification now implies that all component
specifications from 9.0 are also valid for JDK 11. The thought
experiment I offered in the Specification Team meeting today was:
"If a user were interested in running the stand-alone Servlet TCK,
should they expect that TCK would work correctly on JDK 11?" I
think the answer to this question is "yes." If there is agreement
on this, expanding on that a bit -- one might then ask -- what
evidence is provided to demonstrate that the JDK 11 requirement
for each and every TCK is verified?
It is my position that each specification must have a
compatibility certification request (CCR) that verifies their TCK
runs correctly on JDK 11. (The good news, is we already have
almost everything we need.)
During this project, we have been tracking the TCK updates and
result status using the Jakarta EE Platform TCK (AKA CTS).
Stand-alone TCKs that are created by the Jakarta EE Platform TCK
project have also been rebuilt -- changed or not. These are
planned to be released as service releases. However, the SHA Sum
values we referenced for their previous Jakarta EE 9 release CCR
and the component specification pages will need to be updated and
we cannot just replace the EE 9 entry since that was, and still
would be an accurate TCK for Jakarta EE 9.
When Compatibility Certification Requests for Jakarta EE 9 were
created, published, and approved, these were all verified against
JDK 8.
If we proceed only with Platform compatible certification
requests, we will be providing evidence that an EE Platform
(likely multiple platforms, yay!) pass the Jakarta EE Platform TCK
and that the platform implementation is compatible with the
component specifications that the Platform Specification indicates
it can be used to certify as compatible. However this does not
demonstrate that the component specifications have verified their
stand-alone TCKs.
Some background about the Platform TCK project: The stand-alone
TCKs from the Jakarta EE Platform project are produced from common
TCK test code that is used to create the Platform TCK and all the
respective stand-alone TCKs. As part of the production process, to
verify the stand-alone TCKs, GlassFish is used as a "known
archive" of compatible implementations -- This is true only for
the specific specifications that have stand-alone TCKs and are
produced from this project. That list of specifications is
identified in [1] below. There are 19 specifications in this list.
The stand-alone TCK verification uses compatible implementation
from the component project as a quality measure before release. It
has traditionally been up to the project teams to decide if they
want to use the test results from the Platform TCK project, or if
they want to provide separate implementation results. For example,
Enterprise Security and the Soteria implementation have generally
opted to take the results produced by the Platform TCK project.
Eclipse Jersey and Jakarta REST generally opt to use their own
test results even though the Jakarta EE Platform TCK project has
these data available. In all these cases, the TCK can be verified
and documented -- what was tested -- in what operating
environment, and with what JDK in a CCR.
The component specifications are not changing. However, the TCKs
produced by the Platform TCK project have been rebuilt. These new
TCKs are being tested compatible against compatible
implementations contained in Eclipse GlassFish, with JDK 11.
Without a new CCR, even the specifications with TCKs that are not
changing will have produced no evidence that their TCK runs
correctly with JDK 11. In cases where the previously used
compatible implementation will pass on both JDKs -- great -- all
that is needed is a verification re-run, and an update that
denotes that fact.
If the previous statements are found to be accurate and agreed
upon, the following can be documented with the tests that are
already being run, today:
All specifications in lists [1] and [4] below can verify that
their TCKs pass with JDK 11, using the results we are currently
generating out of the Platform TCK project (25 specifications).
Specification stand-alone TCKs from list [2] are explicitly
included with each platform CCR (that brings us to 29
specifications). These results are also being produced in the
Jenkins workspace for the Jakarta EE TCK project. The remainder,
projects from list [3], would need to have their current
stand-alone TCK and implementation status validated. I'm pretty
confident they are in good shape and I don't anticipate much delay
getting these data.
A recent TCK test run Blue Ocean "graph" is available here
(recent results with Eclipse GF 6.1, JDK 11, Full profile). A
recent stand-alone TCK test run, Blue Ocean "graph" is available here
(recent results of all stand-alone TCKs that are produced from the
Jakarta EE TCK Project, run on JDK 11).
I am willing to do most of the documentation work for all of this
(see [5] below for a breakdown) and I think there is sufficient
time to accomplish this before the Platform and Web Profile
specifications are taken to ballot, presuming that the TCK results
hold at their current level -- if any component projects want to
produce their own CCR for JDK 11, they are welcome to do that. If
we can get Spec. teams to proactively approve the CCRs, we can
probably have them all completed before the platform ballot is
started (but that's not certain). I am confident most, if not all,
of the CCRs can be submitted before the platform ballot starts.
As I said in the Spec. meeting today -- I thought this was the
plan all along but -- even if that wasn't well understood, I
believe this is an evidence requirement that we must adhere to. I
think this provides the evidence trail that we want to maintain
for Jakarta EE and with luck, meeting this requirement won't
impact any project schedule targets. In most, if not all cases,
we're already doing the work. It's just a matter of doing the
paper work to document that fact. I'm willing to do nearly all
that "paperwork."
-- Ed
[1] -- Stand-alone specification TCKs that are produced by
Jakarta EE Platform TCK project:
- Annotations
- Concurrency
- Connector
- _expression_ Language
- Authorization
- Authentication
- Rest
- Messaging
- Persistence
- Faces
- JSONB
- JSONP
- Server Pages
- Tag Library
- Transactions
- SOAP with Attachments
- Enterprise Security
- Servlet
- WebSocket
[2] Specifications that are explicitly called out by Platform
specification and must be included in a platform compatibility
certification request:
- DI
- CDI
- Bean Validation
- XML Binding (required for JDK 11 and higher)
[3] Specifications with stand-alone TCKs that will validate
component compatibility for a given platform, but are not produced
by the Platform TCK project:
- Mail
- Activation
- Batch
- Compatibility
[4] Specifications that are certified compatible only with the
Platform TCK (i.e. do not have stand-alone TCKs or are the
platform):
- Platform
- Web Profile
- Enterprise Beans
- Enterprise Web Services
- Managed Beans
- Web Services Metadata
[5] Work needed to validate:
- Collect the current TCK result data (using the data generated
in Jakarta EE TCK Project)
- Generate TCK result pages (under the Eclipse GlassFish
web-site)
- File the necessary CCRs for each specification
- File PR(s) to add these TCK details to the Specification pages
(Add the link to the 9.1 TCK; as needed, add the compatible
implementation details.)
- File the component certification e-mail with the EMO.