I just tried another clean rebuild and jtreg on jar/zip and launcher tests with -ignore:run - no problems on Linux x86.
On Thu, Mar 26, 2015 at 7:49 AM, Kumar Srinivasan < [email protected]> wrote: > 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?) >>>> >>>> >>> >>> >
