Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2021-08-24

Present:

  • Jesse McConnell (Webtide)
  • Jean-Louis Monteiro (Tomitribe)
  • Ivar Grimstad (Eclipse Foundation)
  • BJ Hargrave (IBM)
  • Emily Jiang (IBM)
  • Dmitry Kornilov (Oracle)
  • Thomas Watson (IBM)
  • Ed Bratt (Oracle)
  • Jan Westerkamp (iJUG)
  • Brian Stansberry (Red Hat)
  • John Clingan (Red Hat)
  • Scott Marlow (Red Hat)
  • Lukas Jungmann (Oracle)
  • Kenji Kazumura (Fujitsu)
  • Scott Stark (Red Hat)
  • Edwin Amoakwa (Individual)
  • Nathan Erwin (Individual)
  • Vano Beridze (Individual)

Agenda and Minutes

Jakarta EE 10

  • Ballots passed
  • PR for Core this week
  • Communicate to spec teams the October 15 date for release reviews

Implications of Security Manager Marked for Deprecation in Java SE 17

  • https://www.eclipse.org/lists/jakartaee-platform-dev/msg02744.html

  • Discussion:

    • Most likely just some minor configuration changes for running some of the TCKs
    • For EE 10: Warn that next version of EE will deal with the Security Manager
    • Authorization and Authentication specs are most likely the only specs really affected - TODO: create issues for this in the spec issue trackers
    • When we want to run the EE 10 TCK on 18 and later, changes are anticipated (a service release most likely needed to solve this)
    • https://openjdk.java.net/jeps/411
      • Discussion on security-dev@openjdk.java.net

[EJ] Semantic versioning APIs to announce whether there are major or minor or no changes in the corresponding APIs.

  • Create package-info.java (see an example here) in the API packages
  • Using semantic versioning plugin bnd
  • Tooling to ensure that rules of semantic versioning are followed
    • Only in the class files to help the tooling (class retention annotations are runtime invisible)
  • Potentially an issue with the signature tests?
    • Since the annotations are added in the actual API jars, there should not be an issue with the signature tests
  • Is it ok to introduce a dependency to org.osgi.annotation.versioning.Version ?
    • What if the meaning of the annotation changes at a later stage?
    • Suggestion to create a Jakarta version of the OSGI version annotation(s) to have complete control over it?
      • Put them in the Jakarta Annotations project?
      • All other specs would then depend on Jakarta Annotations, or
      • Produce the artifact from e.g. the Platform project
      • No specification, just a well-documented “Build tooling project”
    • Or, use the org.osgi.* annotations?
      • MicroProfile use this tooling with success today
      • Marlow: TCK signature test could check specifically for org.osgi.* annotations that are not retained at runtime.
  • OSGi Semantic Versioning Whitepaper: http://docs.osgi.org/whitepaper/semantic-versioning/

Back to the top