Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8263826

(bf) MappedByteBuffer.force() should use the capacity as its upper bound

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P3 P3
    • 17
    • core-libs
    • None
    • behavioral
    • low
    • A difference in the portion of the buffer written back to storage might be observable in some cases, but it would be more written back, not less.
    • Java API
    • SE

      Summary

      Modify the MappedByteBuffer force() methods to use as upper bound the capacity instead of the limit.

      Problem

      Prior to JDK 15, the capacity was used as the upper bound in the MappedByteBuffer force() methods. Via a sequence of changes described in the associated issue, this upper bound was inadvertently changed to the limit.

      Solution

      In the force() methods of MappedByteBuffer change the upper bound to be the capacity.

      Specification

      The only part of the specification which is affected are the descriptions of the parameters of MappedByteBuffer.force(int,int):

      @@ -267,11 +267,11 @@ public abstract class MappedByteBuffer
            * @param  index
            *         The index of the first byte in the buffer region that is
            *         to be written back to storage; must be non-negative
      -     *         and less than limit()
      +     *         and less than {@code capacity()}
            *
            * @param  length
            *         The length of the region in bytes; must be non-negative
      -     *         and no larger than limit() - index
      +     *         and no larger than {@code capacity() - index}
            *
            * @throws IndexOutOfBoundsException
            *         if the preconditions on the index and length do not

            bpb Brian Burkhalter
            bpb Brian Burkhalter
            Alan Bateman
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: