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
