zip64 compatibility problems
peter.levart at gmail.com
Sat Feb 9 09:50:14 UTC 2013
On 02/07/2013 06:51 PM, Martin Buchholz wrote:
> On Thu, Feb 7, 2013 at 8:15 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
>> On 07/02/2013 01:55, Martin Buchholz wrote:
>>> Following up, please review the backward compatiblitiy support in:
>>> (ideally users would have even more control via the API, but I ain't gonna
>>> try to touch that)
>> No objection to adding a knob for this but do we need changes for reading
>> too? I'm just concerned that someone could use ZipOutputStream to create a
>> zip or JAR file that is not readable (in the same VM).
> Such zip files have always been readable by the JDK's (and other folks')
> zip implementations, so no changes should be needed (in theory). I've
> already fixed a case where the zip implementation in langtools regressed to
> not be able to read such files.
> That said, we could use more testing.
>> On the property name then we've started using jdk.* for JDK-specific
>> properties. Also as the default is to support ZIP64 when writing then maybe
>> this should have a disable* name so someone can specify
>> -Djdk.util.zip.disableZip64 on the command line without specifying a value.
> Can you point me at exemplar code for reading such a system property?
> Also, this does not disable ZIP64 - it only disables it when it is not
> needed (most other zip implementations can still read the output) "inhibit"
> seems better than "disable".
More information about the core-libs-dev