Hi, On Wed, Nov 8, 2017 at 7:12 AM Satya Deep Maheshwari <m.satyad...@gmail.com> wrote: > While going through the JCR 2.0 api, I see several instances wherein its > specified that the passed inputstream would be closed. > [...] > What is the specific reason for this?
Good question! We actually debated this at some length in the JSR 283 expert group. The overall consensus was that the behavior regarding whether the streams will get closed or not by the implementation should be clearly documented, and there were good arguments either way. The reason why we decided to give that responsibility to the implementation was that it allows an implementation to defer consuming the stream to when save() is called. Otherwise the implementation would always have to consume the entire stream right away, which is problematic in some cases as it could involve using gigabytes of memory or temporary disk space for buffering the streams until the save() call. > Just wondering if this would be > problematic wherein I want to let the stream remain open for e.g. when > reading from a zip file. For the zip file case you can use the ZipFile class to get independent ZipInputStreams for the entries in the file. More generally the CloseShieldInputStream utility class in Commons IO [1] can be used to prevent the closing of a stream, though in such cases you'll need to be sure that the underlying implementation won't be using the mentioned optimization of deferring the consumption of the stream. [1] https://commons.apache.org/proper/commons-io/javadocs/api-2.6/org/apache/commons/io/input/CloseShieldInputStream.html Best, Jukka
