On 6/21/13 6:33 AM, Alan Bateman wrote:
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 do have a version that set/getXYZTime() on extra data...but given the
expectation is
the new methods will be recommended in new code shift away from the dos
time, so
the extra will take some footprint of ZE as well...but yes, it may have
the benefit of
saving at least the a/ctime, which normally people don't care. Another
footprint concern
is the minimum 18 bytes increase (for mtime alone, in 9 for loc and 9
for cen) for each
file in jar file, in case of rt.jar, it is relatively a big increase. A
possible solution is to
have explicit API for ZOS and explicit command option for jar command to
"turn" this
one explicitly by developer/user, instead of the default. Or, as an
alternative to have
some mechanism to turn them off, if the size increase is not desired.
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.
