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

[Xue-Lei Andrew Fan]

On Thu, 28 Apr 2022 04:44:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>>> > What does it refer to with 'it'? Is 'it' refer to the implementation generated parameter values?
>>> 
>>> 'It' refers to the parameters containing all of the parameter values including the supplied ones and provider-generated ones if any.
>> 
>> The full sentence is, "If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned."   As there is no supplied value, I think 'it' refer to the provider-generated ones if any.  As the previous noun is "the parameters values", I'm not sure if the use of 'it' here is properly.
>
>> Can you clarify what is the A and B that you are referring to?
> 
> The sentence is, “If the required parameters were not supplied and the underlying signature implementation can generate the parameter values, it will be returned. Otherwise, {https://github.com/code null} is returned."
> 
> I read "the required parameters were not supplied" as condition A; and "the underlying signature implementation can generate the parameter values" as condition B.

> With Signature class, there is a caveat for EdDSA, the supplied parameters are set but null is being returned when getParameters() is called. This is currently covered by the condition `if the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}` as the underlying signature does not support AlgorithmParameters for the supplied EdDSAParameterSpec object due to lack of ASN.1 definition.

I see now.  My 1st read of the condition, I did not get the point and thought it is not necessary as the method is trying to return "AlgorithmParameters".  Could it be more clear if describe this case in an additional sentence?

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

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