Some applications, like the Jetbrains IDEs, check for a suffix to
determine if a stable JDK is used.
This flag was already passed for older versions, but it got lost for
OpenJDK 14+.
* update two explicit references to jdk14 to just jdk, which no longer
points at jdk8 after #89731.
* patch an explicit -XX:+UseConcMarkSweepGC to -XX:UseG1GC, as the
former now throws an error (after having been deprecated since jdk 9)
* some configure options have been removed upstream
* need a new patch to deal with gcc format warnings
11 remains, as it is an LTS release; all existing users of 11 in
nixpkgs remain on 11 for now.
openjdk/default.nix and openjdk/darwin/default.nix become the
expressions for the current version (12 now; later 13, 14, etc.).
(note: darwin/default.nix was unreferenced; the new version is derived
from darwin/11.nix.)
This small patch makes it possible to control java's truststore path through
the environment. This lets you add (system- or session-wide) CAs that should
be allowed by Java. Java users can still use -Djavax.net.ssl.truststore to
override the truststore set by JAVAX_NET_SSL_TRUSTSTORE.
Something like this can be used to build the truststore (in this example just
using the standard pkgs.cacert CA-bundle):
{
environment.variables.JAVAX_NET_SSL_TRUSTSTORE = "${
pkgs.runCommand "cacerts" {} ''
${pkgs.perl}/bin/perl \
${pkgs.path}/pkgs/development/compilers/openjdk/generate-cacerts.pl \
${pkgs.jre}/bin/keytool \
${pkgs.cacert}/etc/ca-bundle.crt
mv cacerts $out
''
}";
}
Ideally, the dependency on pkgs.cacert should also be removed from pkgs.openjdk
to avoid rebuilding java each time the standard CA-bundle changes. Something
along the example above must then be added to NixOS (however, it would be
nice to not depend on ${pkgs.jre}/bin/keytool to generate that environment
variable).
HotSpot uses the absolute path of libjvm.so to determine the java.home
property (ignoring $JAVA_HOME), which is in turn used by
ToolProvider.getSystemJavaCompiler() to load tools.jar. So we need to
do some trickery to ensure that if java gets invoked from the jdk
output (ratherthan the jre output), it finds libjvm.so in the jdk output.
This unifies the "openjdk" and "openjre" packages. The JDK is placed
in the "out" output, the JRE in "jre".
Also, everything is now stored in $prefix/lib/openjdk, so the JDK/JRE
no longer pollute user environments with files like
"ASSEMBLY_EXCEPTION" at top-level.
