Request for Discussion: 8253952: Work around wrong usage of ZipOutputStream.putNextEntry() in user code

[Volker Simonis]

On Mon, Oct 5, 2020 at 8:13 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 05/10/2020 11:04, Volker Simonis wrote:
> > :
> >> I don't
> >> think the proposal to add a system property to change the behavior is
> >> feasible, at least not without changing the spec but even then it would
> >> be very icky.
> > Why do you think so? The answer to this question is especially
> > important to me because we are considering doing this in our internal
> > version independently of upstream OpenJKD (and potentially also in 8 &
> > 11).
> Introducing system properties to change the behavior of APIs and "fix"
> existing code is really icky. For the main line, then I think it would
> be good to explore the impact of changing the existing putNextEntry or
> introducing a new API. The compatibility impact of the former may not be
> significant but I would expect the spec would be clarified as part of
> this (that is what I was trying to say above). Exploring new APIs would
> be good and a method on ZipEntry may not be too bad (you have a
> reference to the target ZOS in the implementation).

Sorry, maybe I'm missing something, but I can't find a single
reference to neither ZipOutput- nor ZipInputStream in the ZipEntry
class.

>
> > :
> >
> > And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> > property in ZipOutputStream for a similar reason. I just wonder how
> > that could pass the CCC process as I couldn't even find any
> > documentation for it :)
> ZIP64 was very problematic at the time as it wasn't supported by several
> tools. The system property was introduced to disable the feature/support
> so that Java applications didn't create ZIP files that other tools
> couldn't consume. It would be good to get an up to date picture on ZIP64
> support as it might be that this switch can be removed. It pre-dates the
> CSR  process but there was a CCC at the time.
>
> -Alan