6516099: InputStream.skipFully(int k) to skip exactly k bytes
Roger.Riggs at oracle.com
Thu Oct 25 14:15:52 UTC 2018
The FIS skipping past of end of file is puzzling.
If the 'were beyond EOF' was considering the possibility that the file
extended concurrently with the skip operation then it would not be random,
just a normal writer/reader race. The return value from skip would be
and still usable for skipNBytes.
If the spec for skipNBytes describes its behavior in terms of the normal
of skip(n) and read(n) then it will not making promises it can't keep
regardless of the subclass behavior.
FIS also says it can do negative seeks which seems in conflict with
The FIS.skip(-n) behavior raises the question about whether
There are 200+ subclasses of InputStream in the JDK itself so trying to
figure out which ones should have performant versions of skipNBytes
would be quite a bit of extra work.
On 10/24/2018 08:14 PM, Brian Burkhalter wrote:
> Hi Sergey,
> That is rather ugly. Thanks for pointing it out. The previous version which merely repeatedly read and discarded a buffer of bytes did not have this problem, but it also did not take advantage of any performance improvement to be obtained by subclass overriding of skip().
> It does introduce some randomness into the situation. For example if some FileInputStream with a backing file of length L were used in two different scenarios the results could differ.
> A) skip(L-4) then skipNBytes(8)
> B) skip(L) then skipNBytes(4)
> In case A, skipNBytes(8) could conceivably succeed while in case B, skipNBytes(4) could fail, which is inconsistent given that the final positions in stream terms are theoretically identical.
> Unclear what to do here ...
>> On Oct 24, 2018, at 4:41 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n);
>> "<p>This method may skip more bytes than what are remaining in the
>> * backing file. This produces no exception and the number of bytes skipped
>> * may include some number of bytes that were beyond the EOF of the
>> * backing file. Attempting to read from the stream after skipping past
>> * the end will result in -1 indicating the end of the file."
More information about the core-libs-dev