On Fri, 13 May 2022 14:35:56 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> Hmm, would it fall under the "Otherwise, null is returned"? If not, perhaps >> we can add back the part about returning AlgorithmParameters as below: >> >> **If the underlying signature implementation supports returning the >> parameters as {@code AlgorithmParameters},** 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 scheme. If the required parameters >> were not supplied and can be generated by the signature, the generated >> parameters are returned. Otherwise, {@code null} is returned. > > I think it is a special case that should be specified. Theoretically, it > could also occur if params were not supplied by the caller, but the > implementation generated parameters and then could not return them as > AlgorithmParameters. I think the underlying issue is that not all Signature > algorithms should be required to support an encoded form of the parameters. > > It is hard to fit all of these cases in a couple of sentences. I would be > more inclined to add something like the following after the two sentences you > currently have: "However, if the underlying implementation does not support > returning the parameters as `AlgorithmParameters`, `null` is always returned." Yes, I agree that it's a special case as the convention is to define the parameter spec class based on the ASN.1 structure. I like your suggestion better also. Will update using it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8396