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