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

[Xuelei Fan]

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,
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