3

Simple question:

Is the IBM J9 Java 6 bundled class com.sun.imageio.plugins.jpeg.JPEGImageReader exactly the same as the class with the same package/class name in a standard Sun/Oracle JRE?

(And if it is, is it using the same native/JNI code?)

Background for the question: Bug report, stating that a normal JPEG file can't be read, due "IIOException: Quantization table 0x01 was not defined" (which is clearly a bogus error message, given the completely standard sample image).

Harald K
  • 26,314
  • 7
  • 65
  • 111
  • Does your IBM J9 Java 6 have javax.imageio.ImageIO? If so, try reading the JPEG image with ImageIO. – Gilbert Le Blanc May 19 '15 at 21:11
  • @GilbertLeBlanc Thanks. But, yes, that is what was in use (the first line of the stack trace from the linked bug report is `javax.imageio.ImageIO.read`). The question is trying to establish why it behaves differently than you would expect (or different from the Sun/Oracle version). – Harald K May 20 '15 at 03:59
  • @W.Smith Unfortunately, I don't have the code that caused the exception. I'm only developing the library the linked issue was reported against, and trying to figure out why this environment behaves differently than the Oracle JRE, even if the same classes are present. I would also believe the exception should be reproducible using `ImageIO.read(..)`. Anyways, thanks for helping out! :-) – Harald K Oct 13 '16 at 06:55

1 Answers1

2

An IBM fix was recently released in this area:

IV83756 - CRASH IN COM.SUN.IMAGEIO.PLUGINS.JPEG.JPEGIMAGEREADER.READIMAGE()

http://www-01.ibm.com/support/docview.wss?uid=swg1IV83756

This is fixed in Java 6 SR16 FP30 (6.0.16.30), which was released in July 2016.

The 'crash' described in the fix title is an abort triggered by failing a JNI check that is disabled by default. When the JNI check is disabled, then the program would carry on and it's possible that the underlying problem detected by the check might cause the unreliable image read that is reported here.

W. Smith
  • 131
  • 1
  • 7