Thanks for explaining the reasoning behind this. Regards Satya Deep
On Wed, Nov 8, 2017 at 6:20 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > 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 >
