On Thu, 3 Feb 2022 21:30:59 GMT, Sean Mullan <[email protected]> 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
