Jakarta EE Platform Call

Date: 2021-07-13

Present:

• Kevin Sutter (IBM)
• Jan Westerkamp (iJUG)
• Ivar Grimstad (Eclipse Foundation)
• BJ Hargrave (IBM)
• Jesse McConnell (Webtide)
• Thomas Watson (IBM)
• Dmitry Kornilov (Oracle)
• Brian Stansberry (Red Hat)
• Lukas Jungmann (Oracle)
• Ed Bratt (Oracle)
• Tomas Langer (Oracle)
• Jonathan Gallimore (Tomitribe)
• John Clingan (Red Hat)
• Paul Nicolucci (IBM)
• Nathan Erwin (Individual)
• Scott Stark (Red Hat)
• Werner Keil (Individual)
• Kenji Kazumura (Fujitsu)
• Ryan Cuprak (Jakarta EE Ambassadors)
• Emily Jiang (IBM)

Agenda and Minutes

[KWS] API Versioning (follow up from previous two calls)

• Kevin sent out a note concerning the Platform and Web Profile API uber jar files:
  • https://www.eclipse.org/lists/jakartaee-platform-dev/msg02719.html
• BJ clarified some misunderstandings and misdirection in my original note
• Just want to ensure that we are all on the same page with respect to component API jars and the uber Platform jar files
  • If your component Specification is planning a Major version update for Jakarta EE 10, then the recommendation would be to recompile and distribute your APIs at the Java SE 11 source/target levels.
  • If your component Specification is planning a Minor version update for Jakarta EE 10, then the recommendation is to continue compiling and distributing your APIs at the Java 8 source/target levels. If there is a compelling reason to recompile your APIs at Java 11 target level, you are welcome to do that.
    • FYI, BJ recommends just combining these first two bullets as follows:
      • If your component Specification is planning a Major or Minor version update for Jakarta EE 10, then the recommendation would be to recompile and distribute your APIs at the Java SE 11 source/target levels.
  • If your component Specification is not planning either a Major or Minor version update for Jakarta EE 10, then just leave your APIs as-is. If you feel compelled to recompile and distribute at the Java 11 target level, then plan for a service release (x.y.z) to indicate the change.
• Minutes:

  • The recommended combining of the two bullets (Major and Minor version) is approved. We will leave this as a “recommendation” and not a “requirement” to allow component APIs to stay at a lower JDK level if the move to Java 11 is not a requirement.

  • Any building of the API jar files should use the “–release” option to the compiler (instead of the source/target java levels).
    • <maven.compiler.release>11</maven.compiler.release>
  • The Platform and Web Profile uber API jar files will all be re-built with the Java 11 target level (consistent with past practices).
    • For Jakarta EE 10, we will keep creating the uber JARs.
    • Later versions may replace these with BOMs
    • Write somewhere (pom description?) that the ubers are deprecated for removal

Versioning Scheme (hold over from last week, anything new?)

• https://docs.google.com/document/d/1ZQGEYSCN5eYtDjWOXAQqNin7iwLKHnQFEP73FDoQdbw/edit?ts=60b68f2e#
• Survey V2
  • https://survey.sogosurvey.com/r/bfeaPr
• Anything new with this topic?
• New slides from Jan:
  • https://drive.google.com/file/d/12EIE6XZ-aLPftsELod2hSXEZd0UgJ4iQ/view?usp=sharing
• Discussion:
  • A new profile could be feature based for first release?
  • “Mature” profiles time-boxed?
  • Time box?
  • Roadmap for the platform
    • Tie it to the Java SE LTS releases?
    • Effectively a three-year Major release cycle (platform+profiles)
    • Query the spec teams what they would want to do with newer SE versions?
    • Architectural overview relative to Java SE levels needed
  • (to be continued)

Inquiry about Security Manager

• Who is interested, how to approach from the Platform level. (Ed Bratt) (For reference, see JEP 411)