Thanks for the review. webrev has been updated accordingly. Do CCC next
week.
-Sherman
Martin Buchholz wrote:
On Fri, May 14, 2010 at 23:53, Xueming Shen <xueming.s...@oracle.com> wrote:
OK, Thanks!
btw, did you ask this before?
http://cr.openjdk.java.net/~sherman/6581715/webrev/
I think I did. All JDK classes returning an Enumeration
should be retrofitted to implement Iterable.
Looks good.
---
There are a few more places where you can remove
ZipFile.this.
507 ",\n jzfile = " + ZipFile.this.jzfile +
508 ",\n total = " + ZipFile.this.total +
509 ",\n name = " + ZipFile.this.name +
Martin
-Sherman
Martin Buchholz wrote:
On Fri, May 14, 2010 at 19:24, Xueming Shen <xueming.s...@oracle.com>
wrote:
Martin Buchholz wrote:
Well, the obvious thing to do is to use ZipFile,
and if something goes wrong,
back off and try the old implementation with
ZipInputStream in addition.
I will add a check like
if (fname != null && new File(fname).length() < 0x100000000L)
go ZipFile;
else
go ZipInputStream
Sounds good.
hmmm....
If the input zip file is actually a ZIP64 file for some other reason
(for example to get >64k entries), then ZipInputStream
will still succeed, while ZipFile will probably fail,
in which case the fallback algorithm might be more robust.
But I am happy with any action on your part,
including doing nothing.
If the JDK has ZIP64 support,
what goes wrong?
Nothing goes wrong with ZIP64, but we don't have that in 6u (yet)
Oh, right. And a backport of ZIP64 support probably isn't
worth the risk and effort.
Martin
-Sherman
Martin
On Fri, May 14, 2010 at 16:18, Xueming Shen <xueming.s...@oracle.com>
wrote:
It appears the backport to 6u of the optimization we did in #6332094
breaks
someone's code.
Obviously the ZipInputStream works fine with >4G zipfile even without
the
ZIP64 format support
as long as the individual zip entries inside is smaller than the 4G
limit,
so the sequential reading in jar's
old implementation just works "fine" with the >4G zip. But the
optimization
we put in to use ZipFile
instead causes the regression because it needs the access to the 64bit
central directory table if the
zip is > 4G. While it is arguable if a > 4G zipfile without the ZIP64
extension table is a "correctly"
formatted zip file or in fact that jar can never create a > 4G zip file
before we added the ZIP64
support, regression is a regression:-(
I believe you also backport the same thing into 6open.
-Sherman
