According to Claude:

The location within the JDK image is a committed upstream interface. OpenJDK explicitly defines src.zip (alongside things like jrt-fs.jar) as a file at a path intended for external use, contrasted with the contents of lib/ which are private implementation. So when you build OpenJDK, the build system produces src.zip as part of the standard image layout.

and:

It exists so that IDEs and debuggers can show you the actual source of, say, ArrayList.add() when you step into it or hit "Go to definition," instead of just decompiled bytecode or stub signatures. IDEs like Eclipse and IntelliJ pick it up from $JAVA_HOME and attach it as the source for the runtime classes, which is what makes "view source" work for JDK classes out of the box.

and:

There's nothing Nix-specific going on — removing it would actually be the unusual choice, and it would break IDE source navigation for anyone pointing their IDE at the Nix-built JDK. Some Linux distros do split it out into a separate -source package (as the Bazel issue above shows for Ubuntu), but Nixpkgs keeps the upstream layout intact.

If you're trying to slim down a closure and don't need IDE source attachment, you can drop it in a postInstall hook on an override, but for a general-purpose JDK package keeping it is the right default.

In reply to @msgilligan:matrix.org

If someone wants to work to make the JDK toolchain binary free, the place to start might be with Maven. It is currently:

    sourceProvenance = with lib.sourceTypes; [
      binaryBytecode
      binaryNativeCode
    ];

In reply to @pyrox:pyrox.dev
okay yeah, let's just not bother with dropping it since adding the option would trigger rebuilds fafaik

In reply to @pyrox:pyrox.dev
working on this now, we have to bootstrap from ant -> maven 3.3.9(last version that can be built with ant) -> hopefully just the latest maven version

https://github.com/NixOS/nixpkgs/pull/484741 rebuild-linux:1001-2500 🫠

yeah I was kinda floored by that too. :) But since temurin bootstraps OpenJDK, basically anything that uses Java is affected.

I took a look at a couple (gnome-shell and python-vlc) and both have plausible-seeming explanations (gnome-shell depends on libphonenumber, which apparently uses Java for some of its test cases; python-vlc depends on libbluray, and Java is part of the BluRay platform as I recall from some excited JavaOne announcement a couple decades ago :) ).

I could not find a plausible explanation for a third package I looked at, pylatex. But, I don't think there's a way around a mass-rebuild here.

It looks like the jextract build has been broken on Darwin for almost a year. Here's a fix:

• https://github.com/NixOS/nixpkgs/pull/519643

In this comment on a PR to update maven, Benedikt Ritter (britter) says:

a ton of seemingly unrelated packages are being rebuilt, because igraph (a C library for analysis of networks) depends on Apache FOP (an XML formatter) which is built with maven. igraph only requires FOP for building it's documentation but this dependency still has rippling effects, e.g. the python packages now have a transitive dependency to maven because of that.

I've been doing some investigation and think I have a fix.

It turns out that igraph is simply copying its DocBook source to it's doc output and is not running either the html or pdf CMake targets that render the documentation. So I want to make a PR to do the following:

1. Actually enable the rendering of the HTML documentation.
2. Remove the dependency on FOP.

This should stop a lot of rebuilds (especially in Python packages) based on fop <- maven <- jdk.