[🚀 Feature]: Require Java 17 about selenium HOT 16 OPEN

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.

from selenium.

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

from selenium.

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.

from selenium.

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.

from selenium.

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.

from selenium.

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

Since 4.14, Java 11 is required.

from selenium.

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

from selenium.

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

from selenium.

@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.

from selenium.

+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.

from selenium.

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

from selenium.

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

from selenium.

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?

from selenium.

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.

from selenium.

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.

from selenium.

Wow, so Jenkins is being very aggressive.

Comparison of options:

from selenium.