> On 31 Oct 2018, at 20:03, Xuelei Fan <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.
