In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
AdoptOpenJDK is a long-deprecated project, having been superceded by
Eclipse Temurin quite a while ago. Additionally, after running the
generate sources command, many of its subpackages fail to evaluate due
to missing binaries for versions the package expects. Because everything
provided by AdoptOpenJDK is either long-deprecated or also provided by
Temurin, its removal should not cause many problems.
By the same token, OpenJDK 12, 13, 14, 15, and 16 have also all been long
deemed EOL, and 13/14 are both actively broken and fail to build. These
packages, and their associated (and unnecessary) bootstrap chain are a
major factor in the tech debt of OpenJDK as an ecosystem in Nixpkgs.
OpenJDK 16 was the only user of OpenJFX 15, so it has also been removed.
By removing these packages, OpenJDK should hopefully be more
maintainable into the future.
as usual this is mostly copy-pasted from 18, so this commit is best
reviewed with '--find-copies-harder'
stop exposing openjdk 18 since it was not a long-term support release
change the default openjdk from 17 to 19 since nixpkgs is a
rolling-release repository
drop the ceremony around bootstrapping via adoptopenjdk for 64-bit
builds vs. via earlier openjdk builds for 32-bit, because, to be
frank, since we're using temurin now, it's not a simple copy-paste
job. :-/ if someone needs a 32-bit openjdk, that work can be done
separately.
JavaFX revs from 17 to 19; it looks like 18 was never packaged along
with JDK 18.
* the gradle invocation used to build JavaFX must still be done with
Java 18, as gradle does not yet support running itself on Java 19.
* a couple of patches need to be applied, since a new State enum was
introduced in the JDK that collides with one in JavaFX.
* the hash of the gradle dependencies has not changed, which is
surprising, but as far as I can tell correct.
One application (libreoffice) doesn't work with 19 yet, so pin it to
jdk 17 for now.
Co-authored-by: Mario Rodas <marsam@users.noreply.github.com>
`java-packages.nix` attempts to automatically decide which java to use
for bootstrapping. When this works, it works well. However when it
fails due to the user setting `config.allowNonSource=false` on a
non-x86 platform, the reported failure is extremely confusing and does
not mention the `NIXPKGS_ALLOW_NONSOURCE=1` option to proceed, or
that `allowNonSource` had anything to do with the eval failure.
Here's why this is happening:
Currently, `java-packages.nix` makes its detection choice based on
`adoptopenjdk.jdk-hotspot.meta.available`. If the user has set
`config.allowNonSource=false` then the `adoptopenjdk-bin` packages
will all report `_.meta.available==false`. If
`adoptopenjdk.jdk-hotspot.meta.available==false` then the detection
code will proceed to use `callPackage path args`, *even if that
package is **also** `meta.unavailable`* for end-user-unfixable
reasons.
In the case of `openjdk8`, the `path` passed is a `nix` expression
that only works on x86. The user has two options for continuing the
build: buy an x86 machine or add an `allowNonSource` exception for the
bootstrap jdk. The second option is generally preferred, but the user
is only offered the first option.
The following comment appears above the line in `java-packages.nix`
which does the automatic selection:
```
/* adoptopenjdk not available for i686, so fall back to our old builds for bootstrapping */
```
Since the intent here was to decide based on "i686-ness", let's query
the authoritative source for i686ness in nixpkgs: `stdenv.hostPlatform`.
This reduces the build closure size.
Reducing the build closure size reduces the number of rebuilds
across time and it helps with such tasks as bisecting the staging
branch.
