JDK-6336804 : javax.imageio.ImageIO possible handle leak in some methods
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 1.4.2,5.0,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,solaris_9,solaris_10
  • CPU: generic,sparc
  • Submitted: 2005-10-13
  • Updated: 2017-05-16
  • Resolved: 2006-01-09
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 6
6 b67Fixed
Related Reports
Duplicate :  
JDK-6466989 - Unsafe implementation of ImageIO.read()
Description
J2SE Version (please include all output from java -version flag):
 java version "1.6.0-ea"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b55)
  Java HotSpot(TM) Client VM (build 1.6.0-ea-b55, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
  don't know


Bug Description:
   javax.imageio.ImageIO possible handle leak in some methods. 
   "High level" methods to read/write files do not close streams 
   in case of exceptions. See below.

Steps to Reproduce (be specific):
   For example the method javax.imageio.ImageIO.write(RenderedImage,String,File) 
   contains the following code:

public static boolean write(RenderedImage im, String formatName, File output)
    throws IOException {
...
      ImageOutputStream stream = null;
    try {
        output.delete();
	stream = createImageOutputStream(output);
    } catch (IOException e) {
        throw new IIOException("Can't create output stream!", e);
    }
    boolean val = write(im, formatName, stream);
    stream.close(); // not called if above method throws exception!
    return val;
}

   If write() throws an exception, stream.close(); will never be called and 
   the underlying operating system handle will never be closed.
Comments
EVALUATION Yes, it's amazing that no one noticed this sooner. We should make sure that all the read() and write() convenience methods are careful to close streams and dispose reader/writer instances in a try/finally block, whenever appropriate. As part of this fix, we should clarify the spec of these methods as to whether or not they close the provided stream (for those methods that take streams as arguments). In fixing this bug it was noticed that the read(ImageInputStream) method is inconsistent with the rest of the methods in the class in that it will close the provided stream after the read operation has completed. This is unfortunate because that behavior differs from the other convenience methods, such as write(ImageOutputStream), but it's too late in the game to change this behavior now. So at this point the best we can do is add some notes to each method's javadocs indicating whether it is the caller's responsibility or not to close the provided stream.
23-11-2005