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

[Andrew Pielage <andrew.pielage@xxxxxxxxxxx>]

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

Jakarta EE Spec Committee - July 23rd, 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 July 9th, 2025 meeting as drafted - Approved

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
• Not all TCK JARs are available in Maven Central yet
• Scott Marlow tackling this - missing JARs will be manually uploaded to the new portal
• Jakarta EE 12 Update [Jared Anderson]
• Project board: https://github.com/orgs/jakartaee/projects/17/views/1
• Platform and Platform TCK to be potentially combined - discussions and requirements in review
• The projects would need to agree on this first
• Ballot required?
• Previously 7-day ballots were run
• If they agree, previous cases were done via an EMO Restructuring Review
• Does a Restructuring Review require anything from the Specification Committee? Needs review
• Scope statement of the Platform project may need to be updated to cover the TCK
• Why were they separate?
• Somewhat a historical artefact - TCK was closed source and had different contribution processes vs. the Platform project
• Now that the TCKs are no longer closed source and they have been refactored and split up, the argument could be made we no longer need this separation
• Would be more consistent with other projects
• There would end up being a union of the Platform and Platform-TCK leads & committers
• Only the Eclipse project would change - separate mailing lists, GitHub repositories, etc. would be retained
• Any on call opposed?
• No
• Discussions to continue and we will review the state of things on the next call
• Milestone 1 due in September
• October/November - Java 25 support
• Jakarta EE Namespace
• Discuss straw poll results/voting
• Options
• Option 1 - Require existing specification projects to move all of their API package namespaces to jakarta when they move to the Jakarta specification project
• Option 2 - Allow existing specification projects to retain their own existing package namespaces when they move to the Jakarta specification project
• Alternative 1 - Prefer existing specification projects move their API package namespaces to jakarta but allow exceptions to be approved on case by case basis
• Alternative 2 - Allow existing specification projects to retain their own existing package namespaces when they move but require them to change when they make a major version change to their APIs

• 	Option 1	Option 2	Alternative 1	Alternative 2
  Ed Burns (Microsoft) Guest		1
  David Blevens (Tomitribe)	1		2
  Alasdair Nottingham (IBM)		1
  Emily Jiang (IBM)		1
  Ivar Grimstad (PMC)	1
  Werner Keil (Committer Member)	1		2
  Andrew Pielage (Payara)			2	1
  Abraham Marin-Perez (Participant Member)				1
  Kenji Kazumura (Fujitsu)	1			2
  Thomas Watson (IBM)		1
  Ed Bratt (Oracle)		1	2
  (Primeton Information Technologies)
  (Shandong Cvicse Middleware Co)
  	4 - individual 4 - reps	4 - individual 2 - reps	3 - individual 4 - reps *	3 - individual 3 - reps *

• * indicates this total includes reps alternative vote to their preference
• Do we want to rerun the strawpoll with a smaller subset of options (excluding the “losers” from the first round)?
• Why would a specification want to come to Jakarta?
• Brand strength?
• Namespace somewhat falls under this - it’s a technical issue
• Naming is a hotly contested issue
• If we slip in one place do we slip in others?
• If the naming impacts the end user - how?
• Rename package imports - user upgrade barrier
• Transitive dependencies was the bigger issue. There are no such libraries (using the MP namespace) for this situation
• Somewhat alleviated by transformers
• Worth publicly documenting why whichever way we decide?
• Document what the impact on the user (pros and cons) and any other consequences would be if we decide each way
• What happens if we enforce Jakarta?
• What happens if we don’t?
• Helps inform our decisions
• What would we do about maintenance releases?
• We can do maintenance releases on the old javax (EE8) namespace
• We moved to Jakarta to allow evolution of the APIs
• Indications from the MicroProfile straw polls is that they won’t migrate to Jakarta if we enforce namespace
• Ongoing tracking spreadsheet of specifications progressing through the JESP specification version lifecycle
• Issue #55 - TCK Archive Format [Ed Bratt]
• Check in on Ed Bratt’s PR: pending
• Not discussed
• Issue #83 - Clean up and clarify how to list TCK service releases on spec pages [Andrew Pielage]
• Check on progress of pull requests
• Not discussed
• Issue #74 - TCK challenge automatic acceptance - [Ed Bratt]
• Check on progress of specifications
• Not discussed
• Issue #58 - TCK challenge templates [Andrew Pielage]
• Check on progress of pull requests
• Not discussed
• Issue #82 - Consistent approach for TCK challenge exclusions [Ed Bratt]
• Carry over from February 19th: TCK Process should be updated with something akin to Scott Starks suggestion.
• Not discussed
• Review other open issues:
• 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