United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6342404 Image I/O plugin failure causes all readers to fail
JDK-6342404 : Image I/O plugin failure causes all readers to fail

Details
Type:
Bug
Submit Date:
2005-10-27
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2005-12-05
Component:
client-libs
OS:
solaris_9
Sub-Component:
javax.imageio
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

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



Hardware and Software, Engineered to Work Together