JDK-8263620 : (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 17
  • Submitted: 2021-03-15
  • Updated: 2021-03-25
  • Resolved: 2021-03-25
Related Reports
CSR :  
Description
Summary
-------

The `compact()`, `duplicate()`, and `slice()` methods of `java.nio.MappedByteBuffer` are changed to covariant overrides returning a `MappedByteBuffer` instead of a `ByteBuffer`.

Problem
-------

The `compact()`, `duplicate()`, and `slice()` methods of `MappedByteBuffer` return a `ByteBuffer` thereby precluding the ability to use these methods in chain invocations except as the terminal invocation.

Solution
--------

Provide covariant overrides for the `MappedByteBuffer` methods `compact()`, `duplicate()`, and `slice()`.

Specification
-------------

    --- a/src/java.base/share/classes/java/nio/MappedByteBuffer.java
    +++ b/src/java.base/share/classes/java/nio/MappedByteBuffer.java
    @@ -205,7 +215,10 @@ public abstract class MappedByteBuffer
     
         /**
          * Forces any changes made to this buffer's content to be written to the
    -     * storage device containing the mapped file.
    +     * storage device containing the mapped file.  The region starts at index
    +     * zero in this buffer and is {@code capacity()} bytes.  An invocation of
    +     * this method behaves in exactly the same way as the invocation
    +     * {@link force(int,int) force(0,capacity())}.
          *
          * <p> If the file mapped into this buffer resides on a local storage
          * device then when this method returns it is guaranteed that all changes
    
    @@ -362,4 +375,41 @@ public abstract class MappedByteBuffer
             super.rewind();
             return this;
         }
    +
    +    /**
    +     * {@inheritDoc}
    +     *
    +     * <p> Reading bytes into physical memory by invoking {@code load()} on the
    +     * returned buffer, or writing bytes to the storage device by invoking
    +     * {@code force()} on the returned buffer, will only act on the sub-range
    +     * of this buffer that the returned buffer represents, namely
    +     * {@code [position(),limit())}.
    +     */
    +    @Override
    +    public abstract MappedByteBuffer slice();
    +
    +    /**
    +     * {@inheritDoc}
    +     *
    +     * <p> Reading bytes into physical memory by invoking {@code load()} on the
    +     * returned buffer, or writing bytes to the storage device by invoking
    +     * {@code force()} on the returned buffer, will only act on the sub-range
    +     * of this buffer that the returned buffer represents, namely
    +     * {@code [index,index+length)}, where {@code index} and {@code length} are
    +     * assumed to satisfy the preconditions.
    +     */
    +    @Override
    +    public abstract MappedByteBuffer slice(int index, int length);
    +
    +    /**
    +     * {@inheritDoc}
    +     */
    +    @Override
    +    public abstract MappedByteBuffer duplicate();
    +
    +    /**
    +     * {@inheritDoc}
    +     */
    +    @Override
    +    public abstract MappedByteBuffer compact();
     }


Comments
Thanks for the additional information; moving to Approved.
25-03-2021

Re-finalizing.
24-03-2021

MappedByteBuffer has only package-scope constructors.
24-03-2021

ByteBuffer and MappedByteBuffer cannot be extended outside of the java.nio package, they want to be sealed but didn't have the language/VM when they were introduced.
24-03-2021

Moving to Provisional, not Approved until a few points are discussed. Is it the case that all subclasses/constructors of MappedByteBuffer are controlled by the platform and not exposed to end-users? In other words, a user cannot define a MappedByteBuffer subclass? If that is the case, then the API change should be fine. If that is not the case, then derailed JDK-7140820 may be in play.
24-03-2021