CSR Review Request, JDK-8218932 Remove the internal package com.sun.net.ssl

Sean Mullan sean.mullan at oracle.com
Thu Feb 21 20:23:48 UTC 2019


On 2/20/19 10:07 PM, Xuelei Fan wrote:
> On 2/20/2019 12:21 PM, Sean Mullan wrote:
>> In the Problem section:
>>
>> "This internal package is not exported in the java.base module, and 
>> applications cannot use them directly any more."
>>
>> That's not quite true. It is not exported but strong encapsulation is 
>> not yet enabled by default at runtime so by default the APIs are still 
>> accessible. At compile time, they are not, but you can still use the 
>> --add-exports option to override that. I would explain this a bit more.
>>
> Hm, I missed this point.  I will use the 1st part of the sentence only: 
> "This internal package is not exported in the java.base module."
> 
>> Is the compatibility risk really minimal? I think there are some 
>> projects still using it, but they have had plenty of advance warning 
>> to switch. Maybe it should be low with some additional explanation.
>>
> It's low if the package still can be used by applications since JDK 9.
> 
>> Why are you adding "sun.security.ssl.SunJSSE" as a new provider name? 
>> I didn't understand why that was related to this issue or useful.
>>
> I was hesitated to add a new provider name as well.  It should be fine 
> to use "SunJSSE" without a namespace.
> 
> I updated the CSR accordingly.

Thanks, I added my name as Reviewer. I think the Compatibility Kind 
should be "Binary" since removing these APIs (even though they are 
internal) will cause existing applications using them to not link at 
runtime.

--Sean

> 
> Thanks,
> Xuelei
> 
>>
>> --Sean
>>
>>
>> On 2/13/19 4:51 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the CSR reviewed:
>>>     https://bugs.openjdk.java.net/browse/JDK-8218932
>>>
>>> The internal package com.sun.net.ssl had been deprecated since JDK 
>>> 1.4, and was not exported in the java.base module since JDK 9. 
>>> Application cannot use them directly now.  It should be safe to 
>>> remove them in JDK 13.
>>>
>>> If you are using the internal package for some reason, please let me 
>>> know the compatibility impact by the end of Feb 20, 2019.
>>>
>>> Thanks,
>>> Xuelei



More information about the security-dev mailing list