On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleon...@openjdk.org> wrote:
>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod >> to allow specification of time to use for created/updated jar/jmod entries. >> This then allows the ability to make the content deterministic. >> >> Signed-off-by: Andrew Leonard <anleo...@redhat.com> > > Andrew Leonard has updated the pull request incrementally with two additional > commits since the last revision: > > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard <anleo...@redhat.com> > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard <anleo...@redhat.com> However, it looks like this behavior to not set extended mtime within the xdostime range has just been changed by a recent PR: https://github.com/openjdk/jdk/pull/5486/files which has changed jartool.Main using zipEntry.setTime(time) to use zipEntry.setLastModifiedTime(time), the later sets mtime always regardless of xdostime. The implications of https://bugs.openjdk.java.net/browse/JDK-8073497 might also apply to FileTime unnecessary initialization slowing VM startup, however if FileTime is already regularly referenced during startup, then it wont.. If this is the case then way forward (1) would be ok... @AlanBateman was that an intentional change? @jaikiran ------------- PR: https://git.openjdk.java.net/jdk/pull/6481
