[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    Re: Extended socket options and module layers
From:       Chris <chegar999 () gmail ! com>
Date:       2022-08-09 8:22:27
Message-ID: F805F534-F018-4171-A6C9-78E05C54E8D7 () gmail ! com
[Download RAW message or body]

Thanks for your reply Alan

> On 6 Aug 2022, at 08:43, Alan Bateman <Alan.Bateman@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=


[prev in list] [next in list] [prev in thread] [next in thread]