JDK-8287120 : com.sun.imageio.plugins.jpeg.JPEGImageReader.read() no longer throws IIOException for a bad image
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 19
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2022-05-21
  • Updated: 2022-05-22
  • Resolved: 2022-05-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19Resolved
Related Reports
Relates :  
JDK-8274735 - javax.imageio.IIOException: Unsupported Image Type while processing a valid JPEG image
Description
Java versions 8 through 18 throw a javax.imageio.IIOException when com.sun.imageio.plugins.jpeg.JPEGImageReader.read(int imageIndex, ImageReadParam param) is invoked against a bad image. However, in the latest early access version of Java 19, this call no longer throws the javax.imageio.IIOException nor does it throw any other exception. Is this an intentional change in behaviour? I checked the release notes for Java 19 https://jdk.java.net/19/release-notes but couldn't find any note about this change.

I've attached a simple reproducer and the bad image for reproducing this issue. To reproduce this issue, download the bad image and the source Java code to the same directory and then run:

java --add-exports java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED ImageIOTest.java badimage.jpg

(Please ignore the direct references to com.sun.imageio.plugins.jpeg.JPEGImageReader class and the related add-exports instruction. These are there just to simplify the reproducer)

When that above command is run against Java 18 (or any earlier versions), you should see the following output:

======
Trying to read badimage.jpg using reader com.sun.imageio.plugins.jpeg.JPEGImageReader
Received the expected exception - javax.imageio.IIOException: Unsupported Image Type
Success
======

When run against Java 19 EA version:

java -version
openjdk version "19-ea" 2022-09-20
OpenJDK Runtime Environment (build 19-ea+23-1706)
OpenJDK 64-Bit Server VM (build 19-ea+23-1706, mixed mode, sharing)
you'll see the following output/failure:

=======
Running test against badimage.jpg
Trying to read badimage.jpg using reader com.sun.imageio.plugins.jpeg.JPEGImageReader
Exception in thread "main" java.lang.RuntimeException: ImageReader.read did not throw an exception that was expected to be thrown
	at ImageIOTest.main(ImageIOTest.java:29)
=======

This failure was caught in one of the tests in Apache Ant project testsuite. The same badimage.jpg that is attached to this issue is available in the Ant project repo here https://github.com/apache/ant/blob/master/src/etc/testcases/taskdefs/optional/image/src/badimage.jpg
Comments
> Filing a bug is not the way I'd choose to ask a question. There's a mailing list for that. Sorry Phil, in the past I had used to JBS issue tracker to file any change in behaviour kind of issues noticed in Ant, so did the same with this one. I'll use the mailing list going forward. As for the image itself, I'll go through the history in the Ant project to see if I can find why it has been classified as a bad image. Thank you for the additional details about the image.
22-05-2022
Filing a bug is not the way I'd choose to ask a question. There's a mailing list for that. I'm not sure why apache categorise as "bad" which implies "corrupted" .. Clearly my web browser (safari) can display it and the message you used to get from Image I/O's exception was "Unsupported Image Type" which is exactly the case. But this image is a CMYK JPEG, because it has an APP14 marker with transform==0 as per below .. so now we can decode it - and in fact if you render the resulting BufferedImage it looks just like what safari loaded for me. 6.5.3 APP14 marker segment for colour encoding ----------------------------------------- A marker segment containing an APP14 marker and the first six bytes of the application data APi (for i = 1 to 6) of the segment coded as X'41', X'64', X'6F', X'62', X'65', X'00' (the zero-terminated string "Adobe", according to Rec. ITU-T T.50 or ISO/IEC 646 coding) shall identify an APP14 marker segment for colour encoding. AP12 is assumed to contain a single-byte transform flag as defined below; the rest of the marker segment is ignored. Transform flag values of 0, 1 and 2 shall be supported and are interpreted as follows: 0 – CMYK for images that are encoded with four components in which all four CMYK values are complemented; RGB for images that are encoded with three components; i.e., the APP14 marker does not specify a transform applied to the image data. 1 – An image encoded with three components using YCbCr colour encoding. 2 – An image encoded with four components using YCCK colour encoding.
21-05-2022