JEP 373: Reimplement the Legacy DatagramSocket API

Last week, a new Java enhancement proposal (JEP) from Oracle Staff Engineer Daniel Fuchs was given candidate status: JEP 373. As yet it doesn’t target a specific JDK, but since it has been given an S for how much effort it will take, it seems like it probably has a decent shot at JDK 15 later this year. The aim of the JEP is to replace the existing implementations of the java.net.DatagramSocket and java.net.MulticastSocket APIs with updated versions that are easier to maintain and debug than the existing implementations.

This is related to JEP 353, which reimplemented the legacy Socket API in JDK 13, and will be easy to adapt to work with the virtual threads being considered in Project Loom.

JEP 373: Reimplement the Legacy DatagramSocket API

As Fuchs puts it, “the code base of the java.net.DatagramSocket and java.net.MulticastSocket APIs, and their underlying implementations, is old and brittle.” So old, in fact, that they date back to JDK 1.0—talk about a blast from the past! As a result, the code is a mixture of legacy Java and C, making it tough to maintain. Additionally, the implementation of java.net.MulticastSocket causes plenty of problems on its own because it dates back to a time when IPv6 was still in development, meaning that it tries to reconcile IPv4 and IPv6 in ways that are “difficult to maintain”. There are also concurrency issues that can only be fixed with a complete overhaul.

SEE ALSO: JEP 371 – Hidden Classes in Java

Furthermore, Fuchs writes, “in the context virtual threads that park rather than block underlying kernel threads in system calls, the current implementation is not fit for purpose. As datagram-based transports gain traction again (e.g. QUIC), a simpler and more maintainable implementation is needed.”

JEP Details

Since it gets a bit technical here, I’ll let Daniel Fuchs do the talking:

Currently, the DatagramSocket and MulticastSocket classes delegate all socket calls to a java.net.DatagramSocketImpl implementation, for which different platform-specific concrete implementations exist: PlainDatagramSocketImpl on Unix platforms, and TwoStackPlainDatagramSocketImpl and DualPlainDatagramSocketImpl on Windows platforms. The abstract DatagramSocketImpl class, which dates back to JDK 1.1, is very under-specified and contains several obsolete methods that are an impediment to providing an implementation of this class based on NIO (see alternatives, discussed below).

SEE ALSO: JEP 372 – Remove the Nashorn JavaScript Engine

Rather than provide a drop-in replacement for implementations of DatagramSocketImpl, similar to what was done in JEP 353 for SocketImpl, this JEP proposes to make DatagramSocket internally wrap another instance of DatagramSocket to which it delegates all calls directly. The wrapped instance is either a socket adapter created from a NIO DatagramChannel::socket (the new implementation), or else a clone of the legacy DatagramSocket class which then delegates to the legacy DatagramSocketImpl implementation (for the purpose of implementing a backward compatibility switch). If a DatagramSocketImplFactory is installed by an application, the old legacy implementation is selected. Otherwise, the new implementation is selected and used by default.

For starters, the old implementation won’t be removed; jdk.net.usePlainDatagramSocketImpl would configure the JDK to use the legacy implementation. But the default implementation would be the new one otherwise. In the future it’s possible that the legacy implementations will be deprecated and removed, but that’s not the plan for the moment.

For more information, check out JEP 373 here.

The post JEP 373: Reimplement the Legacy DatagramSocket API appeared first on JAXenter.