RFR 8216978: Drop support for pre JDK 1.4 SocketImpl implementations
Michael McMahon
michael.x.mcmahon at oracle.com
Mon Apr 29 16:47:49 UTC 2019
On 29/04/2019, 17:35, David Lloyd wrote:
> On Mon, Apr 29, 2019 at 10:54 AM Michael McMahon
> <michael.x.mcmahon at oracle.com> wrote:
>>
>>
>> On 29/04/2019, 13:08, Chris Hegarty wrote:
>>> On 29/04/2019 12:17, Alan Bateman wrote:
>>>> ...
>>>> Changing SIS.close and SOS.close to caller super.close raises a
>>>> number of questions. These close should never be called
>>>> Socket.getInputStream and getOutputStream don't leak these streams to
>>>> user code (they used to but now in JDK 13). My concern is that if
>>>> they were ever to be called then it will be calling the FIS/FOS close
>>>> methods which brings along a several questions on it interacts with
>>>> the cleaner mechanism used by those classes.
>>> Since 8220493, these socket in/out stream close methods are effectively
>>> no longer in charge of closing the socket ( since that will happen from
>>> the outer stream wrapper in Socket ). I wonder if they should simply
>>> call impl.close()?
>>>
>> On that point. Since it might not be obvious that SIS.close and
>> SOS.close are no longer used,
>> it might be more useful to just replace the close implementations with a
>> comment and an assertion
>> which underlines that fact.
> As someone who does a lot of socket programming (albeit mostly
> non-blocking), I would be *shocked* if closing a socket input or
> output stream didn't translate into shutting down input or output
> (respectively). Not close per se but socket shutdown.
It still ends up as a close of the socket's file descriptor at the OS level
one way or the other. Closing a socket's InputStream or OutputStream
never resulted in a shutdown() call to the OS. If you want socket shutdown
then you need to call shutdownInput() or shutdownOutput API on
j.n.Socket directly.
- Michael.
More information about the net-dev
mailing list