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