Hi,
Alan - I've gone through your comments and refactored the code
accordingly. I spoke with Daniel about the SendBufCheck test, and he
wants to keep this in the JEP as it allows to compare the behavior of
all the different implementations in one place.
Chris - Thanks for opening issue JDK-8241988
<https://bugs.openjdk.java.net/browse/JDK-8241988> and looking after it.
I've incorporated the other changes you requested into the new webrev
below.
I've also updated several tests and included an additional test to
increase the test coverage for both the old and new implementations of
DatagramSocket.
webrev: http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.03/
Kind regards,
Patrick
On 01/04/2020 12:03, Chris Hegarty wrote:
On 31 Mar 2020, at 18:46, Alan Bateman <alan.bate...@oracle.com
<mailto:alan.bate...@oracle.com>> wrote:
On 31/03/2020 18:27, Chris Hegarty wrote:
:
- In DatagramSocket::createDelegate, "enable broadcast if possible”
- Possibly due to refactoring, but I cannot reconcile this with the
old implementation.
DatagramSocket is specified to make a best attempt to enable this
option so I think it's in the right place. At a clean-up, the attempt
in PDSI.datagramSocketCreate could be removed.
Ok, that explains why it was difficult to reconcile in the webrev.
I now see that “best-effort” is not implemented on unix platforms, but
rather fail-fast ( an exception is thrown if the option cannot be set
). Let’s just remove this now superfluous native code as it is confusing.
:
- The set of socket options is now per datagram/multicast socket
instance, rather than on the class of the socket. I don’t think that
this is an issue, just an observation and a confirmation that it is
deliberate.
The set of socket options supported by a custom DSI will likely be
different to the default impl so it needs to be an instance field. I
suspect this is a long standing bug.
Since this issue is orthogonal to the JEP, I filed the following issue
to track it:
https://bugs.openjdk.java.net/browse/JDK-8241988
-Chris.
