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 <[email protected]>: > 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 < > [email protected]> 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> >> > >
