On Thu, 12 May 2022 19:45:37 GMT, Valerie Peng <valer...@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
