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 continue to 
pass.

-------------

Commit messages:
 - 8327466: ct.sym zip not reproducible across build environment timezones

Changes: https://git.openjdk.org/jdk/pull/25207/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327466
  Stats: 186 lines in 2 files changed: 180 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25207/head:pull/25207

PR: https://git.openjdk.org/jdk/pull/25207

Reply via email to