Ah, I suspect the getTime() for xdostime performance issue relates to this:
https://bugs.openjdk.java.net/browse/JDK-4981560
which is not relevant any more since dosToJavaTime() is now implemented
differently
On Tue, Nov 30, 2021 at 2:44 PM Andrew Leonard wrote:
> Thanks Alan,
> Having tried
Thanks Alan,
Having tried implementing a Zoned option, I agree it does seem to bloat
ZipEntry a bit.
As JohnN's suggestion pointed out we could at some point move to always
setting the extended
mtime(FileTime), but we have 78years until we really need to worry about
that! (xdostime covers to 2099)
On 29/11/2021 19:25, Andrew Leonard wrote:
*Problem:*
PRhttps://github.com/openjdk/jdk/pull/6481
addresses the main problems with deterministic timestamping of Zip entries,
with
the introduction of a new --date option for jar & jmod.
However, the ZipEntry timestamp is constructed from a combinat
Given an API-change is not realistic at this point in jdk-18, would it
make more sense to implement solution (1), and consider (2) for jdk-19+.. ?
*Problem:*
PR https://github.com/openjdk/jdk/pull/6481
addresses the main problems with deterministic timestamping of Zip entries,
with
the introduction of a new --date option for jar & jmod.
However, the ZipEntry timestamp is constructed from a combination of an
MS-DOS timestamp
and a FileTime(se
