On Wed, 6 Apr 2022 16:00:10 GMT, Xue-Lei Andrew Fan <[email protected]> wrote:
>> Anyone can help review this javadoc update? The main change is the wording
>> for the method javadoc of
>> Cipher.getParameters()/CipherSpi.engineGetParameters(). The original wording
>> is somewhat restrictive and request is to broaden this to accommodate more
>> scenarios such as when null can be returned.
>> The rest are minor things like add {@code } to class name and null, and
>> remove redundant ".".
>>
>> Will file CSR after the review is close to being wrapped up.
>> Thanks~
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 1053:
>
>> 1051: * <p>If this cipher has been previously initialized with
>> parameters,
>> 1052: * this method returns the same parameters. Otherwise, this method
>> may
>> 1053: * return a combination of user-supplied, default and randomly
>> generated
>
>> ... a combination of user-supplied, default and randomly generated parameter
>> values ...
>
> Other than init(), which APIs could impact the user-supplied parameters? Is
> it the getInstance()?
>
> Is it OK to just use the provider-specific default values instead, by
> replacing the "a combination of user-supplied, default and randomly generated
> ..."?
I am thinking just init() as it takes parameters.
Let me take a second look at various Cipher algorithm implementations and see
if this can be further pared down.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8117
