JDK-8198692 : Release Note: Separate Blocking and Non-blocking Code Paths
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 11
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2018-02-26
  • Updated: 2019-04-09
  • Resolved: 2018-05-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11Resolved
Description
The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes:

1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors.

2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel.

3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed.