Hi Alan, One more question please :) I want to make sure I understand correctly on your following suggestion. In order to use supportedOptions method to test SO_REUSEPORT, I will need to first write a native function to check if SO_REUSEPORT is supported. Then, in the defaultOptions method, I do a conditional add for StandardSocketOptions.SO_REUSEPORT if it is supported on the platform? Is this a preferred way to implement? Please let me know!
The other thing to be aware of is that setOption/getOption methods are specified to throw UOE when invoked to set/get a socket option that is not supported by the implementation. This will also help with the tests as you will be able to use the supportedOptions method to test if a socket option is supported, no need to parse exception messages. Thanks very much, Lucy From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Sunday, November 22, 2015 12:25 AM To: Lu, Yingqi <yingqi...@intel.com>; Kharbas, Kishor <kishor.khar...@intel.com>; net-dev@openjdk.java.net Subject: Re: Patch for adding SO_REUSEPORT socket option On 21/11/2015 02:08, Lu, Yingqi wrote: Hi Alan, Please let me know if there is anything we can do at the meantime to help. We are more than happy to help. Sorry, I wasn't clear. I meant that you will need to work on the javadoc. In many of the classes you've added the following to the spec: "In case of Windows and Solaris, this function should throw SocketException with message "Invalid option". In case of Linux with 3.8 and older kernel, this founction should throw SocketException with message "Protocol not available"." but this is implementation specific, maybe even locale specific too. So I think it's best to start with java.net.StandardSocketOptions and try to get agreement on how the socket option is specified. You should also get familiar with the API tags to distinguish specification and implementation [1]. Once there is agreement on StandardSocketOptions then the javadoc for the java.net set/get methods should be straight-forward. For the NetworkChannels (SocketChannel, etc) then you might consider just dropping it from the javadoc. The reason is that these tables are the socket options that are supported by all implementations and this is not the case here. Instead you can leave to the implementation, which is okay because NetworkChannels allow for socket options beyond those listed in the tables. The other thing to be aware of is that setOption/getOption methods are specified to throw UOE when invoked to set/get a socket option that is not supported by the implementation. This will also help with the tests as you will be able to use the supportedOptions method to test if a socket option is supported, no need to parse exception messages. -Alan. [1] http://openjdk.java.net/jeps/8068562
