On Tue, 19 Apr 2022 02:44:01 GMT, Valerie Peng <[email protected]> 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?
>> 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.
>
> For (1), how about something like below:
>
>> * <p>The returned parameters may be the same that were used to
>> initialize
>> * this cipher, or may contain additional default or random parameter
>> * values used by the underlying cipher implementation. If no parameters
>> * is supplied and this cipher successfully generated the required
>> * parameter values, it will be returned. Otherwise, {@code null} is
>> * returned.
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8117
