RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4]

Alan Bateman alanb at openjdk.java.net
Tue Mar 16 14:42:08 UTC 2021


On Tue, 16 Mar 2021 14:26:47 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. I'm asking now because the change in this PR will specify the new behavior rather than the long standing behavior.
>
> @AlanBateman Hmm, I think that's a different issue to my comment.
> 
> I asked my question above because the correction Brian made when documenting slice(int index, int length) employed a half-closed interval with an exclusive right bound for the interval
> 
>     [index,index+length)
> 
> and I merely felt that the same should apply here in the documentation of slice()
> 
>   [position(),limit())
> 
> I'm not sure I am in a position to provide the right answer to your question but I'll note that in the same pedantic vein the intervals you mention should be similarly semi-closed
> 
>     [0, capacity)
> 
> and
> 
>     [0, limit)
> 
> The byte at index limit/capacity is not necessarily flushed (modulo page roundings).
> 
> As to what might be a correct answer:
> 
>> The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change.
> 
> I believe this was done intentionally when I introduced the force(int,int) variant and re-implemented the noargs variant to indirect to it. I cannot recall why it changed from capacity to limit though.

@adinn My comment wasn't to you, it's a concern that the no-arg force method has changed and the new behavior is proposed to be specified by this PR. I need to re-read the mails as it may be that this will need to be restored to use the capacity.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2902


More information about the nio-dev mailing list