RFR: 8015666: test/tools/pack200/TimeStamp.java failing

[Alan Bateman]

On 20/06/2013 19:48, Xueming Shen wrote:
> :
>
> I'm proposing the following approach to add the functionality of 
> supporting
> the "utc-date/time-with-1-second granularity" and keep the old behavior
> of the get/setTime() of the ZipEntry.
>
> (1) keep the time/setTime()/getTime() for the MS-DOS standard date/time.
>      To set via the old setTime() will only store the time into zip's 
> standard
>      date/time field, which is in MS-DOS date/time. And getTime() only 
> returns
>      the date/time from that field, when read from the zip file/stream.
> (2) add mtime/set/getLastModifiedTime() to work on the UTC time fields,
>      and the last modified time set via the new method will also set 
> the "time",
>      and the getLastModifiedTime() also returns the "time", if the UTC 
> time
>      stamp fields are not set in the zip file header. The idea is that 
> for the new
>      application, the recommendation is to use 
> ZipEntry.set/getLastModifiedTime()
>      for better/correct time stamp, but the existing apps keep the 
> same behavior.
> (3) jar and ZipOutputStream are updated to use the 
> set/getLastModifiedTime().
> (4) Pack/unpack continues to use the set/getTime(), so the current 
> workaround
>      continues work. I will leave this to Kuma to decide how it should 
> be handled
>      going forward. (there are two facts need to be considered here, 
> a) the
>      existing jar file might not have the utc time instored, and b) 
> all "extra" data
>      are wiped out during the pack/unpacking process)
> (5) additionally add another pair of atime/get/setLastAccessTime and
>      ctime/get/setCreationTime().
> (6) The newly added 3 pairs of the m/a/ctime get/set methods use the 
> "new"
>      nio FileTime, instead of the "long". This may add some additional 
> cost of
>      conversion when working with them, but may also help improve the
>      performance if the time stamps are directly from nio  file system 
> when
>      get/set XYZTime. Good/bad?
>
> http://cr.openjdk.java.net/~sherman/8015666/webrev/
>
> Comment, option and suggestion are appreciated.
At a high-level this looks a reasonable approach. An alternative would 
be to define an API over the extra block but I don't think we want to go 
there.

For consistency you might consider setTime setting mtime to null, 
otherwise the ordering when both setXXX methods are used is significant. 
Another thing to consider is whether the "parsing" of the extra block 
could be changed to being lazy now as it's only interesting when someone 
asks for it or the higher precision time stamps. Thinking back to the 
original changes then I wonder if we discussed the UNIX extra field, 
maybe you said that Windows tools can't handle such zip files?

A possible concern is that the footprint of ZipEntry increases. We could 
eliminate this increase if the new methods operated on the extra block. 
There's a clearly a trade-off here.

I spotted one or two "modificatin" in the javadoc, but I'll make time to 
do a proof-read the javadoc once the approach is agreed.

-Alan.