Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2025-07-29

Present:

  • Jared Anderson (IBM)
  • Kyle Aure (IBM)
  • Scott Marlow (IBM)
  • Chithra Mini (IBM)
  • Anand N K (IBM)
  • James Perkins (IBM)
  • Nathan Rauh (IBM)
  • Reshmi Vijayan (IBM)
  • Tom Watson (IBM)
  • Michael Redlich (Garden State JUG)
  • Ivar Grimstad (Eclipse Foundation)
  • Gurunandan Rao(Oracle)
  • Arjan Tijms (OmniFish)
  • Jan Westerkamp (iJUG)
  • Petr Aubrecht (Payara)

Top of mind for Jared, James

  • For those interested in AI and Java, you may want to join the upcoming Jakarta EE Futures call
    • Markus Eisele joins us on August 21 to explore the following topic:
      “From CRUD to Co‑Pilots: Will Jakarta EE Own or Miss the AI‑Native Java Stack?”
  • OSSRH update
    • Issues are still open and being worked by the help desk
  • 1 outstanding CCRs to be accepted or rejected. Opened on July 21
    • Ivar accepted all of the 20 Payara ones last week
    • If no one looks at it July 28, it will be lazily approved
  • Platform challenge issue 2394 followup next actions
    • Option 1: Based off of last week’s discussion
      • Close challenge as invalid
      • Open new TCK bug defect to fix in EE 12
    • Option 2: Or we could consider making the change and working to get an exception from the specification committee
      • Out of the box the test will fail for everyone because they should be exposing the authentication API
      • No vendor should be affected by making the change because they are required to pass the authentication TCK.
    • Today it would only affect glassfish if we made a new service release with the fix and it would not fail with this update
    • TCK Process states:

As another alternative to excluding a challenged test, it may be possible to adjust the test validation logic to “expand” the validation check. E.g. if a test expects a value “A1” for a specific variable “x”, but a challenge is raised arguing that the specification language actually allows for either values “A1” and “A2” (but no other values) to be valid values for “x”, then it could be a valid course of action to modify the challenged test to allow either “A1” OR “A2” for “x”.

Since this line of thinking might be applied to cases that aren’t quite as straightforward as this example, care should be taken when using this approach. A particular danger is that an implementation that has already demonstrated compliance before the challenge was raised might actually not pass the new, modified test.

To limit the confusion and additional work such a scenario would cause, if there is already at least one certified compatible implementation before the challenge, the new, modified TCK should be run against at least one such implementation (and ideally all of them) before the changes are published, released, and finalized.

If such a change were released, and it was later found to cause a previously-certified implementation to fail the new, modified test, then excluding the test would likely be the only option, and this would require yet another, additional service release.

  • The concern is that any TCK version is valid and vendor could use any of the versions
    • Could make it so that it works with the current way with it in the extra and not break users who don’t have it and allow for people to pass who are doing things correctly
  • TCK artifacts not published to maven for EE 11
    • Issue opened with the help desk to publish
    • They appear to be published now, but it needs to be validated by someone running with maven central instead of jakarta staging
    • Some users for running the TCK against glassfish want glassfish to publish the runner pom.xmls.
      • To publish or not to publish, that is the question #1
      • Where to publish, jakarta or glassfish namespace, that is the question #2
  • platform-tck Eclipse project folding into the platform Eclipse project and have common committer list followup
    • Discussed at the Specification Committee and it should just be a normal mailing list vote
    • Not urgent so likely will be done in September after summer
    • After vote complete will just need to file a restructure review with the EMO
    • Vote will need to be done on both the platform and platform-tck projects
  • Platform call hiatus for the next 3 weeks
    • jakartaee-platform channel in the JakartaEE Development slack workspace and jakartaee-platform-dev mailing list can be used for any discussions during those weeks
    • ACTION: Send mail to the mailing list about the break from calls for the next 3 weeks - done on July 31
    • ACTION: Does the calendar need to be updated as well? - done
      • Ivar: removed the next three meetings from the calendar. Next call will be Aug 26, 2025

Jakarta EE 12

  • Want to run Glassfish 8 against EE 12 TCK early versions as we go and having CI jobs up and running throughout the EE 12 development process
    • Glassfish 9 branch will be started soon
    • Part of the TCK process is to re-enable excluded tests which will cause new failures again and need to be worked on to figure out what changed in the tests with the refactoring and fixing the tests
    • Issues are open for the problems that resulted in exclusions. Those can be worked during this time while there isn’t a lot of new platform TCK work to do in this early stage of EE 12 specification development
    • Other option is permanently remove tests if the same function is tested in another test scenario
  • Jakarta HTTP
    • Arjan still hasn’t had time to work on it
    • May not be part of EE 12 if someone doesn’t pick up this work

Back to the top