Remove support for Java 8

[dblock]

Is your feature request related to a problem?

Because Lucene 9 requires JDK 11+, remove support for Java 8.

Uncomment commented code in #2321 for killing child processes that uses JDK9+ ProcessInfo.

[reta]

@dblock this is great, I am wondering if we've ever done comprehensive benchmarking for JDK-8 vs JDK-17 for OpenSearch? I think we have all pieces in place to do that now, and it would be awesome to do that in the scope of this issue, wdyt?

[dblock]

Benchmarking is being actively worked on in #1276, add comments to that issue.

[anasalkouz]

@elfisher, do you how many clients are currently using Java 8?

[andrross]

According to this website, active support for Java 8 ends in March 2022, while security updates will continue to 2025. I'm in favor of removing support for Java 8 for new versions with the end of active support approaching, unless doing so is a significant barrier to adoption of new OpenSearch versions.

[elfisher]

@elfisher, do you how many clients are currently using Java 8?

@VijayanB and @gaiksaya do you know which java version the high-level rest and opensearch-java clients use?

[VijayanB]

opensearch-java supports Java 8 or later, but we test against only Java 14 in CI. For high-level, it should be same as OpenSearch.

[andrross]

@elfisher I think the question is more whether we have users of OpenSearch using a Java 8 runtime who for whatever reason cannot easily upgrade to newer version. If possible we'd like for OpenSearch 2.0 to require Java 11 or newer as a runtime version so that we no longer have to support or test against Java 8.

[reta]

Since Apache Lucene 9.0 requires JDK-11, we have no choice but to bump Opensearch 2.0.0 minimum JDK requirements to JDK-11 (at least) as well. Looking on the other projects which are facing (or just bumping) minimum JDK requirements, it seems like going with JDK-11 may not be the best option since we have next LTS release already - JDK-17.

Different JDK vendors claim the end of (official) support of JDK-11 somewhere in 2023/2024 (for example, [1], [2]) with hard deadline being 2026 [3]. The upcoming versions of Spring and Elasticsearch are settling on JDK-17, I am wondering if we should be taking this route as well? @andrross @dblock @nknize what do yo think guys?

[1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
[2] https://access.redhat.com/articles/1299013
[3] https://endoflife.date/java

[andrross]

Are there users of OpenSearch who for whatever reason run it in an environment where it is not easy to upgrade to a JDK-17 runtime? I honestly don't know the answer to that question, but my only concern is that if we move too fast on the minimum requirement then we could add barriers for such users from upgrading or adopting OpenSearch. If that is not a reasonable concern then I'm all for moving fully to the latest LTS.

[reta]

Thanks @andrross , I don't know the right answer either, we could delay the decision to the moment when 2.0.0 release materializes, but it would be good to collect compelling arguments in favour or JDK-17 as minimum required version (using latest language features is definitely one of those but not sufficient).

[andrross]

Having the recommended version and minimum required version both be JDK-17 simplifies the test matrix as well.

[dblock]

That seems like a high jump. A third of users in https://discuss.opendistrocommunity.dev/t/poll-which-version-of-java-do-you-use-with-opensearch/8189 are saying they use 11, and I wonder whether it's just because it's LTS or something else.

[reta]

@dblock I believe because of LTS, right. The move from JDK-11 to JDK-17 should be super smooth, essentially - there are no reasons to stay on JDK-11 (for the vast majority of deployments).

[hashworks]

I would guess that a good amount of those 34% use 11 because OpenSearch recommends it, not because they preferred it over 17.

[jcgraybill]

The supported lifecycle of 17 is a compelling reason to adopt it for OpenSearch 1.x, in my eyes. I think we should benchmark and understand what it would take to move the minimum and recommended version to 17, and only consider dropping one of those to 8 or 11 if we identify a big obstacle.

[reta]

@jcgraybill it has been started already here #1276

[reta]

But JDK-8 is out of question if we want to move on with Apache Lucene 9.x, JDK-11 is a minimum requirement

[dblock]

@martin-gaievski Anything left here? Can we close?