RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v12]

[Andrew Leonard]

On Wed, 1 Dec 2021 01:37:55 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276766: Enable jar and jmod to produce deterministic timestamped content
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> I found it helpful to look at what others have done.
> 
> The Debian `strip-nondeterminism` tool clamps the low end of the date to `1980-01-01T12:01:00`. All other dates are permitted no matter the consequence. That tool is written in Perl and is able to access all of the timestamp fields individually. See the [`zip.pm` file][1] for details.
> 
> Gradle decided that the only permissible date is `1980-02-01T00:00:00` in the default time zone of the JVM. Period. End of story. No customization at all. [They use a trick][2] with the old `GregorianCalendar` class to counteract the effect in `ZipEntry.setTime` of the default time zone. They use the `org.apache.tools.zip.ZipEntry` subclass of `java.util.zip.ZipEntry`, but many methods pass through to the super class. See the [`ZipCopyAction.java` file][3] for details.
> 
> The crux of our problem, as Andrew made more clear to me, is that the methods of `ZipEntry` do not allow for independent access to the two fields: the "DOS date/time" field and the "UT extra field modtime". When trying to set either one of them, the `ZipEntry` class can overwrite the other using the default time zone of the JVM.
> 
> @andrew-m-leonard So I agree. Either document that the archives are reproducible only within a certain range of dates, or disallow the dates that are out of range. Then we should be good for at least the next 78 years.
> 
> [1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/blob/master/lib/File/StripNondeterminism/handlers/zip.pm#L40
> [2]: https://github.com/gradle/gradle/issues/12895#issuecomment-618850095
> [3]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John for you test program, i've been using your previous version which is similar.
So please can you review the latest commit, it basically follows the same method of your test program using a ZonedDateTime instant from the input --date converted to a LocalDateTime of the same Instant in UTC, and then passed to e.setTimeLocal(ldt)
It also only allows --date in the local date range of 1980->2099

Here's a manual test from 2 timezones of this latest commit:

~/workspace/repbuild$ sudo timedatectl set-timezone GMT
~/workspace/repbuild$ jar --create --date="2021-01-06T14:36:00+02:00" --file=myjar1.jar Time.*
~/workspace/repbuild$ sudo timedatectl set-timezone EST
~/workspace/repbuild$ jar --create --date="2021-01-06T14:36:00+02:00" --file=myjar2.jar Time.*
~/workspace/repbuild$ zipinfo -v myjar1.jar | grep -e Archive -e modified
Archive:  myjar1.jar
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
~/workspace/repbuild$ zipinfo -v myjar2.jar | grep -e Archive -e modified
Archive:  myjar2.jar
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00


I have also added reproducible jar tests across timezones.
thanks

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

PR: https://git.openjdk.java.net/jdk/pull/6481