On Mon, Aug 21, 2017 at 6:35 PM, Xueming Shen <xueming.s...@oracle.com> wrote:
> > I have manually verified the change does fix the problem (either use the > jar tf or > java jdk.nio.zipfs.ZipInfo to check the offending zip file). Given the > nature of the > test case, I'm hesitated to add this test as a unit/regression into the > repo for now. > Testability is one of the serious problems with ZIP64, since even in 2017 it's still unreasonable to create 5GB files in a test. I think we should have a standard way to mark and optionally run expensive tests, as we do in j.u.concurrent with -Djsr166.expensiveTests=true. But we're not going to fix that here. There is one giant benefit of zip's annoying creation of a ZIP64 END header. It allows us to write tests that aren't too expensive (but they do rely on zip being available on the test machine). This command: echo hello | zip infozip.zip - creates a very small zip file with a ZIP64 END header. For bonus points, check that everything still works if you prepend some data, with or without running "zip -A" on it. We should do this.
