Bug with the zip fs provider (7u72, 8u25), am able to create a corrupted zip...

[Francis Galiegue]

On Fri, Jan 16, 2015 at 7:37 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> There is a bug in ZipFileSystem.EntryOutputStream.close(). The current
> implementation
> does not prevent you from writing/closing into the stream after you have
> closed it. The
> second close will basically reset the size to wrong number... You test case
> close the
> stream twice, one is the explicit close, on by the try/catch. Will file a
> bug. The temporary
> workaround is to either remove the "out" out of the try/catch auto-close one
> or don't
> close it explicitly.
>

Yes, the spurious close() was introduced on purpose in order to
trigger the bug. This is the default behavior of Jackson which is why
I could find this bug in the first place ;)

I have already worked around it, so no problems there.

Any ideas if the fix will make it into the next major release (of both
1.7 and 1.8 since both are affected)? In all honesty, the
documentation accompanying new releases (of any product; I have prior,
bad experience with the RDBMS as well) makes it impossible to find
this information. For instance, I couldn't even find a reference
anywhere in the release notes of 1.8u25 that Paths.get("").normalize()
was fixed...

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)