jdk: point attributes without version suffix to latest

[doronbehar]

For too long jdk was pointing to the legacy, unmaintained openjdk8 and too many apps are using it just because it works. This PR aims at making all apps that have jdk in their inputs to use jdk8 explicitly. The end goal is to get from ofborg the "0:rebuild-linux" label, that's why it's still a draft.

Motivation for this change

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[asbachb]

I wonder if it's smart to default jdk to 14. I suspect that several java depended packages will break.

Maybe it would make sense to introduce some kind of lts (java 11) and legacy (java 8) aliases.

[doronbehar]

I suspect that several java depended packages will break.

The current plan is to do something similar to what was done at #89264 :

1. Make 14 the default at all-packages,nix
2. Iterate (I did it with git grep but it's possible there's a smarter way) all usages of jdk without an explicit version suffix and replace these usages with jdk8 specifically.

The goal of part (2) is to make ofborg label the PR as 1:rebuild-linux where the only changed path is the rename jdk 8 ->14.

With ffmeg it was a 135 files changed, 279 insertions(+), 279 deletions(-) PR, but with jdk, I expect it to touch something like ~500 files ... If you are up to contribute, I'd love to get help with this tedious task.

Maybe it would make sense to introduce some kind of lts (java 11) and legacy (java 8) aliases.

The point is that whatever is called jdk should point to the latest version, with or without aliases. The fact that a certain jdk update isn't backwards compatible doesn't mean we should be stuck with it as Nixpkgs' default for ever. See https://discourse.nixos.org/t/nixpkgs-policy-regarding-libraries-available-in-multiple-versions/7026

[jerith666]

I agree it'd be great to have jdk etc. point to 14 (and then 15 etc.); and introduce a jdk_lts that points to 11 (and then 17 (?) etc.).

I also agree that this is the right approach, to just do the rename and make sure it doesn't cause any rebuilds. Then we can gradually replace all the resulting jdk8s with jdk or jdk_lts as appropriate for the package.

Sadly I don't have much time right now to help with this effort, but if that changes I'll jump in as I can.

[doronbehar]

Thanks 💚 @gebner .

[gebner]

I wanted to do this as well because of https://discourse.nixos.org/t/remove-hardcoded-dependency-of-sbt-on-jdk8/9053

I've rebased this PR to master and evaluation almost passes. Many packages fail to evaluate because openjdk14.jre doesn't exist (adding it to passthru doesn't work either because there's no jre directory now...).

[doronbehar]

Many packages fail to evaluate because openjdk14.jre doesn't exist (adding it to passthru doesn't work either because there's no jre directory now...).

Now I remember why I stopped working on this - What bothered me even more then the attributes' names was that later jdk versions here in Nixpkgs weren't split packages.

Still the work you are putting is absolutely valuable.

[danieldk]

That's a wider discussion which should be done outside of this PR. As I've said, the jdk = jdk11 pattern is already widespread (also for other packages).

IMO, having the versioned package as an argument in the derivation really is a step backwards. It makes overriding much less intuitive. JREs are generally backwards compatible, so if you want a newer version, you have to write strange thing like:

myapp.override { jdk8 = jdk11; }

as oposed to

myapp.override { jdk = jdk11; }

Or if you want a newer CUDA version for some machine learning library (if we'd use the same pattern as here):

pytorch.override { cudatoolkit_10_1 = cudatoolkit_11; }

So, to override any Java derivation, one would first need to read it to discover what jdk version is used. What is even worse, if e.g. the default version is changed from jdk_8 to jdk_11, the overrides break for all downstream users.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/package-version-arguments-vs-generic-package-arguments/9071/1

[danieldk]

Discourse is probably a better place to discuss this, so opened a Discourse topic.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/remove-hardcoded-dependency-of-sbt-on-jdk8/9053/5

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/retirement-of-old-openjdk-releases/9929/8

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/package-version-arguments-vs-generic-package-arguments/9071/8