[🚀 Feature]: Require Java 17

[titusfortner]

Feature and motivation

We talked last year about requiring Java 17 later this year, are we still on track for that?

Would it make sense to make that part of Selenium 5?

Usage example

n/a

[joerg1985]

Why not going to 21 (also LTS) instead?
Everybody who needs to upgrade it's local JVM could install 21 instead of 17, so there is no overhead for them.

[diemol]

It is just easier to convince people to do the shorter jump.

I also had in mind the requirement to have at least Java 17 in autumn, at the beginning of winter. Even if Selenium 5 does not happen.

[baflQA]

The only jump you have to convince people to, is to drop JDK 8. I would also vote for targeting the most recent LTS release.

[diemol]

https://www.selenium.dev/blog/2023/java-8-support/

Since 4.14, Java 11 is required.

[baflQA]

That's what I mean 😅 the biggest step was done.

[titusfortner]

Java 17 is EOL in September 2024
So it might make sense to jump to 21 which is how we do it for all the other languages

[titusfortner]

@diemol / @pujagani / @joerg1985
Do we know what code changes we would make if we could update to either 17 or 21?

If we don't have anything specific, it might make more sense to update more slowly. For Java 11 we had a specific need for the http client.

[pujagani]

+1 to Titus and Diego's thought process. I don't know anything pressing that requires Java 21 right off the bat in our codebase. I am in favour of updating slowly since it is not a trivial task in many organizations/users due to various reasons based on what I have seen.
However, based on what I understand, Java 21 does have performance improvements. So might be a good idea to identify timelines for that too.

[joerg1985]

I don't think there is a specific improvment in 21 that could be helpful currently.

[titusfortner]

I'm seeing this as the "End of Public Updates" for Java 17:

September 2024 for Oracle[4]
October 2027 for Eclipse Temurin[13]
October 2027 for Red Hat[8]
October 2029 for Amazon Corretto[14]
September 2029 for Azul[11]
March 2030 for BellSoft Liberica[10]

If we don't have anything specific in mind to target Java 21, I think we should continue to support Java 17

[titusfortner]

In other languages we remove support for versions that are no longer "officially" supported.
What if we do "oracle LTS - 1"
So:

• Require Java 17 on September 2024
• Require Java 21 on September 2026
• Require Java 25 on September 2028

[Lorondos]

The New Relic report is pretty insightful:

https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem

Two key points:

• 35% of applications are using Java 17, representing a nearly 300% growth rate in one year. It took years for Java 11 to reach anywhere near that level.
• Eclipse Adoptium rising in popularity amongst JDK vendors.

[titusfortner]

Ouch, if we require Java 17, that's over 60% of people right now where it wouldn't match their current dev environments, so we may want to be more conservative; especially if there isn't anything we need to upgrade for (like we did for Java 11).

If we use the Eclipse EOL dates that's:

• Require Java 17 on September 2027
• Require Java 21 on September 2029
• Require Java 25 on September 2031

Is that too conservative?

[Lorondos]

Jenkins went through 3 proposals and landed on supporting 2 LTS versions at any given time:

Therefore, the Jenkins project is adopting a 2 + 2 + 2 Java support plan, where Jenkins supports a new Java LTS release in the first two years after the general availability of that Java LTS release, then requires that Java LTS release as the Jenkins minimum Java version in the next two years of that Java LTS release’s upstream support, then drops support for that Java LTS release two years before that Java LTS release reaches end of life upstream.

In practice, this means that Jenkins will support a given Java LTS release for approximately two-thirds the amount of time that upstream Java vendors do, that Jenkins will support two Java LTS releases at any given time rather than three, and that large scale users can stay on a Java LTS release for four years at a time.

https://www.jenkins.io/blog/2023/11/06/introducing-2-2-2-java-support-plan/

I suspect differing needs of features however, with Selenium.

[joerg1985]

I think the base line is the support of the netty and the graphql dependencies. They are hard to replace and externally exposed by the server, so there must be support from a security point of view. Everything else could be somehow replaced. But i don't know the jdk support plan of them.

[titusfortner]

Wow, so Jenkins is being very aggressive.

Comparison of options:

Minimum Version	Oracle	Eclipse	Jenkins
Java 17	September 2024	September 2027	September 2024
Java 21	September 2026	September 2029	September 2025
Java 25	September 2028	September 2031	September 2027

[github-actions]

This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 14 days with no activity.

[Lorondos]

Was there a conclusion to this with Java 17/21 LTS support? I would argue for 21 LTS though it seems most are going with a hard requirement of 17 at least. Maven 4 will require Java 17 for example. https://lists.apache.org/thread/145fmwcfrt0qo1qwfpop7rozhsrv60wk

Interesting comment here in relation to the JDK support for Maven 4:

Managed to find an interesting report from the Eclipse Foundation, mostly focused on Jakarta but seems adoption is quite fast pace:

https://outreach.eclipse.foundation/hubfs/2024%20Jakarta%20EE%20Developer%20Survey%20Report%20.pdf