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