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

[Valerie Peng]

On Wed, 27 Apr 2022 23:02:28 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Right, the user-supplied values takes precedence and provider-specific default/random values should just be supplemental.
>> 
>> As for EdDSA, looks like the prehash and context are only in RFC 8032 and NOT RFC 8410.  caller has to pass these settings/values to the other entity through some other means since the getParameters() return null as there is no ASN.1 definition for the parameters. Looks like these values are packaged into a parameter spec and passed into the underlying EdDSA signature implementation in order to fit into existing API without adding new algorithm specific APIs.
>
> So, "the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}" is quite necessary. Xuelei's suggestion is quite good, just change the last "and" to "or".

I assume you were suggesting this? `"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 implementation. {https://github.com/code null} is returned if the required parameters were not supplied and the underlying signature implementation cannot generate the parameter values."`
But the "the underlying signature implementation supports returning the parameters as {https://github.com/code AlgorithmParameters}" is necessary. Strictly speaking, this is somewhat different than the "cannot generate parameter values" though. Perhaps we should go a bit broader for the last sentence regarding null return value?

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

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