Hi Claes,
This change basically undo the "fix" for 4759491 [1], for better
performance ...
If we go with this change, I think we should also update the field
comment back to the
original one to clearly indicates the "time" is "in DOS time".
- long time = -1; // modification time (in DOS time)
+ long mtime = -1; // last modification time
The set/getLastModifiedTime() pair also need update to set/get the
"time" field
correctly to/from the dos time.
-Sherman
[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90df6756406f
On 2/21/15 6:34 AM, Claes Redestad wrote:
Hi all,
please review this patch to re-introduce laziness in the java-to-dos time
conversions for the ZipEntry.time field.
Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8073497
See bug for more details.
This behavior was actually the case before 8-b94, when the time field
was removed in favor of a set of FileTime fields, but when it was later
re-introduced to address some compatibility issues the conversion was
implemented in an eager fashion. This inadvertently affects VM startup
ever so little, since for every entry read via a ZipFile or
ZipInputStream
we'll do a relatively expensive call creating a Date and doing timezone
conversion.
Some gains from loading fewer classes during VM startup, as well.
Thanks!
/Claes
