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

[Valerie Peng]

On Tue, 26 Apr 2022 14:59:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Undo un-intentional changes.
>
> src/java.base/share/classes/java/security/Signature.java line 1015:
> 
>> 1013:      * parameters were not supplied and the underlying signature implementation
>> 1014:      * can generate the parameter values, it will be returned. Otherwise,
>> 1015:      * {@code null} is returned.
> 
> If we cannot guarantee anything but just want to clarify. how about just say "The returned parameters is a combination of user-provided values, implementation default values, and/or random values used by the underlying signature implementation. It can also be {@code null} if there's none."
> 
> I assume that if a value is necessary but user has not provided one, then there will be a default or a random one.

I searched about "and/or" and it is said that "or" covers "and". So, "and/or" should just be "or".

I am on the fence for requiring provider to generate default parameters (using provider-specific or random values). Could there be scenarios where users are required to supply parameters? 
That aside, this javadoc is lastly updated by JDK-8243424. It seems that JDK's EdDSA signature impl has some interesting usage of AlgorithmParameterSpec which this javadoc has to cover/allow.

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

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