RFR(S): 8073497: Lazy conversion of ZipEntry time
Xueming Shen
xueming.shen at oracle.com
Thu Feb 26 16:45:35 UTC 2015
On 2/25/15 4:17 PM, Claes Redestad wrote:
>
>
> We could preserve precision by shifting the remaining milliseconds
> into the dostime field,
> since the DOS time will only use the 4 lower bytes:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/
>
> After I went through more extensive testing and verification I
> realized that narrowing
> dostime to an int and breaking this remainder hack out into a separate
> field would be
> possible without affecting ZipEntry footprint; arguably cleaner, but
> if this version is
> acceptable I would prefer not to.
>
> Going this way preserves precision across the entire input range of
> setTime, thus all tests
> I could find pass with this version; I've also expanded the
> TestExtraTime test to test both
> far ancient, far future and near future times to verify precision is
> preserved.
>
> I backpedaled on the getLastModifiedTime optimization to set the mtime
> field that Peter
> suggested since it would have the side-effect that the extra time
> field would be written
> after a call to this getter, which would be a bit too unexpected.
>
> Thanks!
>
> /Claes
Hi Claes,
It's a good idea! Given the upper half now covers that 2000 million
seconds, the "dostime" field
is no longer a real "dos time", just wonder if we can go a little
further. For example simply move
the bits for years/months/days/hours/minutes/seconds out (left) a little
more, 11(?) bits, to leave
the lower bits for the 2000 million seconds. The benefit is that the
upper bound is no longer needed.
We need a pair of package private set/getDostime() for ZIS, ZOS and ZF
to access though. Yes,
it costs a little left/right bit-shift when to set/get the dostime, but
it does not requires the
expensive j.u.Date/timezone.
-Sherman
More information about the core-libs-dev
mailing list