RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

[Bradford Wetmore]

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?

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.

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.

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