On 02/07/2013 06:51 PM, Martin Buchholz wrote:
On Thu, Feb 7, 2013 at 8:15 AM, Alan Bateman <alan.bate...@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
