On Thu, 6 Apr 2023 22:36:33 GMT, Archie L. Cobbs <d...@openjdk.org> wrote:
> IO stream classes like `FileOutputStream` can have assocated NIO channels. > > When `close()` is invoked on one of these classes, it in turn invokes > `close()` on the associated channel (if any). But when the associated > channel's `close()` method is invoked, it in turn invokes `close()` on the > associated stream (if any). > > As a result, these IO stream `close()` methods invoke themselves reentrantly > when there is an associated channel. > > This is not a problem for these classes because they are written to handle > this (i.e., they are idempotent), but it can be surprising (or worse, just > silently bug-inducing) for subclasses that override `close()`. > > There are two possible ways to address this: > 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations > 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware > > This patch takes the second, more conservative approach. Closing a FIS/FOS/RAF with an associated file channel is specified to close the channel. FileChannel's class description is missing a sentence to say that closing a file channel obtained from a FIS/FOS/RAF will close the stream, something like: --- a/src/java.base/share/classes/java/nio/channels/FileChannel.java +++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java @@ -122,7 +122,8 @@ import jdk.internal.javac.PreviewFeature; * the originating object, and vice versa. Changing the file's length via the * file channel will change the length seen via the originating object, and vice * versa. Changing the file's content by writing bytes will change the content - * seen by the originating object, and vice versa. + * seen by the originating object, and vice versa. Closing the channel will + * close the originating object. No objection to adding a note to FIS/FOS/RAF for cases where these classes are extended and close is overridden but I think it should be an API note. As regards JBS issues, the title on JDK-8291023 is misleading as it's nothing to do with FileChannel.close, maybe a new issue should be created for the the API note or else JDK-8291023 it renamed to reflective the re-purpose. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1500021465
