Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[META] Set OpenSearch 3.0.0 baseline JDK version to JDK-21 #14011

Open
18 of 31 tasks
reta opened this issue Jun 5, 2024 · 5 comments
Open
18 of 31 tasks

[META] Set OpenSearch 3.0.0 baseline JDK version to JDK-21 #14011

reta opened this issue Jun 5, 2024 · 5 comments
Assignees
Labels
Meta Meta issue, not directly linked to a PR

Comments

@reta
Copy link
Collaborator

reta commented Jun 5, 2024

Please describe the end goal of this project

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.

In order to make the migration as painless as possible, the suggestion is to start from dependent components (plugins, clients, extensions, libraries) and finish up with core, for the following reasons:

  • if we change core to JDK-21 baseline (bytecode), it will break all and every dependent component
  • however, because we always build core with JDK-21 (and bundle it in as well with JDK-21), there won't be any issues dealing the dependent components that are on JDK-21 baseline

Supporting References

Please see #10745

Issues

Related component

Build

@reta reta added Meta Meta issue, not directly linked to a PR untriaged labels Jun 5, 2024
@reta reta self-assigned this Jun 5, 2024
This was referenced Jun 5, 2024
@reta
Copy link
Collaborator Author

reta commented Jun 5, 2024

@msfroh @andrross @dblock @getsaurabh02 fyi folks :) kicking off the campaign ...

@dbwiddis
Copy link
Member

@reta Quick question on this.

In response to this campaign, I updated our compatibility from JDK 11 to JDK 21 like this:

java {
    targetCompatibility = JavaVersion.VERSION_21
    sourceCompatibility = JavaVersion.VERSION_21
}

Our normal development flow is to merge to main and backport to 2.x, which still supports earlier JDK's. I can see the potential for someone introducing code from a JDK between 12 and 20 (logically, 17) such as text blocks, switch expressions, records, and my new favorite stream operator, toList(). They'd pass muster on all our main branch CI but fail the backport and require substituting alternate code. Currently we limit this just to a very few differences to keep backporting simple.

I'm curious what the best approach here is. Can we keep targetCompatibility as 21 to address this campaign while still requiring sourceCompatibility of 11 to make sure backporting goes smoothly and doesn't diverge too much?

Or if we're keeping both, it seems this style may be more broadly applicable and recommended here. Thoughts?

tasks.withType(JavaCompile) {
    options.release.set(21)
}

@andrross
Copy link
Member

@dbwiddis See some more discussion here: opensearch-project/custom-codecs#154 (comment)

The risk is that some new language features will be exposed by a library using JDK21 as a baseline (i.e. Lucene) and that won't work smoothly if your source compatibility is lower than that. I'm not totally sure what those risks look like in practice though.

@dbwiddis
Copy link
Member

The risk is that some new language features will be exposed by a library using JDK21 as a baseline (i.e. Lucene) and that won't work smoothly if your source compatibility is lower than that. I'm not totally sure what those risks look like in practice though.

Agreed that it's not clear what the risks are. I think there are other options (e.g., ForbiddenAPIs) for enforcing lower-JDK source standards, so I'll look into those to address the risk of "dang, my backport failed". And evaluate whether it's more effort to prevent it than to just fix it when it breaks...

@reta
Copy link
Collaborator Author

reta commented Jun 11, 2024

I'm curious what the best approach here is. Can we keep targetCompatibility as 21 to address this campaign while still requiring sourceCompatibility of 11 to make sure backporting goes smoothly and doesn't diverge too much?

Thank you @dbwiddis , additionally to what @andrross said, I think the benefits of using new language features (as well as standard library) outweigh the inconvenience of manual backports (otherwise the legacy will always hold us back). Surely, there is also an option to use baseline constructs (JDK-11) without lowering the source compatibility levels.

And evaluate whether it's more effort to prevent it than to just fix it when it breaks...

I think this is sane approach, additionally we could also use something like https://github.com/openrewrite/rewrite (or similar) to "downgrade" source code during automatic backports.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Meta Meta issue, not directly linked to a PR
Projects
None yet
Development

No branches or pull requests

4 participants
@reta @andrross @dbwiddis and others