I wonder if it’s useful to stick to the old OpenJDK releases like 12, 13 and 14. From my understanding these releases are not supported anymore with updates once a new release is published. So I think we should:
Remove those versions non lts versions apart from the most recent.
Introduce an alias for java 8 (PREFIX-legacy-lts), java 11 (PREFIX-lts), java 15 (PREFIX)
I am against the removal of older JDKs due to the fact that they are still very much in use.
For example, the project that I am currently working on is built on Java 11 and Java 14. We may upgrade to Java 15 but it’s more of a “Maybe someday” kind of thing - and from my experience most companies’ views are similar.
You might as well think of this as a Python 2 / Python 3 situation.
What I would like to see is:
pkgs.jdk alias to always point to the latest JDK version (or latest LTS version, not sure which more makes more sense).
Currently, the alias is set like so:
20.03 - JDK8
20.09 - JDK8
Unstable - JDK14
I think I’m on the same page as @asbachb here. We should keep 8 and 11 around, but with explicit “LTS” labels so it’s clear that packages are depending on older versions. The default should roll as each 6-month release is created, and packages that depend on the jdk should generally depend on it. If a particular 6-month release is found to break a particular package, that package can be fixed by explicitly depending on the LTS release that’ll still be in nixpkgs.
Also, pkgs.apache-maven uses pkgs.jdk.
If it would be Java 15 or 11, maven build hook will use Java 15 to build .jars.
And those jars will require at least Java 15 to run.
Moving pkgs.jdk from the oldest jdk to the newest one might break other build tools (and probably IDEs) as well, because jars have only backward compatibility: old jars can be run on new JDK, but not the other way around.
In my experience most libraries support ‘at least jdk8’ while making sure they also work fine with later versions. I don’t think it is all that commonly the case that software does not run on later versions (though indeed it happens, and IMHO those are bugs worth fixing).
Well, the module system is optional and for many libraries there just isn’t that much motivation to support it.
I’m not sure, I rather like the approach of “latest release by default, specify a particular version if you have special requirements”.
I added https://github.com/NixOS/nixpkgs/pull/98383 so it is easy to generate bespoke jlink’ed JRE’s that are ‘minimal’ for your use case. However, I think in nixpkgs we should still just depend on the ‘full’ JRE. The reason is when you have one tool that needs modules A+B, one that needs modules B+C, and one that only needs module A, you don’t want to install 3 JRE’s - you just want one JRE with A+B+C. So having a JRE with all modules enabled, and an easy way to replace it with a bespoke jlink’ed one (like we have right now) seems like the best solution to me.
If we really want to make tools lean, we should compile them into a native image with graal/substratevm instead.
Almost all software will specify -release 8 (or -target 1.8, though that is not entirely safe) in their build to target JDK8, so they produce jars that require only Java8 to run (even when built with a newer JDK).
It would nice to generate a “Full JRE” for JDK11 for when you want to run non-module setup applications.
At the moment I’m forced to either install the JDK itself which is too large of a transitive dependency or hand-build the minimalJRE.
A “FullJRE” for JDK11 would be a welcomed addition
As a developer, it is often convenient to have access to more JDK’s than just the couple of variations and versions shipped by a typical distro. Outside of nix, tools like sdkman or jabba are often used for that - but that is not very nix-like.
Perhaps it would be neat to provide a ‘nix-like’ way of fetching those binary JDK packages. One way would be to provide derivations for the collection of JDK’s included in jabba, for example like this: