Is there a reason why this was changed? It breaks the pattern with all of the other JDK builders, so it seems a bit out of place to change it in just 1 place. Same with the other references to the bootstrap JDK.

Probably I should have done it on a following PR.
The main reason is to unify the arguments to mkOpenJdk and create a more generic function in the future. There is a lot of duplication between the 22.nix, 21.nix, etc. files.

It also makes it more consistent with the openjfx argument. In my opinion, we should do this:

    openjdk22 = mkOpenjdk
      {
        jdk-bootstrap = temurin-bin.jdk-21;
        openjfx = openjfx22;
      };

or this:

    openjdk22 = mkOpenjdk
      {
        openjdk22-bootstrap = temurin-bin.jdk-21;
        openjdk22-openjfx = openjfx22;
      };

@jlesquembre regarding this change jdk-bootstrap rename, a quick git grep openjdk22-bootstrap showed me this:

pkgs/development/compilers/openjdk/22.nix:, openjdk22-bootstrap
pkgs/development/compilers/openjdk/22.nix:  openjdk-bootstrap = openjdk22-bootstrap.override { gtkSupport = !headless; };

So, won't it break what's in 22.nix and 21.nix?

I just undid that change

Is there a particular reason why the updater is not written in bash or python other than dog fooding?

It makes it a lot harder for general contributions to use it.

Two reasons:

• The update script uses https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.Version.html to parse and compare versions. It makes more sense to reuse that instead of re-implementing that logic on other languages, particularly since the Java version schema could be more complex than expected: https://openjdk.org/jeps/223
• I expect Java developers to be more interested in maintaining the updater script. I think it's fair to write the script in a language more familiar to them.

@jlesquembre regarding this change jdk-bootstrap rename, a quick git grep openjdk22-bootstrap showed me this:

pkgs/development/compilers/openjdk/22.nix:, openjdk22-bootstrap
pkgs/development/compilers/openjdk/22.nix:  openjdk-bootstrap = openjdk22-bootstrap.override { gtkSupport = !headless; };

So, won't it break what's in 22.nix and 21.nix?

These should be kept, as they are used for marking the version.
From The Temurin build wiki, about versions in build configuration:

But when you build something that is fit for others to consume, you will still want to provide a build number with --with-build-number, use -with-version-pre="" if you want to say it is an actual release (use e.g. "ea", or just leave blank to make it "internal" otherwise), and in addition set --with-version-opt to control that thing that defaults to "adhoc.$USERNAME.$basedirname".

I replaced it with --with-version-string=${version}, where the version value is the git tag.
Notice that --with-version-XX= overwrites the value set by --with-version-string.

Currently java --version returns:

openjdk 22-ga 2024-03-19
OpenJDK Runtime Environment (build 22-ga)
OpenJDK 64-Bit Server VM (build 22-ga, mixed mode, sharing)

If we add those 2 flags again (version-opt and version-pre) the output becomes::

openjdk 22 2024-03-19
OpenJDK Runtime Environment (build 22+-nixos)
OpenJDK 64-Bit Server VM (build 22+-nixos, mixed mode, sharing)

In my opinion, the first one makes the JDK version much clearer.

Looking at the link you posted, seems that what we should use is --with-vendor-version-string , but that option isn't mentioned here: https://openjdk.org/groups/build/doc/building.html

Hmm, ideally we would still include the vendor information if possible, especially since we do patch OpenJDK for building on Nixpkgs. I do agree that it is much more clear though. Have you tested if --with-vendor-version-string works? (Finishing up a course so I haven't done so myself yet.)

with --with-vendor-version-string=${version}_nix-build:

openjdk 22-ga 2024-03-19
OpenJDK Runtime Environment 22-ga_nix-build (build 22-ga)
OpenJDK 64-Bit Server VM 22-ga_nix-build (build 22-ga, mixed mode, sharing)

Probably it is a good idea to add --with-vendor-version-string. What value makes sense to you? I like ${version}_nix-build, but I don't have a strong preference.

vendor-version-string is defined here:
https://github.com/openjdk/jdk/blob/6968770b1e918c74fc009e3562a827bb4acbe2d7/make/autoconf/jdk-version.m4#L488-L502

As a side note regarding the OpenJDK patches on nixpkgs, I think that some are not necessary for newer JDK versions. I'll open new PRs to remove them.

Probably it is a good idea to add --with-vendor-version-string. What value makes sense to you? I like ${version}_nix-build, but I don't have a strong preference.

I too don't have a strong preference, but I think the 22-ga is mentioned too many times if you'd use ${version} there too, so I'd vote for --with-veondor-version-string="(nix)".

"--with-vendor-version-string=(nix)":

openjdk 22-ga 2024-03-19
OpenJDK Runtime Environment (nix) (build 22-ga)
OpenJDK 64-Bit Server VM (nix) (build 22-ga, mixed mode, sharing)

@doronbehar makes sense, changing my vote to (nix), I like it more :)
Let's wait for @Infinidoge vote

It feels like it displays a little bit weirdly, with (nix) before the version, etc. But that's less of our problem and more of OpenJDK's problem. Looks good to me!

done, added "--with-vendor-version-string=(nix)"