Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] [jakartabatch-dev] Proposal - Use Java 11 source/target level for Batch 2.1
Hi,

The rationale behind the decision was that at the time of planning, Java SE 17 wasn't even released yet. None of the specification projects wanted to base their specifications on non-released features and considered it a better idea to gain knowledge and experience with the new features before standardizing on them and risking adding things to the APIs prematurely.

It is expected that the next versions of the specifications (and Jakarta EE 11) will be defined using Java SE 17 language features where appropriate.

The important message is that Jakarta EE 10 will be possible to implement, certify, build applications and run with Java SE 17.

Ivar

On Fri, Dec 3, 2021 at 12:30 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
Thanks certainly for the clarification. What would be really great is a cogent rationale for why we didn’t just baseline on Java SE 17 outright.

Was it because some implementations are just more conservative in terms of their Java SE version support? What was the compelling value of using Java SE 11 as the baseline? Was the issue that a jump from Java SE 8 to 17 felt like it was “skipping” Java SE 11? Does Java SE 17 deprecate something that makes it harder to baseline on?

I have to say part of the confusion for me personally is that while I see plenty of people saying Java SE 8 is good enough for them, I don’t see much enthusiasm for Java SE 11 as a release as compared with Java SE 17. Surely I must be missing a perspective?

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.
 
From: jakarta.ee-community <jakarta.ee-community-bounces@eclipseorg> on behalf of Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, December 3, 2021 2:25 AM
To: Jakarta EE community discussions
Subject: 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 blocks

So, I would claim that Jakarta EE 10 supports Java SE 17. The requirement that the TCK must run with 17 ensures that.

Ivar

On 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.html

The ballot summary spreadsheet is:
https://docs.google.com/spreadsheets/d/1Bu6IhGASVapXXaQix8HaED4JYx4UDj9eLEsjCP-7ddA/edit#gid=0

This 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 committers

There 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


--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 

Back to the top