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

[Volker Simonis]

On Wed, Oct 7, 2020 at 5:12 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 06/10/2020 15:44, Volker Simonis wrote:
> > :
> > Sorry, maybe I'm missing something, but I can't find a single
> > reference to neither ZipOutput- nor ZipInputStream in the ZipEntry
> > class.
> >
> I should have been clearer. If the method is on ZOS then you have the
> receiver and the ZipEntry parameter. If you are exploring methods on
> ZipEntry then you have the receiver and the ZOS parameter.
>

That's true, but the problem is that there'S no reference to the
source zip file or stream. As I wrote previously (copied here for your
convenience):

If you mean that  ZipEntry.transferTo() will be intended to copy a
ZipEntry together with the associated, compressed data that will be
much harder if not impossible to implement with the current API. The
first problem is that ZipEntry has no reference to its associated
ZipFile or ZipInputStream. The much bigger problem is that
ZipInputSream is a "streaming" API. We might read from a zip file
which doesn't have the compressed size information in the LFH. In such
a case, it would be impossible to read the compressed data from the
stream because we don't know its length. We can only start to inflate
the data until inflation stops. Only at that point we know the
compressed size of the entry. But at that point we can't access the
compressed data any more because we can't reset the stream.

> -Alan