RFR(S): 8073497: Lazy conversion of ZipEntry time

[Xueming Shen]

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