RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

[Patrick Concannon]

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.Bateman at oracle.com 
>> <mailto:Alan.Bateman at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200409/5f23f81d/attachment.htm>