| Re: [jakarta.ee-community] [jakartabatch-dev] Proposal - Use Java 11 source/target level for Batch 2.1 |
Hi,The "grumbling" often comes from how it is presented. I suggest referring to the attached image (or similar) when faced with the grumbling.Even if the APIs themselves are restricted to Java SE 11 on source and binary level, we are ensuring that the TCK can be run on Java SE 17.That means that- implementations can (and most certainly will) certify on Java SE 17 as well as Java SE 11- which in turn means that applications can be compiled and run on Java SE 17 to take advantage of the performance optimizations between 11 and 17- developers can use all the Java SE 17 features they like in their applications, such as switch expressions, records, and text blocksSo, I would claim that Jakarta EE 10 supports Java SE 17. The requirement that the TCK must run with 17 ensures that.IvarOn Fri, Dec 3, 2021 at 2:44 AM Scott Stark <starksm64@xxxxxxxxx> wrote:_______________________________________________The JavaSE baseline issue is decided for EE10. Here is a summary of the vote that concluded on June 29 2021 that I have added to the platform dev issue for this topic:For further background you can read the minutes and platform dev threads in the preceding months.--- Summary:To wrap up this issue, the thread for the vote on the SE version is:
https://www.eclipse.org/lists/jakartaee-platform-dev/msg02650.htmlThe ballot summary spreadsheet is:
https://docs.google.com/spreadsheets/d/1Bu6IhGASVapXXaQix8HaED4JYx4UDj9eLEsjCP-7ddA/edit#gid=0This was a contingent vote (https://en.wikipedia.org/wiki/Contingent_vote), and a summary of tally of votes amongst the 3 choices is provided below as a chart. The three choices were:
Opt1: Java SE 11 as source/language level and binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 11 or higher.
Opt2: Java SE 11 as source/language level and Java SE 17 as binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 17 or higher. Opt3. Java SE 17 as source/language level and binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 17 or higher.
Opt3: Java SE 17 as source/language level and binary level for all API jars. Compatible implementations are free to pass TCKs using any Java SE version at 17 or higher.<<See JavaSE_vote.svg>>
The X axis in this chart gives the count of the first, second and third choices grouped by all votes, and committer only votes. The three bars in each section give the count for Opt1(green), Opt2(blue), Opt3(orange)
C1_all = the first choice tallies across all votes
C1_com = the first choice tallies for only committers
C2_all = the second choice tallies across all votes
C2_com = the second choice tallies for only committers
C3_all = the third choice tallies across all votes
C3_com = the third choice tallies for only committersThere were 36 votes in total, 12 committers, 24 non-committers. By the rules of the contingent vote, there was a clear majority of first choices for Opt1 regardless of whether committer votes counted or all votes counted, and so only the first choice votes needed to be considered.
---
On Dec 2, 2021 at 6:47:36 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:I think this is fine.
This is a bit of an aside but not sure if you would like to consider it:
I am hearing a lot of grumbling about Jakarta EE 10 not base-lining on Java SE 17 while keeping Java SE 11 and Java SE 8 optional. The precedent for Java EE had been that it always supported the newest Java SE version possible at the time of finalization of a release. This expectation could be a possible source of the grumbling.
I am curious to see if others have opinions on this?
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
On 12/2/2021 11:50 AM, Scott Kurz wrote:
We need to decide what Java level to target for Batch 2.1. Java 11 is the recommendation for the EE 10 platform, however since we still have not added any new APIs at this point we could still decide to go with our Java 8 level binaries from 2.0.
(This option is outlined in the platform release plan: https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan )
I propose we use Java 11 for source/target to stay in synch with the platform. If a user wants to remain on Java 8 they can just use the existing 2.0 API JAR.
Note in terms of language features I'm not sure we depend on anything more than Java 6 ?? still.
Any objections?
If not, then, to add a bit of a further thought, I think we end up with this table worth keeping in mind:
Language Features: Java 6?
javac target: Java 11
TCK execution: Java 11 + 17
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________ jakartabatch-dev mailing list jakartabatch-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--_______________________________________________Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community