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:
Any other thoughts on this?
Nixos as a rolling release, doesn’t have any notion of Long Term Support as far as i’m aware… So it seems that as soon as the new release is out, everyone can upgrade.
This is probably due to eye’s on deck and people power rather any technical reason…
Unless there is a LTS for nixos somewhere?
@asbachb is referring to OpenJDK LTS versions:
http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001833.html
Ah i see! sorry for the confusion.
- Remove those versions non lts versions apart from the most recent.
In favour 
- Introduce an alias for java 8 (PREFIX-legacy-lts), java 11 (PREFIX-lts), java 15 (PREFIX)
I’m not sure I see the need for those
Let me share my thoughts:
Java 11 introduced some breaking changes. So there some projects relying on java 8. In general applications are supported to run under the last lts version, but not the last java version released.
Hey guys, I created an account just for this 
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).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.
We discussed this approach in:
15 or 11 as default pkgs.jdk will have issues being unable to run all Java-written apps in nixpkgs. Java world is full of legacy.Yes.
Java8 in my experience still widely used.
Just look at all the third party libraries and how few publish module info!
Tools should be more explicit though on using a versioned JDK rather the default jdk
I’m also still sad there’s no small JRE for JDK11 for tools.
I just had another thougt. The recommendation to build a versions jdk from source is to use previous jdk for conpilation.
@fzakaria for tools you should generate your own jre with jlink.
Should a complete jlink JRE be pre-provided to mimic jdk8 JRE?
There are a lot of tools that just expect the runtime to be present, I’d like to migrate them at least to Java 11.
I know @doronbehar submitted a patch for a minimal jre but maybe a “complete” one is also useful.
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.
I don’t think there’s too much of a cost to keeping the older jdk’s around, it’s not like python where we have massive package sets related to them; usually there’s just some downstream applications.
Even if they have security vulnerabilities, we can just mark them as vulnerable.
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 openjdk: add derivation to generate bespoke minimal JRE's by raboof · Pull Request #98383 · NixOS/nixpkgs · GitHub 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).
That means extra work to examine all Java software and add patches to build scripts if needed
Sorry I don’t think I explained myself well.
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:
https://github.com/NixOS/nixpkgs/pull/105924
That might reduce the need to include ‘proper’ built-from-source nix packages for (for example) older non-LTS releases, while still making them easily available for those who need them.
I wonder if the current situation makes sense: jdk points to jdk16 which is hardly unsupported as it’s not an LTS release. So many java programs needs an override for 11 or 8.