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

[Alan Bateman]

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

> :
>
> 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