On 10/31/2018 8:52 AM, Chris Hegarty wrote:
Xuelei,On 30/10/18 20:55, Xuelei Fan wrote:Hi,For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs. An application may need richer information for the underlying TLS connections, for example the negotiated TLS protocol version.Please let me know if you have concerns to add a new method HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, by the end of Nov. 2, 2018.Here is the proposal: https://bugs.openjdk.java.net/browse/JDK-8213161 Thanks, XueleiThe new method looks fine. On the deprecation, minimally the annotation should contain the "since" element, which will have a value of `12`.
Hm, it looks better now if using the "since" element. Thanks!
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.Also, I wonder, now that I see the spec, whether or not it is actually a good idea to deprecate these methods. The reason I ask this is that the new method, getSSLSession, can throw UOE, which effectively makes it an optional method. Access to the specific security parameters provided by the existing methods is non-optional. This is a clear difference, and possibly a reason, for folk not interested in the "new" parameters, to continue to use the existing methods.
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.
To make it more clear, I added a implNote in the getSSLSession() method, and recommend to support it in all implementations.
I prefer to deprecate these methods a little bit more, but not very strong. If there is a strong preference, I can live with it.
BTW, I also updated the java.net.SecureCacheResponse accordingly. I'm not sure if SecureCacheResponse is really used in practice. I did not find the implementation of it in JDK.
Here is the webrev if you want to look at the implementation details:
http://cr.openjdk.java.net/~xuelei/8212261/webrev.00/
Thanks,
Xuelei
