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