On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
> Can I please get a review of this change in the JDK build tool class > `CreateSymbols` which addresses an issue related to the reproducibility of > the generated `ct.sym` file? This addresses > https://bugs.openjdk.org/browse/JDK-8327466. > > Even before this change, in order to support reproducibility of the generated > ct.sym file, this internal `CreateSymbols` program takes a `timestamp` > argument. The value for the `timestamp` is considered to be the number of > seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct > that's used by several tools (even outside the JDK) to provide reproducible > output. > > The ct.sym file generated by the `CreateSymbols` program is a ZIP file. > `CreateSymbols` uses the passed `timestamp` value to set the last modified > time on each of the ZIP entries of the generated ZIP file. That way, a > constant value for the `timestamp` argument implies that without anything > else having changed for a subsequent build, the subsequently generated ct.sym > will also have the exact same value for the timestamp for each of the ZIP > entries. > > Like many other things in the ZIP specification, a timestamp for a ZIP entry > can be set in more than one place within the ZIP structure and the value thus > set can be interpreted differently depending on where it is set. That also > results in Java SE's `java.util.zip` APIs having more than one way of setting > that timestamp. > > The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` > API to set this timestamp on the entry. However, that API is specified to be > affected by the local system default timezone. This effectively means that if > `CreateSymbols` is triggered more than once with the same `timestamp` value > but with a different timezone, then the generated ct.sym files from each run > will have a different value for the ZIP entry timestamps. This defeats the > purpose of the `timestamp` agrument. > > The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` > which isn't affected by the local system timezone. This API was introduced in > Java 9 to solve issues like this. The decade old original RFR, when this API > was introduced, does a very good job of explaining the necessity of this API > and how it differs from the `setTime(...)` method > https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html. > > The commit in this PR also introduces a regression test which reproduces the > issue and verifies the fix. > > I have run this change in tier1 and tier5 and this and other tests co... Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25207#pullrequestreview-2836670871
