Re: 8241952: (fs) FileChannel.write​(ByteBuffer src, long position) does not check for the FileChannel being closed first

[Brian Burkhalter]

> On Apr 9, 2020, at 5:00 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> I don't see anything in the webrev to inherit the text from super interfaces, are doing that with a separate issue?

There is no separate issue yet. An example of what I am talking about is FileChannel.read(ByteBuffer[] dsts,int,int). Its javadoc [1] does not have the same exceptions as the specification in ScatteringByteChannel [2]. It does have a subset of the exceptions in the doc but there are none in the FileChannel code itself [3] nor anything about inheriting doc.

Brian

[1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/nio/channels/FileChannel.html#read(java.nio.ByteBuffer[],int,int)
[2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/nio/channels/ScatteringByteChannel.html#read(java.nio.ByteBuffer%5B%5D,int,int)
[3] http://hg.openjdk.java.net/jdk/jdk14/file/6c954123ee8d/src/java.base/share/classes/java/nio/channels/FileChannel.java#l360

    /**
     * Reads a sequence of bytes from this channel into a subsequence of the
     * given buffers.
     *
     * <p> Bytes are read starting at this channel's current file position, and
     * then the file position is updated with the number of bytes actually
     * read.  Otherwise this method behaves exactly as specified in the {@link
     * ScatteringByteChannel} interface.  </p>
     */
    public abstract long read(ByteBuffer[] dsts, int offset, int length)
        throws IOException;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200409/9d9d021c/attachment.htm>