Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Platform Call

Date: 2023-09-05

Present:

  • Jared Anderson (IBM)
  • Emily Jiang (IBM)
  • Tom Watson (IBM)
  • Lenny Primak (Individual)
  • Jan Westerkamp (iJUG)
  • Ivar Grimstad (Eclipse Foundation)
  • Petr Aubrecht (Payara)
  • Arjan Tijms (OmniFish)
  • Dmitry Kornilov (Oracle)
  • Tanja Obradovic (Eclipse Foundation)
  • Lukas Jungmann (Oracle)

Agenda and Minutes

Ed Burns taking Discretionary Time Off this week, 2023-09-05.

  • Arjan running meeting

Optional dependencies on CDI, like in Jakarta Transactions, currently not optional in JPMS module-info.java

  • https://github.com/jakartaee/transactions/issues/214
  • (Transactions refers to old CDI API version)
  • Potentially put extension in separate API jar / module
    • Ship has sailed for Transactions -> @Transactional is already in same package
  • API self contained in Java SE environment
    • Optional dependencies marked static
    • For platform spec API not static
  • The jakarta.jakartaee-api.jar does NOT have module-info.java
    • The next release (EE 11) will not be a jar with classes
    • It will only be a pom, transitively depending on individual spec jars
    • Do we need to strictly (more strictly?) specify that the CDI extensions are optional in the Jakarta Transaction specification
    • What is the difference between a static dependency and a “regular” dependency in module-info.java? Why not make everything static?
    • See https://jakarta.ee/specifications/transactions/2.0/jakarta-transactions-spec-2.0#transactional-annotation
    • Alternative options
      • CDI is more and more central - prepare to pull it on. Don’t try to be independent of CDI
      • An implementation / spec that’s completely independent of CDI, doesn’t need it, doesn’t use it. But there’s an extra feature / extension providing extra options within a CDI environment.
    • Servlet is another example
      • Tomcat used standalone and with Spring
        • Dependency on CDI therefore pretty much must be optional
    • For most other specs CDI should (must) be mandatory
    • Mojarra uses CDI internally as well, Jersey used HK2 internally
      • Extra complications when used with other DI environments

JPMS - questions for them being required or not

  • What guarantees, if any?
  • Should we add it more strictly into the spec?
  • Require module-info.java to be present
    • We don’t test them
    • If vendor wants to produce their own artefacts they can
    • Jakarta EE specification project API artefacts are there for convenience - not normative
    • Would users (consumers) have issues with portability if module-info.java is missing or different (non-portable)
    • Do users ever use JPMS? Do client modularized applications even exist?
    • Binary compatibility might not be influenced here - compilation matters, and then they must compile against an API artefact with JPMS, but the produced war should run across implementations from different vendors

Reproducible builds

  • API

Can someone share their analysis of how the spec committee is responding to our proposed plan? I am a guest on the spec committee, so my analysis is only observational.

Concerns from Red Hat about Jakarta Data itself?

  • https://twitter.com/1ovthafew/status/1696503099601383739
  • Jan TCK dependency to Jakarta NoSQL need to be handled
  • Lenny observes the need to explain to our users the difference between the use cases of Data and Persistence.
    • Where?
      • Tutorial?
      • Blog post?
      • Vendor documentation?
      • YouTube videos?
      • Conference sessions?
    • What
      • Terminology
    • Who
      • Marketing group?
  • Scott Stark stated that Red Hat will increase their level of engagement.
    • To follow
      • GitHub issues for data project
      • Data-dev list
    • Ed to look to Scott Stark to poll for status regarding these

Next steps to get “Make Full / Web profile play nice with MicroProfile maven dependencies” / “Normalize Web Profile Dependencies” PR https://github.com/jakartaee/jakartaee-api/pull/139

  • Jan merged it now
  • Woo!

Maintenance lead role jea-151: define a way forward

  • Ed and Jan to meet 1:1 to define the job to be done.

CDI and CDI EE

  • Breaking up spec/TCK to remove circular dependencies · Issue #687 · jakartaee/cdi (github.com)
  • There will be two ballots for this.
    • Scott will be putting out a new ballot for CDI EE
      • This is either a new spec or a restructuring review.
    • Scott will continue to work with Ivar on this.
  • Make steps to move CDI some integration concerns from CDI itself to the specs that own artefacts? Platform directed (as it’s a cross-spec thing)?
    • Take this as an opportunity to do the right thing for each possible instance of integration challenges. For example Jakarta Servlet and CDI injectability of HttpServletRequest. There is some notion of this being a “built in bean” as defined in CDI.
    • Arjan articulated some history
      • Before: we were not sure if
        • “All the other specs should know about CDI”
        • “CDI should know about all the other specs”
      • Now: we are sure
  • Any steps for a CDI lite API?
    • See above. This is addressed as CDI EE

Maintenance

Back to the top