Re: [jakarta.ee-spec.committee] Follow up on the topic of Jakarta EE 11

[Scott Stark <sstark@xxxxxxxxxx>]

Correct, we cannot drop support for Java SE 17 in the timeframe EE 11
will be incorporated into EAP 8.x.

On Fri, Jan 26, 2024 at 12:41 PM Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx> wrote:
>
> Thanks Scott,
>
> So my reading of this and apologies if I have got this wrong. It is not that there is a technical reason why "Red Hat will not deliver Jakarta Validation or Jakarta Context and Dependency Injection compatible implementations in the current EE 11 timeframe" it is just that you will choose not to as you don't want to impose Java 21 on users of your EE 11 implementation as you see that as too early to drop Java 17 support?
>
> RE: Concurrency, it is not a problem if there is another Compatible Implementation that runs on Java SE 17 that can pass the Concurrency TCK running in Java SE 17. It may be that the Eclipse Concurro project chooses to support both. I am using this as an example to show this relaxing leads to increased work which I worry impacts the timeline for Jakarta EE 11 more significantly.
>
>
>
> Steve Millidge
>
>
>
>
> -----Original Message-----
> From: Scott Stark <sstark@xxxxxxxxxx>
> Sent: Friday, January 26, 2024 5:53 PM
> To: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
> Cc: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
> Subject: Re: [jakarta.ee-spec.committee] Follow up on the topic of Jakarta EE 11 Progress Review
>
> We are not going to be able to commit to a Java SE 21 minimum runtime in either the Hibernate Validator compatible implementation for Jakarta Validation, nor the Weld compatible implementation for Jakarta Context and Dependency Injection as the downstream products cannot impose this restriction on users in the current roadmap for EE 11 based implementations. Our view of the Java SE 21 baseline was that it was sufficient to pass the TCKs running with a Java SE 21 runtime to demonstrate users could choose that option. However, Java SE 17 should also be usable anywhere the specifications were not updated to actually use Java SE 21 language features.
>
> For Concurrency, we don't see a problem if the compatible implementation uses Java SE 21 as the conversation around the Concurrency TCK has been that it would run under Java SE 17 or 21 as the virtual thread flag was just a hint that vendors did not need to honor if the server is not run in a Loom capable environment.
>
>
> On Fri, Jan 26, 2024 at 8:52 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
> >
> > Hi Scott,
> >
> > Thanks for the clarification. I am a little confused as the initial GitHub issue was framed around broader market adoption. However below is framed around not being able to deliver Jakarta EE 11 in the timeframe if this change does not go ahead.
> >
> > Can you outline the complexities that would make it more difficult and time consuming to target a single version, Java 21, rather than two Java versions 17 and 21? In my mind it is simpler to target a single Java version therefore there should be no delivery impact to maintain the status quo?
> >
> > I am aware that Eclipse Concurro for example, as a compatible implementation of Jakarta Concurrency, was planning to support virtual threads as a first class feature but now will need to do additional work (or not be the compatible implementation for Java 17) if this is agreed.
> >
> > Thanks
> >
> > Steve Millidge
> > Founder & CEO
> >
> >
> >
> > -----Original Message-----
> > From: jakarta.ee-spec.committee
> > <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Scott
> > Stark via jakarta.ee-spec.committee
> > Sent: Thursday, January 25, 2024 2:40 PM
> > To: Jakarta specification committee
> > <jakarta.ee-spec.committee@xxxxxxxxxxx>
> > Cc: Scott Stark <sstark@xxxxxxxxxx>
> > Subject: Re: [jakarta.ee-spec.committee] Follow up on the topic of
> > Jakarta EE 11 Progress Review
> >
> > What has been a point of confusion since the suggestion of a Java SE
> > 21 baseline is how that actually requires a Java SE 21 binary target for specification artifacts and therefore either SE 21 targeted compatible ratifying implementations, or a compatible ratifying implementation that uses a lower binary target, and rebuilt specification api jars. If there is a requirement to deliver component specification artifacts that target Java SE 21 binaries, Red Hat will not deliver Jakarta Validation or Jakarta Context and Dependency Injection compatible implementations in the current EE 11 timeframe.
> >
> > On Thu, Jan 25, 2024 at 7:50 AM Emily Jiang via
> > jakarta.ee-spec.committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
> > wrote:
> > >
> > > Further to the call yesterday, I understood the committee would like to start a ballot on the EE 11 Progress Review. I did not want to hijack the call to discuss the whole story about the Java 17 support requested.
> > >
> > >
> > > IBM intends to vote +1 on the Progress Review. I thought I would provide some more context on our thinking via this note.
> > >
> > >
> > > When EE 11 plan was made in August 2023, the minimum Java version was set to Java 21 with the hope of the component specifications utilizing the APIs from Java 21. The reality is that none of the specifications used any APIs from Java 21 including Jakarta Concurrency (Jakarta Concurrency does add one method for Virtual Thread, and this does not depend on Java 21.) The Jakarta Concurrency TCK was written in a way that it can pass on either Java 21 or Java 17.
> > >
> > >
> > > Because of this, the Platform team has agreed with the change of the dependency from Java 21 to Java 17.
> > >
> > > What is the consequence of changing the minimum Java version to Java 17?
> > >
> > > It has no impact to the runtimes that only plan to support Java 21. They can continue to do so. The only impact is on the specification implementations and ratifying runtimes, and Glassfish has done the necessary updates to support both Java 17 and Java 21.
> > >
> > >
> > > In order to encourage the widest adoption on Jakarta EE 11, I think it is reasonable to broaden the scope to accommodate Java 17 and the broader set of implementations that run on it. Different runtimes can choose which Java version they support, and this information can be clearly listed on the Jakarta EE compatibility website. It is no change from EE 10, which supports both Java 11 and Java 17.
> > >
> > >
> > > We think it is important the vote passes, so that we can release Jakarta EE 11 this year. Thank you for spending time reading my note!
> > >
> > >
> > > Thanks
> > > Emily
> > > ================
> > > Emily Jiang
> > >
> > > Java Champion, Fellow of BCS
> > > STSM, Jakarta and MicroProfile Architect @IBM Liberty Cloud Native
> > > Architect & Advocate
> > >
> > > E-mail: emijiang@xxxxxxxxxx
> > > Twitter: @emilyfhjiang
> > > LinkedIn: https://www.linkedin.com/in/emilyfhjiang/
> > >
> > > ________________________________
> > > From: jakarta.ee-spec.committee
> > > <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> on behalf of Paul
> > > Buck via jakarta.ee-spec.committee
> > > <jakarta.ee-spec.committee@xxxxxxxxxxx>
> > > Sent: 25 January 2024 03:38
> > > To: Jakarta specification committee
> > > <jakarta.ee-spec.committee@xxxxxxxxxxx>
> > > Cc: Paul Buck <paul.buck@xxxxxxxxxxxxxxxxxxxxxx>
> > > Subject: [EXTERNAL] [jakarta.ee-spec.committee] Review for approval:
> > > Jakarta EE Specification Committee Meeting Minutes - January 24th,
> > > 2024
> > >
> > > The minutes for the January 24th Specification Committee call are
> > > below and are also available here. Please review and be ready for
> > > approval during our call on February 7th, 2024. Jakarta EE Spec
> > > Committee - January 24th, 2024 Attendees (present ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization.
> > > Report Suspicious
> > >
> > > ZjQcmQRYFpfptBannerEnd
> > >
> > > The minutes for the January 24th Specification Committee call are below and are also available here. Please review and be ready for approval during our call on February 7th, 2024.
> > >
> > > Jakarta EE Spec Committee - January 24th, 2024
> > >
> > > Attendees (present in bold):
> > >
> > >
> > > Kenji Kazumura - Fujitsu
> > >
> > > Emily Jiang - IBM - Tom Watson
> > >
> > > Ed Bratt - Oracle - Dmitry Kornilov
> > >
> > > Andrew Pielage - 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
> > >
> > >
> > > Guests - Jakarta EE 11 co-release coordinators: Ed Burns, Arjan
> > > Tijms
> > >
> > >
> > >
> > > Eclipse Foundation: Tanja Obradovic, Wayne Beaton, Paul Buck (chair)
> > >
> > >
> > > Past business / action items:
> > >
> > > Approval is requested for the minutes from the January 10th, 2023 meeting as drafted - Approved.
> > >
> > >
> > > Agenda:
> > >
> > > Ongoing tracking spreadsheet of specifications progressing through
> > > the JESP specification version lifecycle
> > >
> > > See the spreadsheet for updates.
> > >
> > > In the January 10th Specification Committee call, the situation regarding Jakarta EE 11 Platform Project including Java 17 as a supported platform was discussed. Since that discussion, the Jakarta EE 11 Release Plan was revised:
> > >
> > > See the email from Ed Burns for the background
> > >
> > > https://www.eclipse.org/lists/jakarta.ee-spec.committee/msg03441.htm
> > > l
> > >
> > > Will Lyons shared his observations on this revision with the
> > > Specification Committee in his email
> > >
> > > https://www.eclipse.org/lists/jakarta.ee-spec.committee/msg03442.htm
> > > l
> > >
> > > As a follow-up to Will’s email, Wayne Beaton provided his guidance
> > > to the Committee in his email
> > >
> > > https://www.eclipse.org/lists/jakarta.ee-spec.committee/msg03444.htm
> > > l
> > >
> > > Today’s agenda topic is for the Committee to review the guidance
> > > from Wayne and decide what if any specific actions are required
> > >
> > > Options discussed w/ Wayne:
> > >
> > > Send a warning message noting the plan revision and there is risk to
> > > proceeding to Release Review
> > >
> > > Request a to the Platform Project for Progress Review now noting the
> > > changes in the revised plan
> > >
> > > Do nothing, the Release Review based on this revision is not at risk
> > >
> > >
> > > The three options were discussed and there are no objections voiced to proceed with option 2. The Spec Committee will therefore initiate a formal Progress Review ballot request for the Platform Project. The committee chair will collaborate w/ the EMO to formulate the request to the Platform Project.
> > >
> > >
> > > The formal agenda of the committee concluded and a general discussion ensued on Jakarta EE 11 release plan.
> > >
> > >
> > > Unless otherwise stated above:
> > >
> > > IBM United Kingdom Limited
> > > Registered in England and Wales with number 741598 Registered office:
> > > PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> > > _______________________________________________
> > > jakarta.ee-spec.committee mailing list
> > > jakarta.ee-spec.committee@xxxxxxxxxxx
> > > To unsubscribe from this list, visit
> > > https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
> >
> > _______________________________________________
> > jakarta.ee-spec.committee mailing list
> > jakarta.ee-spec.committee@xxxxxxxxxxx
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>