Jakarta EE Platform Call

Date: 2024-01-09

Present:

• James Perkins (Red Hat)
• Jared Anderson (IBM)
• Emily Jiang (IBM)
• Jim Krueger (IBM)
• Nathan Rauh (IBM)
• Tom Watson (IBM)
• Ivar Grimstad (Eclipse Foundation)
• Arjan Tijms (OmniFish)
• David Matejcek (OmniFish)
• Ed Burns (MSFT)
• Lukas Jungmann (Oracle)
• Tanja Obradovic (Eclipse Foundation)
• Scott Marlow (Red Hat)
• Petr Aubrecht (Payara)
• Nathan Erwin (Individual)
• Scott Stark (Red Hat)
• Cesar Hernández (Tomitribe)

Agenda and Minutes

Big ticket item for this sprint: EE 11 M02

• JEA-243 Release review for all Wave 1, 2, 3, 4 specs: due 2024-01-24.
  • Ed’s 2023-12-13 email to spec-project-leads
  • I realize this is overshadowed by JEA-83. See below.

JEA-83 Baseline Java SE level for EE 11

• Release co-coordinator thoughts
  • We understand these kinds of things unavoidably surface when you try to crank out releases.
  • Even so, this strikes us as an unfortunate wrinkle.
  • We thought the decision to require SE 21 was one of the most important features of EE 11. This was our understanding before agreeing to take the role of release co-coordinator.
    • Multiple parties confirmed this understanding.
    • Emily also observed few specs are using new 21 features.
  • Going back on this seems like a big deal. We do not take it lightly.
  • Note: GlassFish 8 at least will require SE 21+
  • We observe there seems to be a historical precedent of fear for whenever a new “big” or LTS release comes out. EE7, EE8, had this.
• Context review
  • Historical issue gh-platform-553
    • Scott characterized this issue as demonstrating that it takes two years for an LTS to be adopted.
    • Can we close this issue and point to 820?
  • Recently opened issue gh-platform-820
    • Red Hat is stating that they are not able to have SE 21 as a baseline for any products at this time.
• Questions to requestor and responses
  • Have you considered alternatives?
  • Why have other implementers not raised this issue?
  • The new wrinkle
    • Because every component spec has its own implementation, and Red Hat is the implementation of CDI and Validation, and other downstream implementations need that.
    • Red Hat is seeking clarity: are they allowed to deliver their implementations so that they run on 21 but are compiled on 17?
• Eclipse process expert perspective
• Other thoughts
  • Rest spec has thoughts on this.
  • Thomas Watson asserted
    • We are conflating issues.
  • Emily asserts the steering committee has mandated EE 11 specs compile against 21.
    • Thomas observed to implement this mandate, there must be some spec text that binds implementations to this mandate.
• What options can we see right now?
  • It seems we must resolve this issue right away. It blocks EE 11M02.
  • Ivar recommends we should define what we want
    • Then go to the spec committee and say this is what we want.
    • Then go to the steering committee and say we heard what you recommended, but this is what we’re doing.
    • Ed tried to identify the key sub-stakeholders on this
      • Red Hat: Scott
      • IBM
        • Thomas
        • Nathan
        • Emily
      • OmniFish: Arjan
      • Note:
        • REST has an opinion on this.
          • Emily observed the REST project, and its veto policy, makes this problematic.
        • MicroProfile has an opinion on this: compile low, support high.
  • Get the plan of record of the spec committee on the minimum SE requirement for EE 11.
    • According to Eclipse practice the Steering Committee can only recommend on the matter of the minimum SE requirement for EE 11.
    • What does the spec committee have power to do on this point?
      • They can fail reviews if they don’t agree with what is done.
      • Practically speaking this functions as a mandate.

Ratifying Compatible Implementation for EE 11

• Our release plan has
  • all the component specs completing release review in Q1CY24.
  • The Ratifying Compatible Implementation is not due to be delivered until June/July 2024.