This removes OpenJDK 11 entirely? Isn't that the latest LTS version? I think it would be nice to have it available until the next LTS.

It does remove 11 and move all packages that used 11 forward to 12, yeah. I think this is where we ought to be heading ...

Oracle has been pretty clear in their communications that the recommended path is to move onto each new 6-month release as quickly as possible. I view the LTS releases as targeted at risk-averse corporate users, who've got the time to invest in big migration projects every 3-4 years (for each LTS release). I don't think nixpkgs is either that risk-averse or able to make those periodic large investments. :)

I think the goal ought to be that pkgs.jdk & pkgs.openjdk refer to the latest release, and that most other packages in nixpgks that use Java should refer to these. (I've started down that route, but it's tedious and I didn't want it to block getting 12 out there.)

This way everything by default stays on latest. We can keep the newest LTS (and, sadly, probably 8 as well) around for those who need it, but our goal should be everything in nixpkgs uses the latest.

That said, those are longer term goals; if it's simpler for now to just add 12 alongside 11, and not move any of the dependencies forward in this PR, I'm happy to do that and tackle the rest in separate PRs.

Thanks for the reviews!

I haven't done any RFCs yet, will have to read up on that process first. But for now, I've pushed a more modest version that just adds 12 alongside 11. :)

As a Java developer that writes code for risk-averse corporate users I appreciate the availability of Java 11. I'm still mainly using Java 8 😀

I'm ok with the "default packages" (like jdk and openjdk) to point to the latest version like 12.

@jerith666 Thanks for working on these Java improvements!

I also am of the opinion we should keep the LTS version of Java. Ideally, I think we would always have exactly two versions, and no more:

• The current latest LTS version, always bumped as quickly as possible when a new major LTS comes out. This would currently be JDK 11 (and in the future, we would move to, uh, JDK 14 I guess, when that happens?)
• The latest release of the JDK, no matter what it is. In this case, it would currently be JDK 12.

Occasionally, these two releases would coincide, for the 6 months following a new LTS release. (Whether or not jdk and openjdk pointed to the first one or second one is a matter of debate, I think, but I believe the above rule could be discussed beyond that.)

The main nice thing about this I think is that the release cadence of Nix and Java isn't always going to align. If the policy is we immediately stop supporting things after 6 months, and the NixOS release cycle is 6 months, then you will often reach situations where you have an EOL version of the JDK mid-release. Then, that version gets no more backports (for example, you may leave a multi-month window open with a security vulnerability). At least with a stable LTS version, users can be certain that they will have a package that won't be EOL'd mid release, and will also exist between Nixpkgs releases. I think this is valuable and not at all uncommon (several packages we ship have the stable/latest distinction such as this, and effectively follow this exact policy already).

Regarding Oracle's support policy, their new policy is effectively to gate patches to JDK versions after 6 months, which is unfortunate. But the thing is, LTS versions of the JDK generally have wide support among the community, for example by Red Hat and IBM. It is very likely for instance that JDK 11 will see many community patches over time, even if Oracle steps away after a set period. So I think we aren't taking a huge risk by keeping them around.

There are also other complications with our packaging. For example, what is Zulu doing here? It's really just the Azul-branded/supported version of OpenJDK, there is no actual meaningful technical difference -- but there are Nix packaging distinctions between the two that mean Zulu works in some places OpenJDK does not. Ideally we would fix these issues and get rid of Zulu as well, to keep the overhead lower.

There are also some other things I'd like to see but can't recall off the top of my head right now, like a new update of the bootstrap tarballs (since they're on JDK 10 which has been nuked), but that's another story...

And, actually, I would actually also like to even go as far as removing Java 8 (gasp) and replacing it everywhere with Java 11 in Nixpkgs. We could keep JDK8 around in something like NUR for people who really need it.

There's another benefit to this other than less version maintenance: by doing this, we could also perhaps finally destroy the oraclejdk expressions -- for JDK 8, they had feature differences that distinguished them and made the Oracle package a requirement for some things. But, as of JDK 11 there are no actual feature differences between the two, so all uses of OracleJDK in our expressions can hopefully be replaced by OpenJDK, providing we could fix a few packaging issues. This would allow us to remove a bunch of extra crud and get rid of a common proprietary Nix package.

EDIT: I believe there actually is still one distinction between OpenJDK and OracleJDK: OracleJDK supports and ships JavaCard support (Java 5), which some Nix users have expressed interest in maintaining. However, 1) this is not actually a dependency of any of our actual packages, it is a thing (some) users use themselves, and 2) even then, I truly do not believe this is a significant enough portion of the userbase to justify keeping the Oracle JDK expressions around, or at least inside the main Nix tree. If JavaCard/JDK8/OracleJDK is really desired, I think it should be maintained somewhere such as NUR.

I think doing all this would vastly reduce the necessary maintenance burden for various packages and largely cut down on confusion for users (it's honestly confusing to me why we have all these things!)

A fast google indicates there's some active amount of upstream work on both of those issues. But in general I think the thrust of my point stands: 2 major shipped versions (LTS/latest), and we should make progress towards eliminating the (somewhat absurd) proliferation of JDK/Java packages.

Okay, I've put in three workdays with Eclipse on top of this, no major issues have cropped up. Has anyone had a chance to test darwin?

Conflict is with #63574, so cc @abbradar, @jb55, @risicle, @edwtjo. Textually it's minor, but conceptually I think I need to re-cut-n-paste 12.nix to pick up the changes made to 11.nix.

I've incorporated the OpenJFX work from #63574 now. Next, I'll update to 12.0.2, which was recently released.

Works for me. AFAICT all objections have been addressed. The question of what LTS releases we should keep in nixpkgs should be discussed somewhere else. I'll merge this later today unless anybody complains.

@volth The build works on ofborg as well (it hits the point where you got the error before the timeout). I'll merge it, let's see what hydra says. Even if it fails, it shouldn't break anything since nothing depends on openjdk12 yet.