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

[Peter Levart]

On 02/26/2015 01:17 AM, 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,

I like the backwards-compatible extended DOS time format idea. If you 
keep it as one field, you could move the code for conversion from 
millisecond Java time to/from extended DOS time format to the ZipUtils 
methods entirely (javaToXdosTime, xdosToJavaTime) to make logic in 
ZipEntry simpler. I would call the field 'xdostime' then to hint the 
reader about the format which would be nice if it was described in a 
javadoc on the field.

Regards, Peter