On Thu, 21 Apr 2022 23:31:37 GMT, Valerie Peng <valer...@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
