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

[Sean Mullan]

On Thu, 12 May 2022 19:45:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> 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 `setParameter` 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.

I think it is a special case that should be specified. Theoretically, it could also occur if params were not supplied by the caller, but the implementation generated parameters and then could not return them as AlgorithmParameters. I think the underlying issue is that not all Signature algorithms should be required to support an encoded form of the parameters.

It is hard to fit all of these cases in a couple of sentences. I would be more inclined to add something like the following after the two sentences you currently have: "However, if the underlying implementation does not support returning the parameters as `AlgorithmParameters`, `null` is always returned."

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

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