[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-net-dev
Subject:    Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
From:       Xuelei Fan <xuelei.fan () oracle ! com>
Date:       2019-03-01 16:27:47
Message-ID: 906d46a3-b26c-3cae-2e5a-827fbfff7435 () oracle ! com
[Download RAW message or body]

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@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.
>>
[prev in list] [next in list] [prev in thread] [next in thread]