RFR: 8209038: Clarify the javadoc of Cipher.getParameters() [v2]

[Sean Mullan]

On Thu, 21 Apr 2022 23:31:37 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>>> > Hmm, I tried the suggested approach in (1), the result looks very lengthy. Actually, the Cipher.init(..) methods already has a few paragraphs describing the behavior for parameter generation, perhaps we should not repeat stating the "If this cipher was initialized" vs "was not initialized" since lengthy description may confuse users and have higher risks of inconsistency. What do you think?
>>> 
>>> That's a good point, the `init` methods do go into a lot of detail about that.
>>> 
>>> > As for (2), currently only RSASSA-PSS signature impl uses parameters. When specified using PSSParameterSpec, it's possible that some of the parameters are not set, so it's possible for providers to use provider-specific default values for PSS case. So, yes, Signature class may have to updated in the same way to cover this particular scenario.
>>> 
>>> Ok, I think we should try to make the spec consistent across `Cipher` and `Signature` once we settle on the right wording. I think it would be better to do it as part of this issue, but I would be ok doing it later as long as it is also fixed in 19.
>> 
>> I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also.
>
> As for the 2nd sentence, it boils down whether we requires provider to generate default parameters and return it when parameter is required. Existing javadoc states that null is returned when parameter is not required. Given Cipher covers many algorithms, if a provider does not want to generate a default parameter when parameter is required, it can't return null when getParameters() is called.

> I can do the Signature update through https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to fix in 19 also.

Ok.

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

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