[Feature Request] Update minimum compile/runtime versions to JDK25

[Bukhtawar]

Is your feature request related to a problem? Please describe

We want newer plugins(starting sandbox) to build with JDK-25 as we need Java to interact with Rust-native dependencies using FFM which has a stable API release in JDK-22JEP-454 and additionally optimises on GC performance with G1 region pinning espl with JNI interactionsJEP-423.
Similarly virtual‑thread synchronization without pinning gets unlocked which allows to scale well with virtual threads without needing to avoid synchronized blocks (JEP 491). I feel we might need these capabilities on core as well, sooner for performance enhancements.

Other significant performance change : JEP-519 Experiments show compact object headers boost performance—reducing heap/CPU use, garbage collections, and parsing time

Describe the solution you'd like

Since JDK-25 is the LTS version(reached General Availability on 16 September 2025), we want to ensure all newer development is able to utilise virtual thread and FFM capabilities sooner. So, while we updated the bundled JDK to have JDK25 #19314 we need to ensure minimum compiler and runtime capabilities also get bumped to JDK25.

Related component

Build

Describe alternatives you've considered

Have a separate CI for sandbox plugins to use JDK 25 as minimum compile time version as proposed in #21156

Additional context

No response

[cwperks]

@Bukhtawar take a look at the Auxiliary Checks from #20946. Can we split off the sandbox checks to run on a Github runner?

[msfroh]

For earlier versions of OpenSearch, I think we said that we would follow Lucene's practice of sticking with the same minimum JDK within a major version.

That said, Lucene is a library, so guarantees around JDK compatibility make a lot more sense. If someone wants to commit to Lucene 10.x, they should be sure that they can use the same JDK until they upgrade to Lucene 11. I'm guessing that most OpenSearch users use the bundled JDK or are okay with running a newer JDK for OpenSearch (since they're not necessarily running their own code in the same process).

Of course, I just told a colleague on Monday that I guarantee that all OpenSearch 3.x versions will be compatible with JDK 21, so if this proposal goes through, I look look like a liar. 😛