RFR: 8327466: ct.sym zip not reproducible across build environment timezones

[Erik Joelsson]

On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai <jpai at 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