javac doesn't work with jar files with >64k entries

[Martin Buchholz]

On Wed, Nov 7, 2012 at 6:13 PM, Kumar Srinivasan <
kumar.x.srinivasan at oracle.com> wrote:

>  On 11/7/2012 5:38 PM, Martin Buchholz wrote:
>
>
>
> On Wed, Nov 7, 2012 at 1:24 PM, Kumar Srinivasan <
> kumar.x.srinivasan at oracle.com> wrote:
>
>>  On 11/7/2012 10:59 AM, Martin Buchholz wrote:
>>  Talking about tests, take a look at
>> langtools/test/tools/javac/file/zip/T6836682.java
>> Scenario A, that does not cut it ?
>>
>
>  I think there's version skew trouble here.
> The problem is that the test T6836682 creates a ZIP64 jar file when there
> are >64k entries,
> so the entry count is accurate.  If the jar file had been created by jdk6,
> the test would fail.
> Unfortunately, it is hard to create a cross-version test.
>
>  Unfortunately, legacy zip implementations (like jdk6) do not understand
> ZIP64, so they fail while trying to read zip files with >64k entries
> created by jdk7.
>
>  For the relatively common case of legacy zip files with >64k entries but
> filesize <4GB, this is a regression!
> And there is no compatibility flag or system property to request the
> legacy behavior of creating a non-ZIP64 output file with >64k entries.
>
>  Until jdk7 is ubiquitous, we may get the best results by using jdk6 to
> write zip files, and using jdk7 to read them!
>
>  Are y'all ready to take the trouble and risk of backporting ZIP64
> support to jdk6?
>
>
>  as JimH would say "I think I hear my management calling....." :)
>

The thorny compatibility issues are indeed hard (seriously, the risk and
effort of a ZIP64 backport is too high and the value provided too low),
.....  but for the issue of jdk7 javac not understanding jdk6-created jar
files with >64k entries, I suggest "simply" fixing the code as I outlined
and adapting T6836682 to a non-jtreg test (because it would need both a
jdk6 and a jdk7 as inputs).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20121107/c2924476/attachment.html