JDK-6342404 : Image I/O plugin failure causes all readers to fail
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2005-10-27
  • Updated: 2011-01-19
  • Resolved: 2005-12-05
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.
Other JDK 6
5.0u7Fixed 6 b63Fixed
Related Reports
Relates :  
Description
I was doing some testing with our app and noticed that if I removing an
ImageIO plugin's code from the classpath, but still include an entry for
the plugin's ImageReader in META-INF/services, I am no longer able to
use ANY of the ImageIO plugins.

I'm using JDK1.4.2_09. I get a NoClassDefFoundError upon running the
following:

  String[] names = ImageIO.getReaderFormatNames();

The reason I'm getting a
NoClassDefFoundError at this line is because of a failure in
the static initializer of the ImageIO class. It's calling the
IIORegistry, which is trying to iterate over the available
ImageReaders. Since I've removed the plugin code from the classpath,
the registry gets an error when trying to load the class for
the particular plugin.

This to me seems to be a serious problem. Failure of a single
plugin brings the whole ImageIO plugin system down. This puts
the plugin architecture at the mercy of any malicious or
careless developer who might misconfigure their plugin and
thus disable all other plugins.

Naturally, it would be nice to know when a single plugin has
failed to load, but it seems this error should be caught so
that other plugins could continue to load properly.

Here's the stack trace down to the point where it leaves our code
and goes into the J2SE code:

sun.misc.ServiceConfigurationError: javax.imageio.spi.ImageWriterSpi:
Provider com.lmco.imageio.nitf.NITFImageWriterSpi not found
        at sun.misc.Service.fail(Service.java:129)
        at sun.misc.Service.access$000(Service.java:111)
        at sun.misc.Service$LazyIterator.next(Service.java:272)
        at
javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegist
ry.java:174)
        at javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:113)
        at
javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:134)
        at javax.imageio.ImageIO.<clinit>(ImageIO.java:46)

Comments
EVALUATION It is interesting that the Service.providers() method (and the methods on the Iterator it returns) is specified to throw a ServiceConfigurationError, but since it is an Error, it is not required to be caught by the caller. In any case, we should add a try/catch block in IIORegistry.registerApplicationClasspathSpis() to catch ServiceConfigurationError. If caught, we should probably silently ignore the failure and continue attempting to register the remaining SPIs. Same fix should be applied to IIORegistry.registerInstalledProviders().
2005-10-27