I removed the deprecation parts in the update. Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.01/
And the CSR was updated accordingly.
https://bugs.openjdk.java.net/browse/JDK-8213161
Thanks,
Xuelei
On 11/1/2018 4:57 AM, Chris Hegarty wrote:
On 31 Oct 2018, at 20:03, Xuelei Fan <xuelei....@oracle.com
<mailto:xuelei....@oracle.com>> wrote:
...
Yes. I had the same concern about the optional operation. However, I
came to a different conclusion if I'm from viewpoint of these users
that need to use this new operation.
If an application have to use this new operation, for example to
access the negotiated TLS version, this operation is essential to it.
Unfortunately, because of compatibility impact, we cannot force all
implementation supports this new added operation. It is a potential
problem to those applications that need it.
It would be nice if an implementation can support this operation as
soon as possible. If we just add the operation, providers may not
aware there is a need to update their implementation. Unfortunately.
there is not much we can do to notify the provider.
If we deprecated the duplicated methods, it is easier for providers to
catch up with this new added operation, and move forward to support
it. As the deprecating will show up building warnings, or even error
if run in strict building mode.
I have no issue with the addition of the new method to access the
SSLSession. Unfortunately, due to the evolutionary constraints of this
API, the `getSSLSession` method will likely need to be specified to
throw UOE. The actual JDK's HTTPS protocol handler implementation will
not throw UOE.
Clearly there is a desire for non-JDK HTTPS protocol handler
implementations to quickly determine the need to update their code and
override the default implementation of `getSSLSession` ( to do something
useful ), hence the request to deprecate the the existing individual
security parameter accessor methods.
I don't believe that deprecating these individual security parameter
accessors is a good idea for the following reasons:
1) Deprecated warnings are only issued at compile-time, so only HTTPS
protocol handler implementations being recompiled may encounter the
warnings. Existing binary artifacts will not.
2) More importantly. Forever more, developers wanting access to say,
the peer principle or the server's certificate chain, will be
encouraged to get them through an optional API ( rather than a
non-optional API ). This increases the risk that the code will
encounter an UOE. I don't think that this increased risk is justified
by the desire to not-have-two-ways-to-do-the-same-thing. I would
agree if this were a new API, but it is not.
HTTPS protocol handler implementations actively being maintained will
likely quickly get requests from their users to provide a better
implementation of this new method, as folk move towards TLS 1.3, etc.
Maybe such requests will be sufficient to help adoption, at which point
the deprecation of these methods could then be re-considered.
-Chris.
