RFR 15 8243099: Adding ADQ support to JDK

[Alan Bateman]

On 29/04/2020 19:11, Ivanov, Vladimir A wrote:
> Updated version of the webrev available as http://cr.openjdk.java.net/~sviswanathan/Vladimir/8243099/webrev.03/
>
> The tests run results for the " test/jdk/java/net test/jdk/java/nio/channels test/jdk/javax/net test/jdk/jdk/net test/jdk/sun/net" same as for non-patched version.
>
> Changes:
> 1. comment was updated
> 2. names were adjusted with convention (IncomingNapiIdOptSupported  => incomingNapiIdOptSupported, IncomingNapiIdSupported => IncomingNapiIdSupported);
>
Thanks for the update.

For the javadoc, I wonder if it might be simpler to drop "Incoming Napi 
Id" so that the first line is "Identifies the receive queue ...". That 
avoids needing to use "Napi" in the javadoc as it would need to be 
defined. Your previous mail had some good text that could be massaged 
into an @apiNote to give the reader some idea how this socket option 
might be used. I'm in two minds on that because it is very Linux specific.

Does SO_INCOMING_NAPI_ID return a non-0 value for connections through 
the loopback? Just checking as that will influence the tests that can be 
created.

SO_INCOMING_NAPI_ID is supported by all socket types so I think we will 
need tests to properly exercise it on the network channels defined in 
java.nio.channels.

AfterClose test. The legacy Socket APIs validate parameters after they 
have checked the socket state so I assume most of the changes to this 
test aren't really needed. That is, I assume SocketException is thrown 
always. SocketChannel and friends are different in that they validate 
the parameters/input before checking the channel state.

PrintSupportedOptions. That can be simplified to use 
Set.of("SO_INCOMING_NAPI_ID").

-Alan.