Details

    • Type: Bug
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 12
    • Fix Version/s: tbd
    • Component/s: core-libs
    • Labels:
      None

      Description

      There are package-private dependencies between (Server)Socket and
      SocketImpl that result in complications and difficulties when writing a
      custom SocketImpl.

      SocketImpl has two package-private methods ( setSocket and
      setServerSocket ) for setting the (Server)Socket that the impl is
      associated with. There are also a pair of getters, but these are not
      used by either of Socket or ServerSocket. The setters add a cyclic
      dependency between the instances so that the socket may invoke methods
      of the impl, and the impl may invoke methods of the socket. This of
      course causes issues for custom socket impls outside of the java.net
      package.

      FTR these package-private entanglements were introduced to resolve a
      compatibility issue with "old" ( pre unconnected sockets ) style socket
      impls back in 2001, see JDK-4468846 and JDK-4468805.

      Some advise that may help workaround this issue:

      1) Take control of construction.

        In many cases a suitable factory may be used to create and return an
        instance of a (Server)Socket that is backed by a custom impl. Use one
        of the protected constructors that accepts a SocketImpl. That way
        the impl given to either the ServerSocket or Socket constructor will
        have knowledge a priori whether, or not, the impl will be associated
        with a client socket or server socket. Create a separate subclass for
        each of client-socket-impl and server-socket-impl.

      2) Override SocketImpl getOption, setOption, and supportedOptions.

        Given 1 above, custom client or server socket impls may return an
        appropriate set of supported socket options from the supportedOptions
        method. Similarly, get and set Options can validate the given option
        from said set.
          This is necessary as the default SocketImpl code that deals with socket
        options makes use of the value that may have been set by the package-
        private set(Server)Socket method, which is not available to custom
        impls.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                chegar Chris Hegarty
                Reporter:
                chegar Chris Hegarty
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: