RFR 8216978: Drop support for pre JDK 1.4 SocketImpl implementations

Michael McMahon michael.x.mcmahon at oracle.com
Mon Apr 29 17:07:59 UTC 2019


On 29/04/2019, 12:17, Alan Bateman wrote:
> On 29/04/2019 10:52, Michael McMahon wrote:
>> Hi,
>>
>> This is another change which is part of the general cleanup of 
>> SocketImpls.
>> The change removes support for pre JDK 1.4 socketimpls which do not 
>> implement
>> the timed connect method. These SocketImpls have not been compilable
>> since 1.4 and limited runtime support has been provided since then, 
>> which is now being removed.
>>
>> Webrev
>> -------
>> http://cr.openjdk.java.net/~michaelm/8216978/webrev.1/
>>
> This is a good cleanup.
>
> 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.
>
> I don't think AbstractPlainSocketImpl.isBound needs to be volatile as 
> it is guarded by the synchronization on the impl (the doConnect and 
> bind methods are synchronized).
>
ok
> The Windows version of PlainSocketImpl shouldn't need the constructor 
> to be public (I see the Unix version is package-private).
>
ok
> Should we use the opportunity to add something to the javadoc for the 
> SocketImpl constructor so it's not empty? It can be as simple as 
> "Initialize a new instance of this class" as used in other places 
> where there isn't anything to say.
>
The empty comment block looks odd I admit. It was needed to make it 
build and I left it empty so that
the generated apidoc would not change. However, I guess I can add the 
above suggestion to the CSR

Thanks,

Michael


More information about the net-dev mailing list