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

build: Set the target JVM to 11 #8403

Closed
wants to merge 1 commit into from
Closed

build: Set the target JVM to 11 #8403

wants to merge 1 commit into from

Conversation

mnonnenmacher
Copy link
Member

Configure Gradle to build class files compatible with Java 11. This allows to use the published ORT artifacts also in Projects that use Java 11. Previously, Java 17 was required.

The main use case for this is to be able to build the Analyzer Docker image for the ORT Server 1 with Java 11 which is required to analyze Gradle projects that are not compatible with newer Java versions.

Relates to #8249.

@mnonnenmacher mnonnenmacher requested a review from a team as a code owner March 12, 2024 11:57
Configure Gradle to build class files compatible with Java 11. This
allows to use the published ORT artifacts also in Projects that use Java
11. Previously, Java 17 was required.

The main use case for this is to be able to build the Analyzer Docker
image for the ORT Server [1] with Java 11 which is required to analyze
Gradle projects that are not compatible with newer Java versions.

Relates to #8249.

[1]: https://github.com/eclipse-apoapsis/ort-server

Signed-off-by: Martin Nonnenmacher <martin.nonnenmacher@bosch.com>
.getOrDefault(enumValues<JvmTarget>().max())
val jvmTargetCompatibility = JvmTarget.JVM_11
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sschuberth Does it make sense to keep the logic to determine the max version and use different versions for source and target or should we just hard code both to Java 11?

Copy link
Member

@sschuberth sschuberth Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. As IIRC the JVM source compatibility is only also set to avoid the warning mentioned in https://youtrack.jetbrains.com/issue/KT-48745, we probably should just hard-code it. Or yet better, do as advised in this comment and use Gradle's toolchains mechanism with version 11 hard-coded there.

If you want to, I can take over the task to refactor this PR accordingly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please go ahead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sschuberth Any chance we can get this change into tomorrow's release?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's my goal, yes, and I'm on it. Just learned a few unexpected things about Gradle toolchains that require me to think about it a bit more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #8411, which I propose to use instead of this PR.

@sschuberth sschuberth closed this Mar 14, 2024
@sschuberth sschuberth deleted the java-11-target branch March 14, 2024 08:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants