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