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

[Joe Darcy]

On 10/6/2020 6:56 AM, Volker Simonis wrote:
> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>> Hi Volker
>>
>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>
>>
>> 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.
>>
>>
>> Sure. That's obviously the simplest and best solution and I'd be
>> totally happy with it. I just thought there might be a need for
>> somehow preserving the old and buggy behaviour, that's why I added the
>> system property.
>>
>> I've created a simpler version of the fix without property and
>> adjusted the @apiNote accordingly:
>>
>>
>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
> Changing the updated doc to be normativ instead of just an @apiNote
> will make it impossible to downport this change but if you think it is
> really necessary I will accept that. I've removed the @apiNote tag
> from the java doc and changed the draft PR into a real PR.
>
> Without the @apiNote tag I also had to copy the extra documentation
> verbatim to JarOutputStream.putNextEntry() which is not very elegant
> but inheriting the whole api doc from ZipOutputStream didn't seem
> right either. Please let me know if you have a better idea.
>
> I'll open a CSR once we've agreed on the exact text for the java doc change.
>
Note that a backport doesn't necessarily need to be "the same" as the 
original change, although it preferable when it can be of course.

In other words, I would not constrain the change in the feature release 
train by what can be directly backported.

Cheers,

-Joe