| Exactly.
We just need anyone to show up with any of the allowed JDKs and we can ship the final release.
Here are some references to the EFSP text changes:
EFSP 1.0, 1.1 and 1.2 did require all optional parts to be implemented and tested. In particular these lines were all removed in version 1.3 to fix this:
- "A Specification may describe parts as being optional. Optional parts of a Specification must not conflict with one another; it must be possible for a Compatible Implementation to implement all optional parts." - "All parts of a Specification, including optional parts, should be covered by the TCK." - "A Specification Version must identify at least one Compatible Implementation under an Open Source License that implements all optional elements of the Specification and fulfills the requirements of all elements (including optional elements) of the TCK."
Those revisions:
It was basically us (Jakarta EE) that drove that removal specifically because of the lack of fairness, both to GlassFish and to other implementations.
Thanks, Scott. I missed that thread. What you suggest makes sense to me and I think it’s not against the EFSP: any impl on any Java version should be enough to ratify Jakarta EE release. Any issues with running the TCK on a different Java version can be resolved later as a patch release.
Big +1
Ondro The point of the https://github.com/jakartaee/specification-committee/issues/77 issue is to challenge that assumption. Neither the spec process or the spec operations guide calls out that ratification of a spec requires a compatible implementation for every Java SE version. That is simply something that has been done.
Nothing forces GlassFish 8 to run on Java 17. But there’s some impl required to pass TCK on Java 17 to release Jakarta EE 11. I felt that everybody assumes GlassFish will be used also for Java 17. If not, is there any other impl that could be used soon, so that EE 11 can be released ASAP even if GF doesn’t run on Java 17? Ondro Speaking only of my opinion and not about the rules, GlassFish should have equal right to decide to support any JDK at the minimum or up.
If we still have restrictions/requirements in our specification process that do not allow GlassFish to in practice have the same flexibility as any other Jakarta EE implementation, we should work to eliminate those restrictions. Previously, it was the requirement that one implementation had to implement all optional features that put undo burden on GlassFish in practice. I had thought we revised the EFSP to remove that requirement.
Side note on too many meetings and general desire for more list discussion prior to votes: agree 1000%
-- David Blevins
Thank you, Ivar, for the conclusion.
The vote is done and I want to assure you that I respect that.
I just want to comment that, for such important ballots, in the future, I'd welcome that there's a separate discussion thread on the mailing list before the ballot is started. All those who cast -1 vote raised very serious concerns that might have influenced other votes if those concerns were expressed earlier. It's very irresponsible to have a ballot on such serious issues without a proper discussion.
I know that there were discussions on the platform calls but the ballot was held in the specification committee. Not all who voted participated in the platform discussions. Moreover, the decision in the platform was made with the assumption that GlassFish will support Java 17. However, all companies behind GlassFish that are on the spec committee (Oracle, Fujitsu, Payara) voted -1. OmniFish, currently the biggest contributor to GlassFish, is also against, as well as other very active community contributors to GlassFish.
In summary, I want to repeat what i said yesterday on the platform call - it's very risky to make this decision and rely on the GlassFish team to follow, without any help from other Jakarta EE stakeholders. The GlassFish team had no intentions to support Java 17 in GlassFish 8 and it's only additional burden to support Java 17, without any benefits for GlassFish. In the end, the decision to support Java 17 may, and most probably will, delay the release of Jakarta EE 11, if GlassFish is expected to ratify Jakarta EE 11 on Java 17. In the future, it's very important to have a proper discussion among all voting parties before decisions like this are made, so that all voting parties have good understanding of the consequences of their vote. All the best,Ondro Mihalyi
Director, Jakarta EE expert
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
