Skip to main content

Jakarta EE Platform Call

General Date: 2019-12-10

Present:

  • Kevin Sutter (IBM)
  • Jonathan Gallimore (Tomitribe)
  • Andy McCright (IBM)
  • Scott Stark (Red Hat)
  • Steve Millidge (Payara)
  • Bill Shannon (Oracle)
  • Carlos Andres De La Rosa(Eclipse Committer)
  • Kenji Kazumura (Fujitsu)
  • Ken Finnigan (Red Hat)
  • Cesar Saavedra (Red Hat)
  • Emily Jiang (IBM)
  • David Blevins (Tomitribe)
  • Brian Stansberry (Red Hat)
  • Martin Stefanko (Red Hat)
  • Cesar Hernandez (Tomitribe)
  • Ivar Grimstad (Eclipse Foundation)
  • Dmitry Kornilov (Oracle)
  • BJ Hargrave (IBM)
  • Nathan Erwin (Eclipse Contributor)
  • Rudy De Busscher (Payara)

Agenda

[KWS] Discuss latest vote tallies…

  • Vote 1 to prune Stable APIs (majority voted +1)
  • Vote 2 to leave Activation in javax namespace (split with no clear majority)
  • Vote 3 to leave JAXB, JAX-WS, SOAP, and WS Metadata in javax namespace (split with no clear majority)
  • Vote 4 to make Enterprise Web Services and EJB 2.x API Group as optional (majority voted +1)
  • Vote 5 to prune EJB Interop (Ch 10 of EJB 3.2 Core spec) (majority voted +1)

Proposed compromise to alleviate deadlock on Votes 2 and 3:

Move Activation, JAXB, JAX-WS, SOAP, and WS Metadata to jakarta namespace Activation would be a Required spec for the Platform due to multiple dependencies JAXB, JAX-WS, SOAP, and WS Metadata would become Optional specs for the Platform

DECISION: Go with this compromise and communicate via the Release Plan.

[KWS] Java SE 8 or Java SE 11 as the minimum.

Another key decision to allow for continued development efforts. [SM] Will track as part of the Jakarta EE 9 Release Plan. Proposed wording for the Release Plan: “For inclusion in Jakarta EE 9, specification’s apis MUST be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile WON’T be required to support Java SE 8 and may certify compatibility on Java SE 11 and/or Java SE 8. ”

Updated Statement: “For inclusion in Jakarta EE 9, specification’s apis MUST be compiled at the Java SE 8 source level. However, compatible implementations of the Jakarta EE 9 Web Profile and Full Profile will be required to certify compatibility on Java SE 11. Compatible Implementations may additionally certify and support Java SE 8.”

[KWS] Specification Sizing Exercise

https://docs.google.com/spreadsheets/d/1EN5UEzxFV1Buk7yqdQAweaynWJ3UNn2BjN7blXn9vh4/edit#gid=0

Solid input via the spreadsheet, but still looking for more input… Long pole items are the Compatible Implementations that are needed for each Specification version submission.

Emphasize use of RCs, especially for APIs. Allow 2 months time between RC and ready for Final ballot.

Promote early releases for the Component features (ie. JPA, JSON-B, etc). There is no requirement to wait for the Platform release.

RCs at the Platform level is a good idea, but it will affect the final schedules.

Also need to be aware of the IDE’s plans to support Jakarta EE 9. Timelines, etc. Having RCs available early will help with their efforts as well.

When will Glassfish be available as the Platform Compatible Implementation? Steve and friends at Eclipse Glassfish will have to determine some date to shoot for.

Update Release Plan and make it publicly available by Thursday, Dec 12.

[KWS] Other minutes…

Need to update the Release Plan per the discussions today. Make Release Plan more publicly accessible. Announce on Platform dev list by Thursday, Dec 12 Discuss the Release Plan at next week’s meeting.
Hopefully, finalize Plan for submission to Steering Committee.

Didn’t get to the other items below…

[IG] Related to the two bullets above: What steps/tasks are needed for a component spec to do the namespace switch? If we can create such a list, it can be used for the component specs to estimate when they will be able to deliver.

[IG] Can we exclude optional parts of the component specifications in the platform specification(s)

Releasing the platform spec requires TCK passed by an implementation, including optional parts. Eclipse GlassFish will most likely be the only implementation of the optional parts as no vendors are likely to include them in their implementations.

Suggestion: Exclude optional parts from the platform specification Optional parts are still part of the component specifications and will be implemented and tested there

Back to the top