If accepted by Steering Committee, then the Jakarta EE 9 Release Plan would be updated accordingly
Dmitry Kornilov proposed to have follow on SE 11 compatible implementation after EE 9 release
We need this follow on support for Java SE 11 in a timely manner, like before EOY 2020. Not only would this demonstrate that Java SE 11 is important, but it would also demonstrate a faster cadence for Jakarta EE releases.
TCK(s) updates may be needed – signature tests are one area to verify.
Versioning in order to support Java SE 11 is a future discussion item. For example, whether we need a Jakarta EE 9.1, or if a simple update to the TCK (ie. 9.0.x) is sufficient.
Currently: A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not extend the API (no supersetting), and must fulfill all the requirements of the corresponding TCK. A Specification Version must identify at least one Compatible Implementation under an Open Source License that implements all optional elements of the Specification and fulfills the requirements of all elements (including optional elements) of the TCK.
To be: How about?
A Compatible Implementation must fully implement all non-optional elements of a Specification Version, must not extend the API (no supersetting), and must fulfill all the requirements of the corresponding TCK. A Specification Version may implement optional elements of the Specification and fulfills the requirements of all elements (including optional elements) of the TCK.
Today, all optional elements must be implemented by a single compatible implementation
This issue must be addressed after Jakarta EE 9
Jakarta EE 9 will go forward with the current definition
Proposal: Modify the wording to allow for multiple CIs to be specified for a Specification Version (required and optional features).
Need to differentiate between “preview” or standalone specifications (which are optional to the Platform) and declaring specifications or features of the Platform as Optional (on the way to Removal).
Didn’t come to a final conclusion for all scenarios yet. This is a good discussion to start, but as stated, the resolution is not required until Jakarta EE 10.
[Werner] Module definitions
Several APIs defined modules either via module-info or Automatic-Module-Name in the META-INF as of Jakarta EE 8. The JSON specs did and JTA 1.3.3 already had
Which has not been changed to “jakarta.transaction” in the Jakarta EE 9 Milestone.
Since it was there in Jakarta EE 8 already, I would certainly not remove them, but IMO the module namespace where a module had already been declared should now be “jakarta.*”, doesn’t it?
We are not defining new module names for Jakarta EE 9. If module definitions existed in Java EE 8 and they have moved forward to Jakarta EE 8 and 9, then we should ensure that these automatic module names use the proper jakarta. module prefix (just like the new package names).
Since we are proposing to make Java SE 8 as the priority runtime, then none of this module definition material will affect our immediate needs. But, once we try to support Java SE 11, then we should ensure that we are consistent with our module definitions (for those that currently exist).
True module definition is an exercise left for Jakarta EE 10.
Werner will take the action to analyze the current situation with module names. Look to see if there are additional components beyond JTA that have an automatic module name specified with the java. prefix that should be updated to jakarta.