Why does JCR 2.0 API ask to close the passed InputStream?

[Satya Deep Maheshwari <m....@gmail.com>]

Hi

While going through the JCR 2.0 api, I see several instances wherein its
specified that the passed inputstream would be closed. Here are a few
instances:

Node.setProperty(String, InputStream)
Property.setValue(InputStream)
ValueFactory.createValue(InputStream)
ValueFactory.createBinary(InputStream)
Session.importXML(String, InputStream, int)
Workspace.importXML(String, InputStream, int)

What is the specific reason for this? 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.

Regards
Satya Deep

Re: Why does JCR 2.0 API ask to close the passed InputStream?

[Satya Deep Maheshwari <m....@gmail.com>]

Thanks for explaining the reasoning behind this.

Regards
Satya Deep

On Wed, Nov 8, 2017 at 6:20 PM, Jukka Zitting <ju...@gmail.com>
wrote:

> Hi,
>
> On Wed, Nov 8, 2017 at 7:12 AM Satya Deep Maheshwari
> <m....@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
>

Re: Why does JCR 2.0 API ask to close the passed InputStream?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Nov 8, 2017 at 7:12 AM Satya Deep Maheshwari
<m....@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