Thanks for your reply Alan > On 6 Aug 2022, at 08:43, Alan Bateman <[email protected]> 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
