Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2022-10-25

Present (please put your name down here to mark yourself as present…):

  • Jared Anderson (IBM)
  • Jim Krueger (IBM)
  • Nathan Rauh (IBM)
  • Thomas Watson (IBM)
  • Scott Marlow (Red Hat)
  • John Clingan (Red Hat)
  • Ed Bratt (Oracle)
  • Abraham Marín-Pérez (LJC)
  • Ivar Grimstad (Eclipse Foundation)
  • Werner Keil (Ambassador/Committer)
  • Nathan Erwin (Individual)
  • César Hernández (Tomitribe)
  • Brian Stansberry (Red Hat)

Agenda and Minutes

Takeaways from the Community discussions (EclipseCon + JavaOne) \

  • Predictability around releases
    • When the release is (cadence)
    • Java SE version
  • Should we jump on the release train model?
    • Eg. fixed dates for Milestones/Releases in order to make it to the platform release (that is released at the same time each year)
      • Milestone should be spec, api, and TCK (tests for new features added)
    • One year/two years? June after the Java SE LTS release?
    • Should poll about cadence length before settling on one
      • Omnifaces survey showed that 1 year is favorable
      • Need more data points
    • Should also investigate about the “amount of features” in a release is enough
    • Release process must be improved to be able to deliver predictable releases
      • Dependencies
      • Reduce number of waves
      • TCK
    • Need more contributors for the TCKs
      • Refactoring of the TCK will help remove the barrier of contributing to the
      • TCK
      • How can we get the spec projects to be represented on the monthly TCK calls?
    • Encourage spec projects to use calls/meetings more in addition to the mailing lists
  • Should we abandon semver on the Platform Level?
    • Individual specs should still use semver
    • For predictability
  • How do we handle the architecture/design/restriction incorporated in the platform specification
    • Must find a way of handle this
    • The platform is more than a container containing a list of individual specifications
    • How can we evolve specs and platform to be able to release larger chunks of functionality over several releases (e.g. like it is done for Project Loom in OpenJDK)
  • Feedback around the namespace change
    • Concern around third party libraries that are not maintained
    • Not much concern around the actual migration of their own apps

Agenda for Next Week’s monthly call

  • Make sure the spec projects show up

Back to the top