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
|