Because people write code like:
myMethod(InputStream in) {
InputStream child = new InputStream(in);
child.close();
}
InputStream in = new FileInputStream(... path ...);
myMethod(in);
myMethod(in);
An exception will be thrown when the second myMethod call occurs.
Unfortunately not everyone wraps their calls to a coder with an
UnownedInputStream or a filter input stream which drops close() calls is
why its a problem and in the few places it is done it is used to prevent
bugs from creeping in.
On Tue, Jan 30, 2018 at 11:29 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
> I get the issue but I don't get the last part. Concretely we can support
> any lib by just removing the exception in the close, no? What would be the
> issue? No additional wrapper, no lib integration issue.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau>
>
> 2018-01-30 19:29 GMT+01:00 Lukasz Cwik <lc...@google.com>:
>
>> Its common in the code base that input and output streams are passed
>> around and the caller is responsible for closing it, not the callee. The
>> UnownedInputStream is to guard against libraries that are poorly behaved
>> and assume they get ownership of the stream when it is given to them.
>>
>> In the code:
>> myMethod(InputStream in) {
>> InputStream child = new InputStream(in);
>> child.close();
>> }
>>
>> InputStream in = ...
>> myMethod(in);
>> myMethod(in);
>> When should "in" be closed?
>>
>> To get around this issue, create a filter input/output stream that
>> ignores close calls like on the JAXB coder:
>> https://github.com/apache/beam/blob/master/sdks/java/io/xml/
>> src/main/java/org/apache/beam/sdk/io/xml/JAXBCoder.java#L181
>>
>> We can instead swap around this pattern so that the caller guards against
>> callees closing by wrapping with a filter input/output stream but this
>> costs an additional method call for each input/output stream call.
>>
>>
>> On Tue, Jan 30, 2018 at 10:04 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> All is in the subject ;)
>>>
>>> Rational is to support any I/O library and not fail when the close is
>>> encapsulated.
>>>
>>> Any blocker to swallow this close call?
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>> <http://rmannibucau.wordpress.com> | Github
>>> <https://github.com/rmannibucau> | LinkedIn
>>> <https://www.linkedin.com/in/rmannibucau>
>>>
>>
>>
>
