RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v4]

Valerie Peng valeriep at openjdk.java.net
Thu May 12 19:48:54 UTC 2022


On Thu, 12 May 2022 18:23:18 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Fixed the nit. Thanks~
>> As for the part about returning the parameters as `{@code AlgorithmParameters}`, it should be covered by current sentence, i.e. `and can be generated by the signature`. Perhaps we don't have to spell out all possible causes where the parameter can't be generated?
>
> That sentence is specifically if the caller did not specify parameters though. The previous wording is if the caller did specify parameters (as say an `AlgorithmParameterSpec`) and the implementation cannot return them as `AlgorithmParameters`. So I think it needs to be mentioned as it is kind of surprising if you specify parameters to `init` but `getParameters` returns null.

Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps we can add back the part about returning AlgorithmParameters as below:

**If the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters},** the returned parameters may be the same that were used to initialize
 this signature, or may contain additional default or random parameter values used by the underlying signature scheme. If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned. Otherwise, {@code null} is returned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8396



More information about the security-dev mailing list