Skip to main content

Jakarta EE Platform Call

Date: 2021-06-08


  • Jonathan Gallimore(Tomitribe)
  • Ivar Grimstad (Eclipse Foundation)
  • Jan Westerkamp (iJUG)
  • Kevin Sutter (IBM)
  • Dmitry Kornilov (Oracle)
  • Cesar Hernández (Tomitribe)
  • Aaron Coburn (Independent)
  • Andy McCright (IBM)
  • Ruslan Synytsky (Jelastic)
  • Tanja Obradovic (Eclipse Foundation)
  • Scott Marlow (Red Hat)
  • Lukas Jungmann (Oracle)
  • Ryan Cuprak (Jakarta EE Ambassadors)
  • Werner Keil (Committer, Jakarta EE Ambassadors)
  • Scott Kurz (IBM)
  • Steve Millidge (Payara)
  • Jesse McConnell (Webtide)
  • BJ Hargrave (IBM)
  • Emily Jiang (IBM)

Agenda and Minutes

Jakarta Config - can we use the Jakarta EE zoom account for our calls?

[Ivar] Yes, I’ll set it up for you using the EE4J PMC account and publish on the public specifications calendar

Versioning Scheme

  • Proposals:
  • Straw Poll:
  • Discussion
    • Within a major version timeframe of the Platform/profiles, all specifications will not be allowed to introduce breaking changes.
    • Should the “smaller” profiles be re-released every time a including profile is released? Or is this just busywork for the vendors?
      • Example:
        1. Core 10 with Config 1.0
        2. Web 10 with Config 1.1. Should that result in Core 10.1 with Config 1.1 as well?

        Or does this result in Web 10.1, when depending on Core 10.1 (and Web 10 has a dependency to/aligned to Spec Versions of Core 10(.0)?

    • All profiles with the same major must include the same majors for individual specializations
    • Signature tests on spec level, not profile?
      • Example: Allow for passing the profile TCK signature tests even if the product is including a higher minor version of one of the included specifications.
      • Marlow: Allow TCK signature test supersetting of core profile APIs?
  • Action: Add this conversation as preface to the versioning doc and run the poll again

EE10 Issues

  • JPMS
  • Action: Decide (by vote) to require specifications to define a
  • Update naming conventions to cover and OSGi bundles to ensure consistency (including specs with multiple modules, e.g. WebSocket and NoSQL)

Complete the topic around Java SE level

  • Decide on minimum (and maximum?) language/source level
  • Action: Run a vote for the baseline as Java SE 11 and allow Java SE 11 language features. Allow for runtime execution with any Java SE 11 or later.
  • Proposal to run the same vote with Java SE 17 to see the lay of the land

— The following topics were not covered —

TCKs (in queue for next week call)

  • Core Profile TCKs
  • Web Profile TCKs
  • Full Platform TCKs

Back to the top