On Thu, 21 Apr 2022 23:15:10 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>>> 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.
>>
>> I like this first sentence.
>>
>>> > If no parameters
>>> > * is supplied and this cipher successfully generated the required
>>> > * parameter values, it will be returned.
>>
>> What does "successfully" mean? If it wasn't successful, what happens? Maybe
>> we should avoid that word. How about:
>>
>> "If parameters were not supplied and this cipher requires parameters, the
>> returned parameters will contain the parameter values generated by the
>> underlying cipher implementation."
>>
>>> > 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.
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8117
