United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6336804 : javax.imageio.ImageIO possible handle leak in some methods

Details
Type:
Bug
Submit Date:
2005-10-13
Status:
Resolved
Updated Date:
2010-04-26
Project Name:
JDK
Resolved Date:
2006-01-09
Component:
client-libs
OS:
solaris_9,generic,solaris_10
Sub-Component:
javax.imageio
CPU:
sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2,5.0,6
Fixed Versions:

Related Reports
Duplicate:

Sub Tasks

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.
                                     
2005-11-23



Hardware and Software, Engineered to Work Together