JDK-8230211 : Prepare DatagramSocket for alternative DatagramSocketImpl
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-08-27
  • Updated: 2020-05-18
  • Resolved: 2020-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15Fixed
Related Reports
Blocks :  
JDK-8233319 - Deprecate MulticastSocket methods that operate on java.net.InetAddress
Blocks :  
JDK-8235141 - Specify the required standard socket options for the socket types in the java.net package
Blocks :  
JDK-8236246 - SelectorProvider support for creating a DatagramChannel that is not interruptible
Blocks :  
JDK-8236184 - (dc) IP_MULTICAST_* and IP_TOS socket options not effective
Blocks :  
JDK-8234148 - DatagramSocket.setOption/getOption/supportedOption should support multicast options
Blocks :  
JDK-8233435 - (dc) DatagramChannel should allow IPv6 socket join IPv4 multicast groups (macOS, win)
Blocks :  
JDK-8234103 - DatagramSocketImpl::socket is not needed
Blocks :  
JDK-8233307 - MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set
Blocks :  
JDK-8233296 - MulticastSocket getOption/setOption inverts the value of IP_MULTICAST_LOOP
Blocks :  
JDK-8233141 - DatagramSocket.send doesn't specify exception thrown when no target address
Blocks :  
JDK-8232673 - (dc) DatagramChannel socket adaptor issues
Blocks :  
JDK-8222829 - DatagramSocket.setSoTimeout does not specify IAE when timeout is negative
Blocks :  
JDK-8146298 - (dc spec) connect and disconnect methods should specify that they may block
Blocks :  
JDK-8230946 - Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel
Blocks :  
JDK-8235783 - DatagramSocket::connect and DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException
Blocks :  
JDK-8236105 - Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent
Blocks :  
JDK-8234083 - DatagramSocket should report SO_BROADCAST as a supported option
Blocks :  
JDK-8233860 - java/net/SocketOption/AfterClose.java test incorrectly handles IP_MULTICAST_IF
Blocks :  
JDK-8233191 - MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set
Blocks :  
JDK-8231570 - (dc) Clarify implicit bind behavior of DatagramChannel
Blocks :  
JDK-8231260 - (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)
Blocks :  
JDK-8231259 - (dc) DatagramChannel::disconnect re-binds socket to the wildcard address (macOS)
Blocks :  
JDK-8236925 - (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket
Relates :  
JDK-7141822 - java/nio/channels/DatagramChannel/ChangingAddress.java failing on OS X
Relates :  
JDK-7143960 - java/net/DatagramSocket/SendDatagramToBadAddress.java is failing on Mac OS X
Relates :  
JDK-8243488 - Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket
Relates :  
JDK-8234103 - DatagramSocketImpl::socket is not needed
Relates :  
JDK-8235674 - JEP 373: Reimplement the Legacy DatagramSocket API
Relates :  
JDK-8239355 - (dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)
Description
Evaluate how java.net.DatagramSocket can be simplified to make it a lot easier to replace the underlying implementation. 
Among other things, the following should be considered and evaluated:

1. Drop the support for DatagramSocketImpl implementations that are compiled with JDK 1.3 or older.

2. Drop the filtering when the DatagramSocket is connected. Instead, DatagramSocketImpl.connect should flush the read queue after the address association is setup.

3. Change DatagramSocket.recieve so that the security manager case when not connected always receives into a temporary buffer. This will eliminate the need to peek ahead.

Other preparatory work that could make it easier to provide an alternative implementation should also be considered.
Comments
Fixed as part of JDK-8241072
18-05-2020
If the DatagramSocket wrapper is changed to no longer ever call peek and peekData, it could be a good move to still modify the API documentation of DatagramSocketImpl to allow those methods to throw UnsupportedOperationException, and maybe deprecate them as well.
04-09-2019
So, the assumption is that since the plain-DatagramSocketImpl is not accessible to user code ( it is confined within DatagramSocket ) that it does not have to adhere to the DatagramSocketImpl specification for peek and peekData, right?
04-09-2019
I don't think the DatagramSocketImpl spec will need to be updated, except to clarify how connect can behave when there are datagrams in the read queue. The platform DatagramSocketImpl is internal to the JDK, it should never leak to user code.
04-09-2019
DatagramSocketImpl::peek and DatagramSocketImpl::peekData are public Java SE API's - whether or not their implementation is needed by java.net.DatagramSocket is not the only issue. If these methods are to be optionally implemented, their specification will have to be updated to reflect that.
04-09-2019
Just on point 4, once DatagramSocket is updated then it should not need to use the impl's peek or peekData implementations.
30-08-2019
A few notes, before I forget: 1) DatagramSocketImpl::connect ( and disconnect ) was added in Java 1.4 2) The emulation of connect, in DatagramSocket, is ( at least in part ) due to the fact that the impl may not support connect ( if it was compiled with a JDK less than 1.4 ) 3) If/When support for pre-1.4 impl's is removed, and if connect emulation is also removed, then the DatagramSocket implementation ( and maybe the constructor/connect specification also ) should be updated to actively disallow its creation with a pre-1.4 impl ( or some such change that will not allow a connect call to complete successfully, when it may be ineffectual ). 4) DatagramSocketImpl has API support for peeking, through peek(InetAddress) AND peekData(DatagramPacket). Maybe a new NIO based impl will need new ( currently-does-not-currently-exist ) support in the internal NIO implementation, since DatagramChannel doesn't need it.
30-08-2019