8227080: (fs) Files.newInputStream(...).skip(n) is slow

[Roger Riggs]

Hi Brian,

Looks fine; taking into account possible integer overflow and returning 
the actual number of bytes skipped.

+1, Roger

On 7/2/19 7:16 PM, Brian Burkhalter wrote:
>
>> On Jul 2, 2019, at 3:32 PM, Simone Bordet <simone.bordet at gmail.com 
>> <mailto:simone.bordet at gmail.com>> wrote:
>>
>> On Wed, Jul 3, 2019 at 12:00 AM Brian Burkhalter
>> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> Here is an updated version which should not have a problem with 
>>> overflow:
>>>
>>> http://cr.openjdk.java.net/~bpb/8227080/webrev.01/
>>
>> Why:
>>
>> return sbc.position() - pos;
>>
>> rather than just:
>>
>> return n;
>
> That’s what I had first before re-posting.
>
>> Unless SeekableByteChannel.position(int) may not actually set the
>> position to the given value, which I can't quite believe (as the
>> javadoc says it is permitted to set it to a larger value than the
>> current size)?
>
> No, I think either way is good.
>
>> Will you tackle the missing synchronization in another webrev?
>
> Yes as I am sure there will be other comments from others.
>
> Thanks,
>
> Brian