Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2024-01-23

Present:

  • Arjan Tijms (OmniFish)
  • James Perkins (Red Hat)
  • Ivar Grimstad (Eclipse Foundation)
  • John Clingan (Red Hat)
  • Jared Anderson (IBM)
  • Kyle Aure (IBM)
  • Emily Jiang (IBM)
  • Jim Krueger (IBM)
  • Riva Philip (IBM)
  • Nathan Rauh (IBM)
  • Tom Watson (IBM)
  • Adam Yoho (IBM)
  • Scott Stark (Red Hat)
  • Nathan Erwin (Individual)
  • Scott Marlow (Red Hat)
  • Brian Stansberry (Red Hat)
  • Cesar Hernandez (Tomitribe)
  • Dmitry Kornilov (Oracle)
  • Petr Aubrecht (Payara)
  • Ed Bratt (Oracle)

Agenda and Minutes

JEA-277-mitigate-gh-platform-820

  • Baseline JDK is now JDK 17 as to Red Hat’s request
    • Email from steering committee
      • Question -> must process be followed
      • Wayne mentioned spec process doesn’t require a vote
        • Spec committee will have a vote
          • Progress review needed
        • Some concerns about virtual threads
          • Oracle
    • A compatible component impl must pass their component TCK when run under Java 17 or 21.
      • To ratify a component specification, there must exist an implementation that passes on Java 17. There must also exist an implementation that passes on 21.
      • These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
    • A compatible platform impl must pass the platform TCK when run under 17 or 21.
      • To ratify a platform specification, there must exist an implementation that passes on 17. There must also exist an implementation that passes on 21.
      • These need not be the same implementation. There can be one implementation that passes on 17 and a different one that passes on 21.
    • Discussed the above
    • Steve Millidge
      • Steve brought it up at the steering committee
        • Specification committee will discuss it
    • GlassFish community
      • Revert 8.0 branch to JDK 17
      • Anyone against it in this group? -> Nobody against it

Marlow: Unknown when EE 11 Platform TCK will be ready for Platform/profiles Spec ratification.

  • Appclient container support is being worked on now.
  • TCK Test vehicles need equivalent.
  • Most of the tests need further work for deploying and running on EE 11.
  • EE 11 specific tests will be needed
    • Enough such that there is enough testing to be determined.
  • We also will need EE 11 Platform/profiles to be implemented that can run on .
  • Make list of TCKs that still need to start migration
    • Servlet done
    • Security done
    • Faces done (with including the old tests inside the new build)
    • Persistence need to be done
    • Batch already had standalone
    • CDI already had standalone
    • Authorization needs to be done
    • WebSocket?
    • Concurrency?
    • EJB?
  • Test vehicles
    • Mostly Servlet is important
    • Jakarta Persistence uses Java SE vehicle
      • SE vehicle vs EE vehicle (what’s the exact difference, do we need some definition for that?)
      • Map to an Arquillian container
        • Appclient based test
          • Modification to standard container for Arquillian WildFly
          • Protocol adjustment
            • Appclient needs two deployment
            • Formatted log parsing as output
        • Servlet has simplest impl (maps directly) \
  • JavaTest
    • Quite complex
    • No trivial mapping from JavaTest to Junit

Rest 4.0 becomes Rest 3.2

  • Deprecation of @Context
  • Implement an alternative CDI based solution already?
    • Deprecated something needs alternative
    • May be difficult to implement
  • Resources available for REST?
    • REST was not able to make 4.0 deadline because of resource issues
    • Hard to say - RestEasy might be CI for REST 3.2
      • James working on that (for RestEasy)
  • How much time would REST 4.0 still need?
    • Realizing that in 3.1 @Context would be removed in “some” future release
    • Concern that there was no formal deprecation. Without that formal deprecation there might be problems with implementors
    • Effort not terribly much different
      • Might even be more (supporting two injection implementations)

Jakarta Data implementations

  • Join forces by Red Hat and glassfish community
    • IBM able to chip in?
    • Payara?
    • Tomitribe?
  • Chat with Gavin King
    • How much existing code could be used
    • Scott will talk with Gavin on January 24
  • Static meta model
    • Might be merged in
  • Can implementation use Jakarta Persistence APIs only?
    • Nathan: yes
      • No need to have the Eclipse EE4J implementation done within the EclipseLink project. Could be standalone project using JPA/jakarta Persistence APIs, could even bypass Jakarta Persistence entirely and just use JDBC
    • Or are Hibernate / EclipseLink specifics needed? -> No

Validation

  • Any progress?
  • Yes - Scott working on the update
    • Will produce release

M2 Dates:

CDI

  • The EE portion needs to be rehomed (profile on the platform)

Back to the top