On Tue, 26 Apr 2022 14:59:35 GMT, Weijun Wang <wei...@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
