Hi Martin,
In case you have missed it, jdk/test/tools/launcher/BigJar.java
has a suppressed large file test, you might want to enable it
if not already done, I think this test originally came from google
not sure, nevertheless, a similar one also exists in:
langtools/test/tools/javac/file/zip/T6836682.java
As for the changes I glosssed over it, yea it is scary, but thanks for
making
the changes.
The Right Thing is to have only one C Zip implementation, shared by
launcher, zip_util, and pack200. And my change is one step towards that,
but I'm not tackling the big job right now.
+1.
Kumar
On Wed, Mar 25, 2015 at 10:55 AM, Xueming Shen <[email protected]>
wrote:
It looks fine...I hope you guys also have some tests over there to bring
in more confidence :-)
It might be "easier" to simply update the original haveZIP64() with the
code
we have in zip_util.c in which we also try to read the end64 to verify if
we
really have one. Your choice though.
-Sherman
On 03/25/2015 09:55 AM, Martin Buchholz wrote:
Yeah, this review is kinda scary. There's a lot of technical debt here,
and this change only addresses some of it.
A variant of this code is in use at Google.
On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <[email protected]>
wrote:
Hi Xueming and Alan,
I'd like you to do a code review.
https://bugs.openjdk.java.net/browse/JDK-8073158
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/
Of course, the really correct thing is to have at most one zip
implementation per programming language, but I'm not trying to fix that
here (how many zip implementations does openjdk have?)
