[OpenJDK 2D-Dev] RFR: 8204187: Remove proprietary JPEG code from javax.imageio

Krishna Addepalli krishna.addepalli at oracle.com
Fri Jun 1 20:04:07 UTC 2018

Hi Phil,

The changes look fine to me. However I have one question: In SOFMarkerSegment.java file, in the function below,

  int getIDencodedCSType () {
  for (int i = 0; i < componentSpecs.length; i++) {
	if (componentSpecs[i].componentId < 'A') {
	          return JPEG.JCS_UNKNOWN;
 switch(componentSpecs.length) {
 case 3:
 	if ((componentSpecs[0].componentId == 'R')
 	          &&(componentSpecs[0].componentId == 'G')
 	          &&(componentSpecs[0].componentId == 'B')) {
 		          return JPEG.JCS_RGB;

componentId is an integer, and it can store only one value R, G or B. However, the condition checks for the integer value being equal to all the three values simultaneously which is impossible.
I know this code was existing before your changes, but not sure if my understanding is correct.


-----Original Message-----
From: Phil Race 
Sent: Friday, June 1, 2018 10:35 PM
To: 2d-dev <2d-dev at openjdk.java.net>
Subject: [OpenJDK 2D-Dev] RFR: 8204187: Remove proprietary JPEG code from javax.imageio

Bug : https://bugs.openjdk.java.net/browse/JDK-8204187
CSR : https://bugs.openjdk.java.net/browse/JDK-8204189
Webrev : http://cr.openjdk.java.net/~prr/8204187/

Please review the code and the CSR.

There are 4 optional color spaces for the standard JPEG plugin documented in the javax.image I/O JPEG metadata specification.


Optional ColorSpace support: Handling of PhotoYCC (YCC), PhotoYCCA (YCCA), RGBA and YCbCrA color spaces by the standard plugin, as described below, is dependent on capabilities of the libraries used to interpret the JPEG data. Thus all consequential behaviors are optional.
[and more details]
The necessary support for these is implemented in a modified, closed source, IJG libjpeg 6b.

What this means is that OpenJDK never has supported these.

However code to handle these on the Java side is implemented in the open code Oracle intends to remove the closed source native support, so we can clean up the open code.

And there's a particular bug that even the supported YCCK color space would not work with OpenJDK due to the ID specified in the Java code not matching the ID specified in the standard IJG libraries.

Another fix is that even though it did not have support for writing images with alpha, the writer would say it could - true only for a JDK with the closed enhancements.
So what would happen is that even if code would check to see if it was supported when it tried it would get this exception :

Exception in thread "main" javax.imageio.IIOException: Invalid argument to native writeImage
     at java.desktop/javax.imageio.ImageWriter.write(ImageWriter.java:613)
     at java.desktop/javax.imageio.ImageIO.doWrite(ImageIO.java:1628)
     at java.desktop/javax.imageio.ImageIO.write(ImageIO.java:1594)
     at TestWriteARGBJPEG.main(TestWriteARGBJPEG.java:15)

With the removal of the Java code related to these color spaces, you will still get an exception, but a slightly different one :

Exception in thread "main" javax.imageio.IIOException: Bogus input colorspace
     at java.desktop/javax.imageio.ImageWriter.write(ImageWriter.java:613)
     at TestWriteARGBJPEG.main(TestWriteARGBJPEG.java:23)

The key to avoiding both of these is making sure the code that checks support looks to see if there is an alpha channel and gives you a correct answer. That is fixed.
I have also included a new test which covers this and updated an existing one.

I am leaving the specification alone for now at least, to leave the door open to reinstating such support somehow if it there is a need. If we do it may be just a subset.

I am preparing a release note as well as a CSR for this.


More information about the 2d-dev mailing list