On Thu, 3 Feb 2022 21:30:59 GMT, Sean Mullan <mul...@openjdk.org> wrote:
> > > On a related issue, have you given any thought as to what the behavior > > > should be if a 3rd-party JSSE provider is not updated to support these > > > new methods? I don't know of a good way to address that since the API is > > > not part of the provider implementation. We need a way to query what > > > parameters a given provider supports, I think. > > > > > > It's a good question. A 3rd party provider need to support to the new APIs. > > Otherwise, the spec does not really work except to use the default values. > > It might be overweighted if the Java SE API has to detect the > > implementation details. > > Fair point. However, I think then we have to make some changes to the > specification wording that state that these new methods depend on support > from the underlying provider. In other words something like > `SSLParameters.setSignatureSchemes(new String[] {"ecdsa_secp521r1_sha512"})` > could be silently ignored if the provider doesn't support the new method. > It's unfortunate because a developer may miss this point or it may go > undetected, whereas throwing an `UnsupportedOperationException` would > probably be detected (but which won't work for this API). I do note that > previous methods we have added to SSLParameters have probably had this same > issue. But I think we should try to address it better with these methods. > I'll suggest some wording changes. > > To help reduce this potential issue, we can make sure we mention this issue > in the release notes, and encourage 3rd party providers to add support for > these methods when they add support for JDK 18. > > Open to other ideas though. Good points. I will try to add an apiNote. ------------- PR: https://git.openjdk.java.net/jdk/pull/7252