Jakarta EE Platform Call

Date: 2022-03-22

Present:

• Jesse McConnell (Webtide)
• Emily Jiang (IBM)
• Thomas Watson (IBM)
• Jim Krueger (IBM)
• James Perkins (Red Hat)
• Dmitry Kornilov (Oracle)
• Scott Marlow (Red Hat)
• Ivar Grimstad (Eclipse Foundation)
• Lukas Jungmann (Oracle)
• Ed Bratt (Oracle)
• Cesar Hernandez (Tomitribe)
• BJ Hargrave (IBM)
• Scott Kurz (IBM)

Agenda and Minutes

Jakarta EE 10 Status (standing agenda item)

• CDI to restart their release review
  • Need to resolve a PR on Weld (compatible implementation) before resuming
  • Does not affect the Interceptors ballot
• REST to restart their release review after TCK challenge \

Jakarta EE Core Profile Artifact

• https://github.com/eclipse-ee4j/jakartaee-api/pull/118
• https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10CoreProfileRelasePlan
• PR looks good to merge, please comment! Otherwise it will be merged and staged pretty soon \

Java 18 (General Availability today) followup

• OpenLiberty and WildFly have run with Java 17/18 and have results
  • jakartaee-tck/issues/743 is tracking issue for analyzing Security Manager use in TCK.
• Batch TCK does not support Java 18+ today.
  • Should Batch TCK do what Platform TCK does?

• RH to be more active in the JEP-411 discussions in OpenJDK

• (Option 1) Is there a general opinion that it is ok to make tests requiring Security Manager optional for Java SE 18+?
  • These tests should be listed
  • No, as discussed we should wait until we know exactly what is in Java SE 21 before saying 18+ will work.
• (Option 2) Another option is to limit to Java SE 17 for EE 10, and do a EE 11 release to allow for Java SE 21 (Sept 2023)?
  • E.g. EE 11 would raise API source level to 17 and allow TCK to run on 17 and 21 (no refs to Security Manager in TCKs)
  • All tests must pass. If an implementation is able to pass the tests on higher SE versions, that’s fine. \
• Seems that this group leans toward Option 2