Why is it unexpected ?
The method declares that it throws IOException .. which if thrown
clearly means the stream can't be de-coded.
Perhaps your point is that this then prevents control reaching the
reset, so that the next plugin
doesn't get its turn to also reject the truncated file.
I suppose I can see that might be a reasonable thing to do in the event
there's some image format
that has a large read requirement for the header validation and that the
following plugin may
see that there's a small valid image ?
But this fix is still putting it on each plugin to behave itself .. and
we already handle that in the ImageIO class
although I think it isn't perfect, as it still relies on co-operation
with regard to mark()
And if you call this directly, you can handle that just as well yourself
.. and still can't trust extra
plugins to behave ..,. so what is the use case for this fix ?
-phil.
On 5/17/22 5:48 AM, Martin Desruisseaux wrote:
Hello
I prepared a pull request at [1] for fixing an unexpected EOFException
thrown by ImageReaderSpi.canDecodeInput(Object) in JDK implementations
for BMP, WBMP, GIF, PNG and TIFF formats (JPEG is not impacted). This
exception occurs when the stream has less than 8 bytes. For example,
it occurs when probing all files in a directory if that directory
contains empty files.
If believe that in order to process, a bug report must be filled on
https://bugs.openjdk.java.net/ ? Can someone hint me about how to do
that (since I can not create a report myself)?
Regards,
Martin
[1]https://github.com/openjdk/jdk/pull/8700
