RFR: 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible

Alan Bateman Alan.Bateman at oracle.com
Fri Nov 5 07:23:40 UTC 2021


On 04/11/2021 21:16, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>    - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>    - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>    - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>
I think this is going to require discussion, a PR may be too premature. 
Is your goal to get the JDK build and run-time images creates with jlink 
to use the SOURCE_DATE_EPOCH? Are you looking for project builds that 
use the jar/jmod/etc. tools to use it? Or are you looking to have every 
library and application that uses the java.util.zip APIs to read it? If 
it includes the latter, and the patch in the PR suggests you are, then 
it will require analysis to work through the API spec changes.

One suggestion is to look at JDK-8231640 and PR 5372 [1]. The original 
proposal was to use SOURCE_DATE_EPOCH. After a lengthy discussion we 
converged on the system property java.properties.date rather than the 
env variable. I suspect that much of that discussion applies here.

-Alan

[1] https://github.com/openjdk/jdk/pull/5372


More information about the compiler-dev mailing list