[PROPOSAL] Set OpenSearch 3.0.0 baseline JDK version to JDK-21

[reta]

Is your feature request related to a problem? Please describe.
Currently, the 3.0.0 baseline JDK version is set to JDK-11. The Apache Lucene 10 is going to require JDK-21 and it would make sense to align the OpenSearch JDK baseline requirements with that.

Describe the solution you'd like
Set the target / source level to JDK-17. Allow to use new features of the languages and the standard library.

Describe alternatives you've considered
Why not JDK-21? As of today, for a few reasons:

• we are still trying to move to JDK-21 as a runtime (see please [META] Ensure JDK-21 (baseline) ecosystem readiness  #10334), so there are few unknowns here to understand the impact
• we need to align with
  a) OpenSearch plugin developers
  b) community plugin developers
  c) other projects in ecosystem (https://github.com/opensearch-project/opensearch-hadoop, https://github.com/opensearch-project/spring-data-opensearch, https://github.com/apache/flink-connector-opensearch, ... and many others)

Depending on the release date of 3.0.0, we may reconsider the decision for a more aggressing JDK baseline.

Additional context
Backports to 2.x will be more complicated

• [FEATURE] Set baseline JDK version to JDK-21 security#3609
• apache/lucene@8f17f23

[nknize]

we are still trying to move to JDK-21 as a runtime

Note that a JDK 21 runtime is already supported and project Panama MMap and SIMD vector incubation APIs will be used by Lucene. It's just not the default, so I think this is more about deciding which version to bump for min supported and bundled JDK.

[reta]

Thanks @nknize , are still trying to move is about the rollout (the codebase, at least core, should be ready, there are issues with that outside of core): we are blocked on distributions availability.

[nknize]

we are blocked on distributions availability.

By "distribution" I assume you mean the OpenSearch bundle? Min distribution is ready to go, just change the system runtime.

there are issues with that outside of core

This is a reason I'm not a fan of the OpenSearch bundle force installing all bundled OpenSearch plugins (originally decided back in the ODFE days). IMHO it's a better user experience to let the user choose which plugins they want to install instead of assuming they know which are safe to uninstall. It gives the user more control in keeping their runtime lean with only the features they want to use. If a plugin(s) is not JDK 21 compatible a user could still bump their bundle runtime if they didn't install the JDK incompatible plugin.

We could also provide a version compatibility check mechanism at plugin install and/or upgrade migration time to inform the user of JDK incompatibilities.

[reta]

By "distribution" I assume you mean the OpenSearch bundle? Min distribution is ready to go, just change the system runtime.

No, JDK-21 distributions, see please #10334 (TLDR; ppc64 is still being cooked, we need it)

If a plugin(s) is not JDK 21 compatible a user could still bump their bundle runtime if they didn't install the JDK incompatible plugin.

The problem is that some plugins use Gradle with Kotlin and this beautiful combination does not support JDK-21 at all, also see please #10334 (TLDR; people physically cannot build with JDK-21 even to verify compatibility)

We could also provide a version compatibility check mechanism at plugin install and/or upgrade migration time to inform the user of JDK incompatibilities.

That's correct, enforcing the baseline (JDK-21) at this point will be too much, JDK-17 seems to be reasonable.

[nknize]

No, JDK-21 distributions.

Sorry I think there was confusion. I'm not suggesting we bump bundled JDK to 21. I'm very much +1 bumping bundled to 17 or maybe even 19. I was just making a comment that the vast majority of users can already use their own JDK 21 runtime and thus get the benefits of Panama MMap and incubating SIMD optimizations provided by the latest Lucene improvements. There are just some corner cases that can't. I want to make sure we don't send a misleading message that OpenSearch is not 21 runtime compatible. Doing this could provide marketing fodder to those less informed that wish to push reasons why a user should pick or switch to Elasticsearch instead.

TLDR; people physically cannot build with JDK-21 even to verify compatibility

I think maybe I'm not being clear here either so my apologies for the confusion. I'm not suggesting users trial by fire build with 21. I'm suggesting we provide a compatibility mechanism for them that checks their runtime and their list of installed plugins and informs the user if they have a plugin installed that's incompatible with the 21 runtime if they are interested in bumping it themselves. Though maybe it's not needed and a compatibility matrix is sufficient. I'm just brainstorming ideas to make the user experience more appealing.

some plugins use Gradle with Kotlin

Just a personal (controversial?) opinion here but kotlin is another reason I dislike the bundle installing all plugins by default. Kotlin is of course compatible with Java (jetbrains originally developed for improving java and many use it for Android) but they're not the same and there are subtle performance differences when comparing with Java that make me cautious trusting performance when calling OpenSearch java from kotlin code. I think we could do better here to have kotlin plugins provide more reliable benchmarking. Combine that with the fact that Kotlin lags JDK versions and delays upgrades like we see with JDK 21 and it only substantiates my opinion that we should rethink implementing bundled plugins in kotlin altogether. We certainly shouldn't force install them on users.

[reta]

Thanks @nknize , I think we touched upon very important topics but a bit derailed from the this proposal, I would blame myself for the confusion. I will try to clarify what exactly the goal is.

The OpenSearch 3.0.0 and 2.x codebases are requiring JDK-11 baseline from the source and binary level, so for anyone using the OpenSearch bits the JDK-11 is a minimum required version.

  allprojects {
    java {
        targetCompatibility = JavaVersion.VERSION_11
        sourceCompatibility = JavaVersion.VERSION_11
    }
  }

I suggest for OpenSearch 3.0.0 we elevate the baseline to JDK-17 (for the reasons I shared in the description):

  allprojects {
    java {
        targetCompatibility = JavaVersion.VERSION_17
        sourceCompatibility = JavaVersion.VERSION_17
    }
  }

How it relates to bundled distributions? The 2.x is bundled with JDK-17 LTS right now (https://github.com/opensearch-project/OpenSearch/blob/2.x/buildSrc/version.properties#L5) but anyone could run it on JDK-11+ (since this is a baseline). For 3.x (unless the release won't happen till JDK-25), we would bundle JDK-21 LTS, but anyone could run it on JDK-17+ (with this proposal).

Does look a bit more clear? Thanks again!

[nknize]

but a bit derailed from the this proposal, I would blame myself for the confusion.

No worries at all! I should've started with "I agree bumping the min required version..." instead of saying "I think this is more about deciding which version to bump for min supported and bundled JDK." and then clarified the 21 runtime just so folks don't think we have zero support.

I suggest for OpenSearch 3.0.0 we elevate the baseline to JDK-17 (for the reasons I shared in the description):

I've been mulling this one over a bit so I just went ahead and opened an issue to transfer what's in my head to github for discussion. For 3.0.0 (which is a ways off) we could consider bumping to JDK19 to guarantee availability of preview features like virtual threads. This would enable us to explore using them as an optimization for some of the distributed I/O heavy ops (disk, network) to bump overall OpenSearch performance by default. Lucene doesn't much care because of some reasons discussed in relatively recent discussions.

[reta]

Thanks @nknize

For 3.0.0 (which is a ways off) we could consider bumping to JDK19 to guarantee availability of preview features like virtual threads.

What is the reason for JDK-19 (non LTS and dead) vs going JDK-21? We could also go 2 step, JDK-17 -> JDK-21, requiring JDK-19 at this point I think is not needed, no one runs on it (I am 100% sure).

[nknize]

(non LTS and dead)

That's right I forgot it was superseded.

requiring JDK-19 at this point I think is not needed

I agree at this point we don't need it since Lucene already handles the mrjar logic for us. I think for vThreads work it would be useful but 21 will likely be fully supported by the time that work is done.

We could also go 2 step, JDK-17 -> JDK-21

+1 to this as the approach. We can prototype 21 vThreads and then make the move if we merge it as a Feature Flagged enhancement.