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

[Sean Mullan]

On Wed, 11 May 2022 22:12:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/SignatureSpi.java line 399:
>> 
>>> 397:      * values used by the underlying signature scheme. If the required
>>> 398:      * parameters were not supplied and can be generated by the signature,
>>> 399:      * the generated parameters will be returned. Otherwise, {@code null}
>> 
>> Minor wording nit - change "will be" to "are" to be consistent with other wording which uses the present tense. Same comment applies to `Signature.getParameters`.
>> 
>> Also, do we no longer need to mention the part "and the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}"?
>
> 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.

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

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