Hi All: We should at the very least document all of this carefully.
My gut reaction is that an API called skip should call skip internally. Doing anything else clever as you point out has performance implications and might violate the principle of least surprise. We could consider creating a Skipper interface that can be implemented by with Skip and a SkipRead implementations. Then all of the code that used to call skip would be parameterized. But this might be too framework-y for [io], or [compress] Gary On Sun, Apr 22, 2018 at 9:52 AM, Stefan Bodewig <bode...@apache.org> wrote: > Hi all > > while looking into https://issues.apache.org/jira/browse/COMPRESS-449 I > realized that calling skip on any InputStream probably means you are up > to receiving an IOException because some stream in there decided to > implement skip via seek and now faces a stream that doesn't support > seek. And there is no way you can test for this. > > It looks as if commons-io has decided to simple not use skip at all, > IOUtils.skip only uses read. commons-compress IOUtils.skip tries to be > smart with a combination of skip and read but is fooled when the stream > it reads from is System.in and the amount to skip is big enough. > > OTOH not using skip but read on a stream that was happy to provide a > proper skip is a severe waste of time. > > Any other ideas than playing save and wasting time? > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
