OK .. we can probably take the proposed change, but there's no guarantee
it won't
still happen with 3rd party external plugins.
I've filed the bug for you :
https://bugs.openjdk.java.net/browse/JDK-8287102
-phil.
On 5/18/22 2:47 AM, Martin Desruisseaux wrote:
Hello Philip
Le 17/05/2022 à 20:36, Philip Race a écrit :
Why is it unexpected ?
The purpose of ImageReaderSpi.canDecodeInput(Object) is to tell if the
source object seems to be supported by the reader. If the file is too
small, it is not supported by the reader. So a return value of false
is what I would expect from the method contract, because the method is
capable to provide a clear answer to the question "does it seems a
valid file?"
By contrast, I would expect IOException to be thrown only if an
unexpected error prevents canDecodeInput(Object) from fulfilling its
method contract, e.g. a lost of internet connection prevents the
reader to check the magic number. EOFException does not met that
criterion for the reason stated above.
The method declares that it throws IOException .. which if thrown
clearly means the stream can't be de-coded.
In my understanding of the method contract, if the stream can not be
decoded, this is indicated by a return value of false rather than an
IOException. In the context of ImageReaderSpi.canDecodeInput(Object),
I interpret IOException as an error that prevent the method from
answering the question "does it seems a valid file?"
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 ?
In my case I handle the search of ImageReader myself. Contrarily to
ImageIO I do not catch IOException, because it may be a serious error
that prevent the plugin from answering its question. The stream may
now be in a corrupted state (it is not always a local file; it can be
on the cloud, a database BLOB, etc), and continuing with other readers
after the initial error can cause a series of confusing error
messages. Instead I let the first IOException propagates. The meaning
is very different than "unsupported format".
I could catch the specific case of EOFException, but I don't because
1) it relies on assumptions about how the plugin behave, 2) the input
may be an object other than ImageInputStream that we don't know how to
mark, and 3) EOFException can in some circumstances be a serious error
(i.e. EOFException occurring not in the stream given to the
canDecodeInput(Object) method, but is some auxiliary file that the
plugin needs to read). Only the plugin knows for sure if EOFException
means "unsupported format" or "serious error".
Regards,
Martin
