I don't think that is the actual reason here - it seems likely that there
was some kind of internal error or bad SPI causing this.
So throwing an exception seems more appropriate.
And also the bug was originally solely about write(..).
-phil.
On 03/16/2016 01:35 PM, Sergey Bylokhov wrote:
As far as I understand the createImageInputStream() returns null is
this stream is unsupported by current plugins via spi. Probably the
read() method should return null too?
/**
* Returns a {@code BufferedImage} as the result of decoding
* a supplied {@code InputStream} with an {@code ImageReader}
* chosen automatically from among those currently registered.
* The {@code InputStream} is wrapped in an
* {@code ImageInputStream}. If no registered
* {@code ImageReader} claims to be able to read the
* resulting stream, {@code null} is returned.
*
.......
* @return a {@code BufferedImage} containing the decoded
* contents of the input, or {@code null}.
*/
public static BufferedImage read(InputStream input) throws
IOException
On 16.03.16 20:29, Philip Race wrote:
The test writes out into "test.src".
I believe that you should treat that as a "read-only" location.
Write to a tempfile (File.createTempFile()) or TESTCLASSES.
-phil.
On 3/15/16, 10:50 PM, Jayathirth D V wrote:
Hi Phil,All
_Please review the following fix in JDK9:_
__
Bug : https://bugs.openjdk.java.net/browse/JDK-8044289
Webrev : http://cr.openjdk.java.net/~jdv/8044289/webrev.00/
<http://cr.openjdk.java.net/%7Ejdv/8044289/webrev.00/>
Issue : When createImageInputStream() or createImageOutputStream
returns null in ImageIO.read() or ImageIO.write() we are seeing NPE as
it stream is used further without null check.
Root cause : “stream” is used without checking whether it is null or
not.
Solution : Handle null pointer of stream and throw IIOException.
Test case contains all possible scenarios where
createImageInputStream() or createImageOutputStream can return null.
Thanks,
Jay
