http://javaweb.sfbay.sun.com/~sherman/6332094/

Xueming Shen xueming.shen at oracle.com
Fri May 14 23:18:47 UTC 2010


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



More information about the core-libs-dev mailing list