RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
Xuelei Fan
xuelei.fan at oracle.com
Fri Mar 1 16:27:47 UTC 2019
On 2/28/2019 4:26 PM, Bradford Wetmore wrote:
> AbstractDelegateHttpsURLConnection.java
> ---------------------------------------
> 74/88/etc. I haven't checked for sure, but IIRC we made setNewClient
> public from protected and other such changes in order for these classes
> to use the delegation model and allow calls to both sun/net/www/protocol
> and com/sun/net/ssl/internal/www/protocol... Should the delegation code
> be stripped out, and these methods be set back to protected?
>
It should be safe to use "protected", but it's less risky to keep it
unchanged. I agree that the delegation code should be stripped out.
The HttpsURLConnection implementation could be re-designed. I filed a
new bug to track the enhancement (JDK-8219987).
> ProviderConfig.java
> -------------------
> I think we're over-rotating on this one, I'd be very surprised if anyone
> is still using com.sun.net.ssl.internal.ssl.Provider. My personal
> preference is to kill it now, but if you really want to keep it, please
> file a bug and commit to a near release so we can finally kill this
> thing off.
>
I would like do it later as the old java.security use this string, and
I'm not sure if someone really use it in their application. It is safer
to fix in a separate bug. I filled a new bug to tack the update
(JDK-8219989).
> test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
> test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
> --------------------------------------------------------------------
> When we opensourced the JSSE code, we left some of the javax and com
> tests in the com/sun/net/ssl test directory. The test names are very
> similar, with the exception of the Com/Javax prefix. The tests were
> identical, with the exception of whether they called into the com or
> javax APIs.
>
> Here you are deleting the ComTrustManagerFactoryImpl test which is
> probably correct, but should you also be deleting the
> JavaxTrustManagerFactoryImpl test as well? Please check that we didn't
> get too carried away and are deleting still valid tests.
>
They are helper classes and used by ProviderTest, which is used to test
the com.sun.net.ssl wrappers.
Thanks,
Xuelei
> Thanks,
>
> Brad
>
>
> On 2/26/2019 7:33 AM, Chris Hegarty wrote:
>>
>>> On 26 Feb 2019, at 03:53, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> <Loop in net-dev>
>>>
>>> It makes sense to me to leave the AbstractDelegateHttpsURLConnection
>>> methods as public. We may need to re-org the code later, but it is
>>> out of the scope of this update.
>>>
>>> Here is the new webrev (only AbstractDelegateHttpsURLConnection
>>> updated):
>>> http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
>>
>> I think that this is probably ok ( since the package is not exported ),
>> but it seems a little distasteful to not have the API move through
>> the terminal deprecation route before being removed.
>>
>> -Chris.
>>
More information about the security-dev
mailing list