Jakarta EE Platform Call

Date: 2020-07-14

Present (please put your name down here to mark yourself as present…):

• Emily Jiang (IBM)
• Steve Millidge (Payara)
• Kevin Sutter (IBM)
• BJ Hargrave (IBM)
• Ivar Grimstad (Eclipse Foundation)
• Jonathan Gallimore (Tomitribe)
• Dmitry Kornilov (Oracle)
• Paul Nicolucci (IBM)
• Nitin Dahyabhai (WTP)
• Scott Marlow (Red Hat)
• Scott Stark (Red Hat)
• Kenji Kazumura (Fujitsu)
• Andy McCright (IBM)
• Ed Bratt (Oracle)
• Werner Keil (Individual)
• Cesar Hernandez (Tomitribe)
• Jason Mehrens (Individual)

Agenda

[KWS] Proposal to prioritize Java SE 8 certification over Java SE 11

• https://www.eclipse.org/lists/jakartaee-platform-dev/msg01987.html
• https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00600.html
• If accepted by Steering Committee, then the Jakarta EE 9 Release Plan would be updated accordingly
• Minutes:
  • 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.

[KWS] Final Specifications Progress

• https://github.com/orgs/eclipse-ee4j/projects/17
• https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9#jakarta-ee-9-schedule
• Looking for the following Specifications to be ready for final ballot by next Tuesday, July 20…
  • https://github.com/orgs/eclipse-ee4j/projects/17?card_filter_query=label%3Awave%3A1
  • Interceptors
  • Expression Language - note from Scott Marlow, hit (unknown cause) issue with EL 4.0.0-RC2 (RC1 works) borking GlassFish TCK testing. More EL api changes may be needed.
  • SOAP Attachments
  • JSON-P
  • Servlet (currently failing standalone TCK and needs a new milestone release)
  • Web Socket
  • Activation (in progress)
  • Bean Validation (in progress)
  • Dependency Injection (in progress)
• The next batch will be right on its heals (July 27)…
  • https://github.com/orgs/eclipse-ee4j/projects/17?card_filter_query=label%3Awave%3A2
• Minutes:
  • Dmitry pointed out that Annotations and JWS should be moved to wave 1. Done (KWS)
  • We need a staging release of the final version published to https://jakarta.oss.sonatype.org/
  • The specification committee has appointed mentors to all specifications. Kevin is going to assign the mentors to the PRs
  • Discussed setting up a shared document with vacation plans for key personnel, but dismissed due to privacy concerns.

[Emily] Optional features - must one compatible implementation support all of them?

• https://www.eclipse.org/lists/jakartaee-platform-dev/msg01985.html
• 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.
• Minutes:
  • 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

                         <Automatic-Module-Name>
                            java.transaction
                          </Automatic-Module-Name>
  

• 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.