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
