On Fri, 28 Jan 2022 15:17:28 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Copyright correction > > src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 710: > >> 708: * Signature Schemes</a> section of the Java Cryptography >> 709: * Architecture Standard Algorithm Name Documentation, and may also >> 710: * include other signature schemes that the provider supports. > > There doesn't seem to be anything preventing a user from setting a bogus > signature scheme (ex: named "foo") - which is neither a standard name or a > provider specific name. > I think the method may be too tightly specified, and you should make this > more general and not put any constraints on the names of the signature > schemes. (Although we should still link to the specification for a list of > standard names). > > It would be useful to explain when this method returns pre-populated scheme > names as supported by the underlying provider and when it may return an empty > list. You should also define the interaction with the system properties (probably as an @implNote). Does `getSignatureSchemes` ever return the value of the system properties? Does the `setSignatureSchemes` API always override the properties even if it is called by the provider? ------------- PR: https://git.openjdk.java.net/jdk/pull/7252
