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