On Wed, 2 Feb 2022 22:41:56 GMT, Xue-Lei Andrew Fan <xue...@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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7252
