RFR: 8209038: Clarify the javadoc of Cipher.getParameters()
Valerie Peng
valeriep at openjdk.java.net
Wed Apr 6 19:20:42 UTC 2022
On Wed, 6 Apr 2022 15:48:26 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> 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 1051:
>
>> 1049: * Returns the parameters used with this cipher.
>> 1050: *
>> 1051: * <p>If this cipher has been previously initialized with parameters,
>
>> If this cipher has been previously initialized with parameters, this method returns the same parameters.
>
> Previously, "may" is used ("may be the same ..."). This change looks too strict for compatibility. I had a look at the AES implementation, the parameters initialized with init() could be filtered and modified before saving the parameters related class fields.
Can you be more specific like which block of code that you are referring to as the filtering and modification?
I'd expect the intention is to use the parameter specified. Otherwise an exception should be thrown if the specified parameter is invalid. Only when no parameter is specified, the provider would try to generate the parameters using whatever values it has or got.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8117
More information about the security-dev
mailing list