Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2025-10-14

Present:

  • Jared Anderson (IBM)
  • Kyle Aure (IBM)
  • John Clingan (IBM)
  • Scott Marlow (IBM)
  • Chithra Mini (IBM)
  • James Perkins (IBM)
  • Nathan Rauh (IBM)
  • Brian Stansberry (IBM)
  • Reshmi Vijayan (IBM)
  • Michael Redlich (Garden State JUG)
  • Dmitry Kornilov (Oracle)
  • Otavio
  • César Hernández (Tomitribe)
  • Bernd Müller (Ostfalia)
  • Petr Aubrecht (Payara)

Top of mind for Jared, James

  • Ballot for including Jakarta Query into the Platform and Web Profile completed yesterday. Ballot was passed with all positive votes.
  • OSSRH update
  • EMO opened this issue to track the restructure of the Platform and TCK Eclipse projects
  • New CCRs created last week and this week for EE 9.x
  • Next Jakarta Futures call
    • Our next scheduled Jakarta EE Future Directions meeting is scheduled for Thursday, October 16th, 2025 at 12:00 noon EST.
    • Mary Grygleski will present some interesting ideas on Jakarta EE and AI.
  • Program plan email from Ed Bratt

Jakarta EE 12

  • https://github.com/orgs/jakartaee/projects/20/views/1 dashboard populated with M1 issues for each spec with an update for EE 12.
    • Aiming for October 15 for completion for M1
    • Main concern is publishing
    • 7 component specs have published M1 APIs and/or M1 specification documents / javadoc
    • CDI has an Alpha1 from March
    • Seeing things in repo1.maven.org, but not repo.maven.apache.org. Is that expected?
      • Concurrency is missing in apache.org. Data doesn’t have this problem. WEIRD!!!
      • It is in the metadata and can be accessed directly, but just isn’t in the index of the artifact URL
  • Jakarta and MicroProfile Update
    • Emily sent a proposal to the mailing list about MP joining Jakarta EE
    • MP Steering committee call today
    • Last few weeks there has been low attendance at the MP meetings due to this topic and travel due to fall conference season
  • Jakarta Connectors: removing the @SecurityPermission annotation and ra.xml deployment descriptor (Kyle Aure)
    • Can this be removed, or does it need to be deprecated first?
    • Does removing require updating the version to 3.0 instead of 2.2 which is what the current release plan version is?
      • An annotation not being there isn’t a breaking change. Applications do not fail with class loading errors due to an annotation not being found.
      • Security 4.0 removed IdentityStorePermission without deprecating first
      • Authentication 3.1 removed constants from jakarta.security.auth.message.config.AuthConfigFactory that were deprecated in 3.0
    • I think it can be removed without deprecating first. It only affects compiling of the code, but not runtime unless they are calling SecurityPermission.XXX for some weird reason.
    • Is it better to break them or for them to get the warning of deprecated use? For security reasons maybe it is better to break them?
    • Since they could get compile errors, it would be better to update the version number to be a major version update.
    • Jakarta EE 11 already removed SecurityManager support
    • Conclusion: Can remove without deprecating, but should update the version numbering to 3.0 instead of 2.2.
  • Jakarta Connectors: Marlow: https://github.com/jakartaee/connectors/issues/168 - `Implication of read-only transactions on Jakarta Connectors specification`?
    • Also see Transactions 2.1 tracking issue https://github.com/jakartaee/transactions/issues/220 for read only transactions hint.
    • Does it also impact Jakarta Messaging?
      • It can use connectors and can do transactions
      • With read only you wouldn’t consume a message?
    • Enterprise Beans and Web containers obviously have transaction usage.
      • There should be tests created for those technologies
    • JDBC can use transactions
      • JDBC testing is covered by the platform / web profile TCK and would need to have specific tests for this function
    • Persistence is an obvious use of transactions that needs to have appropriate specification and testing updates
    • New transaction test added to the platform TCK that is pending
      • If a DB doesn’t support read only transactions the test is expected to pass still
    • Transaction and platform community may need to open issues against other specifications to add specification language and test changes for the implications of read only transactions
      • JDBC set read only on the connections needs to be discussed in the specification language
      • Connectors may need a set read only mechanism
    • Transaction issue is currently closed. Will be re-opened to address these other concerns across the platform ecosystem
  • TCK call is tomorrow. Please attend. Current schedule is 1st and 3rd Wednesday

Back to the top