Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8222028

Reimplement the Legacy Socket API

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 13
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      medium
    • Compatibility Risk Description:
      Hide
      It is possible that there is existing code that depends on unspecified behavior in corner cases where old and new implementations behave differently. Every effort has been made to ensure that the new implementation is compatible with the old implementation but there are a small number of differences that are detailed in the "Risks and Assumption" section of the JEP. The `jdk.net.usePlainSocketImpl` system (and network configuration file) property can be used to configure the JDK to use the old implementation and mitigate most of the behavior differences identified in the JEP.
      Show
      It is possible that there is existing code that depends on unspecified behavior in corner cases where old and new implementations behave differently. Every effort has been made to ensure that the new implementation is compatible with the old implementation but there are a small number of differences that are detailed in the "Risks and Assumption" section of the JEP. The `jdk.net.usePlainSocketImpl` system (and network configuration file) property can be used to configure the JDK to use the old implementation and mitigate most of the behavior differences identified in the JEP.
    • Interface Kind:
      System or security property
    • Scope:
      JDK

      Description

      Summary

      Replace the underlying implementation used by the java.net.Socket and java.net.ServerSocket APIs with a simpler and more modern implementation that is easy to maintain and debug. The new implementation will be easy to adapt to work with user-mode threads, a.k.a. fibers, currently being explored in Project Loom.

      Problem

      The java.net.Socket and java.net.ServerSocket APIs, and their underlying implementation, date back to JDK 1.0. The implementation is a mix of legacy Java and C code that is painful to maintain and debug. In the context of a future world of fibers that park instead of blocking threads in native methods, the current implementation is not fit for purpose.

      Solution

      The java.net.Socket and java.net.ServerSocket APIs delegate all socket operations to a java.net.SocketImpl, a Service Provider Interface (SPI) mechanism that has existed since JDK 1.0. The built-in implementation is termed the “plain” implementation, implemented by the non-public PlainSocketImpl with supporting classes SocketInputStream and SocketOutputStream.

      The new implementation, NioSocketImpl, is a drop-in replacement for PlainSocketImpl. It is developed to be easy to maintain and debug. It shares the same JDK-internal infrastructure as the New I/O (NIO) implementation so it doesn't need its own native code. It integrates with the existing buffer cache mechanism so that it doesn’t need to use the thread stack for I/O. It uses java.util.concurrent locks rather than synchronized methods so that it can play well with fibers in the future. In JDK 11, the NIO SocketChannel and the other SelectableChannel implementations were mostly re-implemented with the same goal in mind.

      To reduce the risk of switching the implementation after more than twenty years, the old implementation will not be removed. A system property is added to configure the JDK to use the old implementation. This can be used in environments where older code is found to have a dependency on unspecified behavior that differs between the old and new implementation. The property can also be set in the JDK's network configuration file for environments that cannot specify the property on the command line. Some future release will remove the old implementation and the property.

      Specification

      There are no Java SE specification changes. A number of API issues were identified during the development of this feature and these are being addressed by other issues, e.g. JDK-8219446.

      The JDK-specific system property to select the old implementation is jdk.net.usePlainSocketImpl. If set, or set to the value true, at startup, then the old implementation will be used. The property can also be set in the network configuration file ($JAVA_HOME/conf/net.properties) for end-user or other environments that are unable to set the property on the command line. If the system property is set, and also set in the network configuration file, then the system property wins.

      In addition, an implementation note will be added to the SocketImpl class description:

      @implNote Client and server sockets created with the {@code Socket} and
      {@code SocketServer} public constructors create a system-default
      {@code SocketImpl}. The JDK historically used a {@code SocketImpl}
      implementation type named "PlainSocketImpl" that has since been replaced by a
      newer implementation. The JDK continues to ship with the older implementation
      to allow code to run that depends on unspecified behavior that differs between
      the old and new implementations. The old implementation will be used if the
      Java virtual machine is started with the system property {@systemProperty
      jdk.net.usePlainSocketImpl} set to use the old implementation. It may also be
      set in the JDK's network configuration file, located in {@code
      ${java.home}/conf/net.properties}. The value of the property is the string
      representation of a boolean. If set without a value then it defaults to {@code
      true}, hence running with {@code -Djdk.net.usePlainSocketImpl} or {@code
      -Djdk.net.usePlainSocketImpl=true} will configure the Java virtual machine
      to use the old implementation. The property and old implementation will be
      removed in a future version.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                alanb Alan Bateman
                Reporter:
                alanb Alan Bateman
                Reviewed By:
                Michael McMahon
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: