poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yegor Kozlov <ye...@dinom.ru>
Subject Re: Should POIFSFileSystem close its input stream (Buzilla 44366)?
Date Thu, 07 Feb 2008 09:29:46 GMT
Personally, I think the caller is always responsible for closing the input stream.
With java.io.* streams calling fis.close() twice doesn't do any harm.
BUT think of reading via JDBC input streams ( from Oracle or MySQL
blobs, etc.). Are you sure they will be happy with closing of already
closed stream?

So, I'm -1 to automatically close it in POIFSFileSystem(InputStream
stream).

What we can do is to create a special constructor:
POIFSFileSystem(InputStream stream, boolean autoClose ).

autoClose=false by default.

Use it in your code if you need this "auto-close" behavior

Yegor

> 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: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org


Mime
View raw message