[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-net-dev
Subject:    Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket
From:       Chris Hegarty <chris.hegarty () oracle ! com>
Date:       2020-01-16 12:42:51
Message-ID: F5FA8EB5-65F7-4E81-A962-C41FF015E54B () oracle ! com
[Download RAW message or body]


> On 16 Jan 2020, at 12:10, Alan Bateman <Alan.Bateman@oracle.com> wrote:
> 
> On 16/01/2020 11:45, Chris Hegarty wrote:
> > > 
> > Generally, I agree with updating the socket adapter to support
> > multicast. It will certainly help with future work in this area.
> > 
> > The instanceof checks in the constructors highlight that there is an
> > abstraction missing here - to support creating a custom MulticastSocket
> > implementation. If / When DatagramSocketImpl is deprecated, the advise
> > will likely be to subclass MulticastSocket if one wants to provide a
> > custom implementation. I believe that this cannot be done efficiently
> > with the current API - and that is the issue that this change is running
> > into that results in the instanceof checks in the constructors.
> The main API issues date back to choices made in JDK 1.0 but it's not clear to me \
> that it's worth trying to fix them now.

The extensibility point of these APIs is DatagramSocketImpl, which was
probably a reasonable design choice back in 1995.

> The extensibility could have been looked in JDK 1.4 when the protected constructor \
> was added but even then,

Again, it appears that the design choice for significant extensibility 
is through the DatagramSocketImpl - not withstanding several oversights
regarding compatible evolution of the decoupled socket types and the
impl type.

> it's not clear that there was any interest in completely different implementations \
> outside of the JDK.

True, but if DatagramSocketImpl is degraded, then there should be a
viable alternative.

> So if someone really wants to this now then they could create a DatagramSocketImpl \
> and use the factory method to set it system-wide. I don't think we've ever seen \
> anyone do that, maybe because that mechanism is very under specified, maybe because \
> it would require accessing the internal representation of FileDescriptor and \
> DatagramPacket. If that mechanism is deprecated and eventually removed (which is \
> probably the right thing to do) then the only choice would be to extend and \
> override all methods.

Agreed. And then one runs straight into the same issue that is resulting
in the instanceof checks - how can MulticastSocket be extended without
triggering the creation of a built-in implementation? I'm saying that it
is not (easily?) possible with the current API - hence the ugly
instanceof some-internal-type checks (which non-JDK code cannot do).

> Yes, I agree the check for the sub-class is ugly. The legacy implementation also \
> has to check if it's a MulticastSocket so that the right impl is chosen.

It's selecting an implementation based on its own known public API
hierarchy, which seems reasonable.

My intention is to highlight the missing design abstraction with the
MulticastSocket API ( as I see it when grok'ing the instanceof checks),
rather than getting in the way of this particular change, so I have
filed a separate issue to track that [1].

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8237352
   Evaluate how to write a custom MulticastSocket without using DatagramSocketImpl


[prev in list] [next in list] [prev in thread] [next in thread]