zip64 compatibility problems

Peter Levart 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:
>>>
>>> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**
>>> useZip64For64kEntries/<http://cr.openjdk.java.net/~martin/webrevs/openjdk8/useZip64For64kEntries/>
>>>
>>> (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".

disfavor ?

Regards, Peter




More information about the core-libs-dev mailing list