Jakarta EE Platform Call

Date: 2022-10-18

Present:

• Jared Anderson(IBM)
• BJ Hargrave (IBM)
• Emily Jiang (IBM)
• Tom Watson (IBM)
• Ivar Grimstad (Eclipse Foundation)
• Jan Westerkamp (iJUG)
• Arjan Tijms (OmniFish)
• Scott Marlow (Red Hat)
• Scott Stark (Red Hat)
• John Clingan (Red Hat)
• Ed Bratt (Oracle)
• David Matejcek (OmniFish)

Agenda and Minutes

[Emily] JPMS required for Jakarta Activation and Jakarta Mail even though Jakarta EE clearly documented that it is optional:

• https://github.com/eclipse-ee4j/jaf/issues/98
  • Discussed the challenge. Will be accepted, and tests modified to allow for differentiating between SE and EE runs (as described by Lukas in the comments in the challenge)
• https://github.com/eclipse-ee4j/mail/issues/625
  • Same as above

Result of EE 10.1 poll

• https://twitter.com/mnriem/status/1578072631819096064?s=20&t=EX6ad0gqNeivQ6J07
  4z9MQ
• A Jakarta EE Minor Release (10.1) that drops support for Java SE 11 violates semver rules - it’s a breaking change. [Jan]
• Dropping Java SE 11 support could be done in a major release (Jakarta 11). [Jan]
• Discussion on the platform dev mailing list regarding a 10.1 release created the idea to have a mandatory (timed?) Milestone for dropping SE 11 and adding 18+ support on component specs (requiring addressing the SecurityManager removal) [Jan]
• Suggestion: When there is a PR with the proposed changes, a Jakarta EE 10.1 release can be considered if it doesn’t take away time/resources from Jakarta EE 11
• Questioning the approach with polls from individuals
  • Valid data points
  • Limited outreach
  • Specific audience
  • No context for the options (no pros or cons)
• Should be restrictive updating base Java version without specific technical requirements/requests from the specifications