Rebuilding against a more precise JDK versions

[marko-bekhta]

I recently was trying to run the rebuild script check on a project released with JDK 17.0.12 while the rebuild script uses 17.0.14. I've ended up with:

-        throw new UnsupportedOperationException("UserType does not support reading CallableStatement parameter values: " + this.userType);
+        throw new UnsupportedOperationException("UserType does not support reading CallableStatement parameter values: " + String.valueOf((Object)this.userType));

so I was thinking, should there be a way to specify the JDK version more percise.

An implementation idea for this: for a project that has a maven/gradle wrapper we could leverage the simple JDK image instead of using maven/gradle ones, e.g. eclipse-temurin:17.0.14_7-jdk-alpine (or whatever is specified) This way we could lock the rebuilt to the exact JDK version.

[algomaster99]

There is support for building project with a precise JDK version. See

reproducible-central/content/io/jooby/jooby-3.0.5.buildspec

Line 10 in 0e16663

jdk=17.0.8

for example.

When you rebuild this buildspec, it would spawn an interactive subshell and then you can switch to JDK 17.0.12 and then run the maven command provided.

[marko-bekhta]

@algomaster99 thanks for the suggestion. But I don't think it plays nicely with the gradle rebuild, see:

reproducible-central/bin/includes/rebuildToolGradle.sh

Line 29 in 0e16663

jdkImage="docker.io/library/gradle:8-jdk${jdk}"

it uses the gradle images, and those do not have such granularity for JDK versions. So if a more precise version is specified ...

manifest for gradle:8-jdk17.0.12 not found

[algomaster99]

Uh okay. I am not sure about gradle rebuilds. I have not played with them as much 😅

[hboutemy]

yes, generated bytecode changed quite much in JDK 17.0.14: there is a clear split between "up to 17.0.13" and 17.0.14 (I hope 17.0.15 will generated like 17.0.14...)
in the past, this happened with JDK 8: there is same split in time, I just did not record the ranges.
The clearly known JDK difference is Azul Zulu JDK 8 vs any other vendor, as they back-ported hash algorithms from JDK 11 and it had an impact on CycloneDX Maven Plugin.

this is exceptional, hence why Reproducible Central intentionally did not record patch JDK requirements: this was a design decision I did from the start.
I added an option for Azul, as a way to support the Zulu 8 case: it did not break the design, just added a small "vendor prerequisite"

if you have an idea on how to configure in .buildspec and add related support in ./rebuild.sh without breaking the design, help welcome

[hboutemy]

lately, I have a few releases that require a precise JDK 21 release because of sealed classes: listing them here, as it's the same type of complexity for the rebuild engine = need sometimes to have a very precise env to re-create
= https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/jstach/ezkv/README.md
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/io/jstach/rainbowgum/README.md

FYI, to successfully rebuild, I could not use the container-based rebuild that happens on GHA, but rebuild in interactive mode on my own laptop, that permitted me to use sdkman to select a very precise JDK 21 patch version (I have many JDKs installed over time on my machine)

FYI, I also changed some time ago the way buildinfo files are generated by Reproducible Central: I now store details on the env of the build => 4a9bd3a
the price to pay is that this buildinfo file is not reproducible any more (or more precisely it is hard to reproduce because of the level of details), but removing details to get it reproducible was finally counter productive. What is expected to be stable is .buildcompare: the environment details of .buildinfo can vary from one rebuilder to another