Agree.
Hi Emily, thanks forpointing this out. However, since we were able to change the plan just recently, why not change it again?
The requirement to have an impl for Java 17 is impractical and can significantly delay the release date of Jakarta EE 11, I think it’s worth dropping it.
Ondro
In the Jakarta EE 11 Release Plan page, the following was clearly documented: API Source Code --release LevelFor the Jakarta EE Platform (Platform, Web and Core), the Java compiler --release option is 17. For the component specs, the Jakarta EE Platform requires the Java compiler --release option is at most 17, but component specifications can decide on a lower level.
TCK Source Level
- Component spec TCKs and platform TCK must compile at Java 17 or less.
- A compatible component impl must pass their component TCK when run under Java 17 or 21.
- To ratify a component specification, there must exist an
implementation that passes on Java 17. There must also exist an
implementation that passes on 21.
- These need not be the same implementation. There can be one
implementation that passes on 17 and a different one that passes on 21.
- A compatible platform impl must pass the platform TCK when run under 17 or 21.
- To ratify a platform specification, there must exist an
implementation that passes on 17. There must also exist an
implementation that passes on 21.
- These need not be the same implementation. There can be one
implementation that passes on 17 and a different one that passes on 21.
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
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To 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
_______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
