[jakarta.ee-spec.committee] Review for Approval: Jakarta EE Specificatio

[Andrew Pielage <andrew.pielage@xxxxxxxxxxx>]

The minutes for the August 20th Specification Committee call are below and are also available here. Please review and be ready for approval during our call on September 3rd.

Jakarta EE Spec Committee - August 20th, 2025

Attendees (present in bold):

Kenji Kazumura - Fujitsu

Emily Jiang - IBM - Tom Watson

Ed Bratt - Oracle - Dmitry Kornilov

Andrew Pielage (chair)  - Payara - Petr Aubrecht

David Blevins - Tomitribe - Jean-Louis Monteiro, Cesar Hernandez

Ivar Grimstad - PMC Representative

Marcelo Ancelmo - Participant Member -  Abraham Marin-Perez

Werner Keil - Committer Member

Jun Qian - Primeton Information Technologies - Enterprise Member

Zhai Luchao -  Shandong Cvicse Middleware Co. - Enterprise Member

Guest - Jakarta EE 12 co-release coordinators: Jared Anderson, James Perkins

 

Eclipse Foundation: Tanja Obradovic

Past business / action items:

• Approval is requested for the minutes from the August 6th, 2025 meeting as drafted - Quorum not reached

Agenda:

• EE 11 Update [Ed Burns]
• Retrospective update
• [Carry over from July 9th]: 
• Retrospective was done on the platform call (issue link, document link)
• Need to review retro link to figure out what may need action by spec committee vs others
• Any remaining business on EE11
• Jakarta EE 12 Update [Jared Anderson]
• Platform calls on break until the 26th August
• Jakarta EE Namespace
• [Carry over from July 23rd, August 6th]:
• Discuss straw poll results/voting and actions
• Do we run the straw poll again with only options 1 and 4?
• Do we want to simply accept MicroProfile retaining its namespace for now, and finish defining the rules later?
• What would be the impact if we accepted MicroProfile now, but then made a rule stating all specifications must use jakarta.*?
• There are existing process controls to prevent them doing further releases until they comply
• The Platform team can rule that all specifications contained in the specification itself must use the jakarta.* namespace, and “kick out” or freeze any specifications which don’t comply. These specifications would then just exist as “standalone” Jakarta specifications
• This would be balloted by the Platform committers, not us.
• With only this rule in place, this would not prevent the component specification from continuing to do releases - the new versions would just not be included in the Platform specification.
• If we make a general JESP (or similar) change to the overall Jakarta working group, this would apply to all Jakarta component specifications and we could then vote -1 (against) any new versions of the specifications as not meeting the requirements for a release.
• Should we just have “guidance” of expectations rather than a strict ruling?
• Does there need to be a straw poll in the Platform?
• The JESP currently mandates javax to jakarta, anything else is up to the component/umbrella specifications
• What actually are the expectations?
• If we left the rule as is, then the individual specifications (Config, Fault Tolerance, etc.) could come across with their existing namespace, and continue to do releases as any other Jakarta specification.
• Jakarta Platform currently consumes Web Profile, which in turn consumes Core Profile
• Currently there cannot be something in one of the consumed specifications that is not a part of the consuming specification e.g. there can’t be a specification in Core Profile which isn’t a part of Web Profile or Platform
• To be pulled into one of these umbrella specifications, the individual component specification will need to comply with any rules those specifications define (namespace or otherwise).
• If Web Profile doesn’t want to include all of the MicroProfile component specifications, a new Jakarta Micro Profile umbrella specification could potentially be created to exist as a separate umbrella which would not need to be consumed by the Web Profile or Platform.
• To decide when we have quorum: 
• Do we want to assign an investigative writeup of pros vs cons of defining it as a Jakarta working group wide rule (e.g. JESP rule) vs. delegating any namespace decision to the Platform team?
• Continue discussion next call
• Ongoing tracking spreadsheet of specifications progressing through the JESP specification version lifecycle
• Not discussed
• Issue #55 - TCK Archive Format [Ed Bratt]
• Not discussed
• Check in on Ed Bratt’s PR: pending
• Issue #83 - Clean up and clarify how to list TCK service releases on spec pages [Andrew Pielage]
• Not discussed
• Check on progress of pull requests
• Issue #74 - TCK challenge automatic acceptance - [Ed Bratt]
• Not discussed
• Check on progress of specifications
• Issue #58 - TCK challenge templates [Andrew Pielage]
• Not discussed
• Check on progress of pull requests
• Issue #82 - Consistent approach for TCK challenge exclusions [Ed Bratt]
• Not discussed
• Carry over from February 19th: TCK Process should be updated with something akin to Scott Starks suggestion.
• Review other open issues:
• Not discussed
• Determine which issues to label as “enhancement” and add to our board
• Close issues which are no longer relevant or have been dealt with

--

Andrew Pielage
Senior Software Engineer

		payara.fish
		+448005385490

Try our fully managed cloud native application runtime. 15 day trial available. Payara.cloud

Payara Services Ltd, Registered office: Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ, United Kingdom
Registered in England and Wales: 09998946 | VAT: GB 193854467

Payara is a proud recipient of the prestigious Queen's Award for Enterprise: International Trade 2021