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

Gradle has poor handling of Java versions #125819

Closed
leo60228 opened this issue Jun 5, 2021 · 5 comments
Closed

Gradle has poor handling of Java versions #125819

leo60228 opened this issue Jun 5, 2021 · 5 comments
Labels
0.kind: bug Something is broken 6.topic: developer experience 6.topic: java Including JDK, tooling, other languages, other VMs

Comments

@leo60228
Copy link
Member

leo60228 commented Jun 5, 2021

Describe the bug
The gradle package sets JAVA_HOME to jdk, which is Java 8. This means that compilation and Gradle itself will use that version of Java, which is problematic since both projects and Gradle plugins may be using newer versions of Java.

To Reproduce
Steps to reproduce the behavior:

  1. Build a project with Gradle that requires a newer version of Java.

Expected behavior
I expect there to be a clear way to handle needed Java versions.

Additional context
There are several workarounds here. Newer versions of Java can be configured as Gradle toolchains, but that doesn't help for plugins, and is somewhat ugly (since toolchains can only be configured via dotfiles or command-line arguments). Alternatively, the Gradle package can be overridden, but this is somewhat ugly and non-trivial with the new Nix CLI.
However, this problem is complicated by the fact that many projects will expect a Java 8 compiler. A solution could be to run Gradle itself with the latest packaged version of Java and to have support for Gradle toolchains to use multiple compiler versions.

Notify maintainers

@lorenzleutgeb

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-linux"`
 - host os: `Linux 5.10.37, NixOS, 21.05.20210531.d25ea6a (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.4pre20210529_1f39092`
 - channels(root): `"nixos-21.03pre250162.34ad166a830, unstable-21.03pre250162.34ad166a830"`
 - channels(leo60228): `"unstable-21.03pre248170.007126eef72"`
 - nixpkgs: `/nix/store/wxq267m1smpj631y19qpdyn82l8mnj90-source`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: gradle gradle_4 gradle_4_10 gradle_5 gradle_6 gradle_7
# a list of nixos modules affected by the problem
module:
@leo60228 leo60228 added the 0.kind: bug Something is broken label Jun 5, 2021
@lorenzleutgeb
Copy link
Member

lorenzleutgeb commented Jun 5, 2021

See also gradle/gradle#16645 (sadly not much interest/activity over there)

See also https://discourse.nixos.org/t/auto-detecting-java-installations/4677

@leo60228
Copy link
Member Author

leo60228 commented Jun 5, 2021

I saw those, but if I understand correctly they only apply to compilation and not the Gradle daemon, so they wouldn't help with plugins requiring newer versions of Java (like https://github.com/FabricMC/fabric-loom).

@leo60228
Copy link
Member Author

leo60228 commented Jun 5, 2021

The line in all-packages.nix making Gradle use Java 8 references #89731. However, as far as I can tell, that PR provides no explanation for why keeping Gradle on Java 8 was necessary. I misread the PR description, never mind.

@lorenzleutgeb
Copy link
Member

Ah, it seems I misunderstood what you were aiming at. How about overriding the JDK used for your Gradle?

Making this more flexible is what I was trying to do in #119444 but that's somewhat stalled. Maybe also worth considering. Happy to take your feedback and/or improvements there.

@roberth roberth added the 6.topic: java Including JDK, tooling, other languages, other VMs label Jun 21, 2021
@lorenzleutgeb
Copy link
Member

I believe this was resolved with #119444

It is now possible to pass java (the JDK that Gradle itself should use) and javaToolchains (a list of JDKs that should be registered as toolchains). Sane defaults for java are used.

I'll go ahead and close this issue, because I believe it is resolved and it is inactive for >6 months.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: bug Something is broken 6.topic: developer experience 6.topic: java Including JDK, tooling, other languages, other VMs
Projects
None yet
Development

No branches or pull requests

4 participants