RFR(S): 8073497: Lazy conversion of ZipEntry time
xueming.shen at oracle.com
Sat Feb 21 18:49:48 UTC 2015
This change basically undo the "fix" for 4759491 , for better
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
correctly to/from the dos time.
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
> we'll do a relatively expensive call creating a Date and doing timezone
> Some gains from loading fewer classes during VM startup, as well.
More information about the core-libs-dev