Extended socket options and module layers

[Chris]

Thanks for your reply Alan

> On 6 Aug 2022, at 08:43, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/08/2022 20:43, Chris Hegarty wrote:
> …
> 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.

That sounds very reasonable.

> 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,

+1

> 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.

Thankfully we’re past that now, and have rewritten our code to remove the use of reflection.

-Chris