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".
