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

[Lance Andersen]

Hi Volker,

Thank you for looking into this and creating a draft PR.

On the surface, I don’t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.

The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.

Thoughts?

Best
Lance

> On Oct 5, 2020, at 2: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).
> 
>> :
>> 
>> 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


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com