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
