I think we're each half-right. How about a compromise...
Every descendant of InputStream in java.io closes the encapsulated
InputStream when it's own close method is invoked. You wouldn't expect the
following code snipped to leak, would you?
BufferedInputStream bis =
new BufferedInputStream(new FileInputStream("aaa"))
bis.close()
ChunkyByteArray didn't have a close() method so if ChunkyByteArray.close() were
called (and it IS being called properly), it would be InputStream.close() that
was actually invoked. That's an empty method and therefore a leak.
So, I'll remove the calls to close() in ChunkyByteArray, but the close() method
itself needs to stay. Also, the existing "fInputStream = null" statements have
to stay removed so close() can call fInputStream.close().
george
-----Original Message-----
From: Andy Clark [mailto:[EMAIL PROTECTED]
Sent: Monday, February 07, 2000 2:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Patch for ChunkyByteArray.java
"George T. Joseph" wrote:
>
> Under 2 of 3 EOF conditions, the InputStream under ChunkyByteArray was not
being
> closed before fInputStream was set to null. This resulted in files being left
> open even after all parsing was complete. Usually the JVM cleans this up
when
> the InputStream is garbage collected. However, if the GC doesn't run (either
> because a large heap is allocated or because it's turned off) the files remain
> locked.
I would disagree that the ChunkyByteArray is responsible for
closing the stream. My general rule is that if you create
the stream, you close it. Since the ChunkyByteArray doesn't
open the stream, it should not presume that it is allowed
to close it. In fact, I'm thinking that the one place where
ChunkyByteArray closes fInputStream should be removed.
However, this does bring up a very good point. Are there
places in the code where a stream is opened internal to the
parser, yet not closed? Patches for those conditions would be
gladly accepted! :)
--
Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED]
