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