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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
