[jakarta.ee-spec] Jakarta EE Spec Committee Approved Meeting Minutes - J

[Andrew Pielage <andrew.pielage@xxxxxxxxxxx>]

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 3 - reps *	4 - individual 4 - 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