Extended socket options and module layers

[Alan Bateman]

On 05/08/2022 20:43, Chris Hegarty wrote:
> :
>
> I'm not sure that there is anything that should (or could) be done about
> this - an SPI for extended options is not really viable or suitable. Our
> use of reflection really obfuscated the bug, but equally code that
> deals with the extended socket options is often conditional so as to
> tolerate running on different platforms. Anyway, I thought it worth
> sharing, since it's both interesting (to me) and informative (in case
> someone else encounters similar).
Run-time argumentation of JDK modules was on the list of the 
requirements for Project Jigsaw at one point but it bring a significant 
number of surprises and may not be worth it. Right now it is limited to 
support tooling, e.g. loading the JMX agent at run-time, where it is 
mostly transparent that the augmentation is done by via a child layer.

I think there is merit is re-examining the integration of the jdk.net 
module. Not high priority but I think the "triggered registration" 
should be removed and the implemented of extended socket options should 
move to java.base, the jdk.net module should just expose the API. That 
would align with how extended open/copy options work in the 
jdk.unsupported module and the extended map mode in the jdk.nio.mapmode 
module. It would have internal mirrors for complex socket options but 
that isn't too hard to do.

Introducing a service interface and having jdk.net provide an 
implementation may be worth thinking about too. The type for many socket 
options is a boolean or integer so they could be used without needing a 
static reference to the extended socket option. I'm not saying this 
would be the best way to set/get socket options but it would allow code 
to find the socket option in the supported set and make use of it 
without a static reference, something that would help the scenario you 
outline where a library is supported across a range of releases and 
doesn't want to make use of MR JARs.

-Alan