Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

3 Jakarta EE Platform Call

Date: 2021-02-16

Present:

  • Werner Keil (Individual)
  • Andy McCright (IBM)
  • Kevin Sutter (IBM)
  • Jean-Louis Monteiro (Tomitribe)
  • BJ Hargrave (IBM)
  • Otavio Santana (Platform.sh)
  • Emily Jiang (IBM)
  • Ed Bratt (Oracle)
  • Thomas Watson (IBM)
  • Steve Millidge (Payara)
  • Scott Marlow (Red Hat)
  • David Blevins (Tomitribe)
  • Ivar Grimstad (Eclipse Foundation)
  • Paul Nicolucci (IBM)
  • Dmitry Kornilov (Oracle)
  • Scott Stark (Red Hat)
  • Lukas Jungmann (Oracle)
  • Jesse McConnell (Webtide)

Agenda and Minutes

Jakarta EE 9.1

  • Plan endorsed by the Steering Committee and approved by the Specification Committee
  • GitHub Project Board
  • Issue created to ensure CORBA is properly specified as Optional
    • https://github.com/eclipse-ee4j/jakartaee-platform/issues/300
  • GlassFish 6.1 now running on JDK 11. Merged to master. Tests can be started soon.

[WK] True Modularity of a future Jakarta EE release, at least 9.2 or 10

  • A side story of the discussion around possible Jakarta REST Client contributions from MicroProfile was the desire to have finer-grained modularity, e.g. Jakarta REST Client and Server in two separate modules. Just like the java.se module consists of nearly 20 other modules in Java SE 15. This does not rely on Jigsaw alone, before defining more than one monolithic module (as every Jakarta EE 9 API does that applies at least an Automatic-Module-Name) the packages must be separated into (Maven) modules that are available independently. So far in Jakarta EE 9 I believe WebSocket 2.0.0 is the only Spec with a separation between Server and Client, and it also does in the MANIFEST file, both OSGi bundle and Automatic-Module-Name jakarta.websocket and jakarta.websocket.client. All the others are monolithic even if they support the JPMS.The perfect example (not yet JPMS but Maven-based) would be NoSQL, it’s Communication module contains half a dozen modules with some as fine-grained, that they could be reduced to supporting only Document, Key-Value or Column-based NoSQL systems. Other candidates might be:
    • REST (Server vs. Client similar to Websocket)
    • Persistence (a “Core” or “Lite” module allowing use in Java SE or MicroProfile as well as a with a possible synergy with NoSQL, e.g. reusing annotations)
    • CDI: The whole “CDI SE” or “CDI Lite” discussion is the perfect case for fine-grained modularity while CDI in Reality doesn’t even use JPMS yet
    • Security (could be more modular e.g. multiple authentication mechanisms, etc.)
    • JSON-P (if the “DOM” like part and Streaming API could be clearly separated)
    • Faces (much too big, should be broken down into multiple modules, unless it is not relevant enough today? ;-)
    • Mail (also quite big, see Faces)

  • Discussion during call

    • The separation of Server vs Client (ie. WebSocket, REST) is relatively straight forward
    • It gets more difficult when the API/SPI is used to load the desired implementation (ie. NoSQL). Service loader mechanism.
    • Lukas explained how this works with JAXB
    • Relationship between JPMS and OSGi. Figuring out a means of allowing these two technologies to co-exist will be key. Both Glassfish and Open Liberty are dependent on OSGi (others?).
      • WildFly is using JBoss Modules which is also important.
      • Jetty supports being consumed as JPMS and OSGi both.
      • Piranha is said to use JPMS quite a lot.
      • Helidon makes extensive use of JPMS including Jigsaw-enabled MP APIs (which seem repackaged because the official ones don’t even contain an Automatic-Module-Name yet)
      • Tomcat/TomEE has intentionally avoided OSGi and similar modularity.
      • Modules should be enabled for those who support it, but not require all servers and users to use modularity.
    • https://github.com/eclipse-ee4j/saaj-api/issues/43 - user submitted comparison of current hk2osgiresource locator vs OSGi mediator spec
    • Key Summary from this discussion: The Platform needs to define rules for the module names for the APIs. Right now, there is a suggestion for those APIs which have stepped ahead of the Platform. But, it’s not a firm requirement yet. (This was briefly discussed as part of 9.1, but it was pushed out…)
      • Some design thought is required. It’s not a boilerplate operation that applies universally to all Specifications.
      • How does a defined module naming convention apply to the uber jars that we create (ie. Platform and Web Profile)?
        • This is an issue, applications could ‘requires servlet’ but if you have it in an uber you would have to instead ‘requires jakarta.uber’, etc.
        • Should implementations that use these uber jars pass TCK based on the uber jar by not specifying a module name?
          • In other words, module names only have to be correct if a module name is included.
      • Would a TCK also support optionality e.g. have MVC but not Servlet/JSP/Faces or vice versa in the Web Profile?
      • Does this also mean certification requests can come for just the individual module (a CCR for REST Client for example)?

[Emily Jiang] How can a spec group make decisions, e.g. supermajority or over majority among comitters or something else?

  • Recommendation is to write down (and agree) on the decision making process. Then apply it. As long as it does not violate the Eclipse Development Process.

Keep the Platform Project in the Loop

  • Specification projects are encouraged to join the platform call and tell us what they are planning. Have a round-table discussion with the platform team.

Back to the top