The way POIFSFileSystem is implemented right now, the caller is
responsible for closing the input stream supplied.  During normal
operation, POIFSFileSystem reads until EOF (see code within
RawDataBlockList/RawDataBlock).  In most cases the input stream is
being closed by the caller (either explicitly, or implicitly due to
garbage collection of an input stream local variable).
POIFSFileSystem could close the input stream, but doesn't.

I ran into this problem, when a java process held a lock on an XLS
file long after HSSFWorkbook had finished reading it.  Of course the
solution was simple - just call fis.close(), but I was wondering how
many other places this problem might exist.

My suggestion is to have POIFSFileSystem always close the input
stream, so the caller never has to worry about that detail.



There is a potential problem with this proposed patch for the unusual
case where the caller supplies an input stream that can continue to be
used after reaching EOF.  I've never seen such a stream, but any
arbitrary subclass of InputStream could allow such behaviour.  In this
unusual circumstance however, the caller could wrap the input stream
in order to trap the close() call.

Another less likely problem with the patch concerns calling close()
twice on an input stream.  The javadoc has nothing to say about this
point, but all major subclasses of InputStream have no trouble with
this.



So I guess it is a question of whether we want to code "is.close()" in
a finally block after every call to POIFSFileSystem (and classes that
utilise it), vs writing wrapper code in the uncommon cases when
"is.close()" is unwanted.

All existing junits work in the presence of this new patch.  If anyone
can think of a scenario where this patch (always closing the input
stream) would be bad, it would be good to see this requirement
demonstrated as a new junit.

Either way this gets decided, I would like to update the javadoc.
It's always good to document who is responsible for closing a stream.

-josh

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to