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

Sean Mullan mullan at openjdk.java.net
Mon May 16 13:31:50 UTC 2022


On Fri, 13 May 2022 20:58:16 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Signature.java line 1012:
>> 
>>> 1010:      * values used by the underlying signature scheme. If the required
>>> 1011:      * parameters were not supplied and can be generated by the signature,
>>> 1012:      * the generated parameters are returned. However, if the signature scheme
>> 
>> I think one small addition to the 2nd sentence would help to cover the case where null is returned if params were not set and the impl does not generate params (regardless as to whether it supports returning them as `AlgorithmParameters`): "If the required parameters were not supplied and can be generated by the signature, the generated parameters are returned; otherwise `null` is returned."
>
> With this modification of 2nd sentence. The whole paragraph becomes:
> 
>      * <p>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. However, if the signature scheme does not support returning
>      * the parameters as {@code AlgorithmParameters}, {@code null} is always
>      * returned.
> 
> For the last sentence, would it be better to use "also" instead of "always"?

I think "also" would not be quite right, because I would read that as there is something else that is also returned with `null`. I think you can remove the word "always" -- it isn't really necessary and that might address your concern.

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

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



More information about the security-dev mailing list