RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]
Xue-Lei Andrew Fan
xuelei at openjdk.java.net
Wed May 4 04:20:15 UTC 2022
On Mon, 2 May 2022 21:42:28 GMT, Valerie Peng <valeriep at openjdk.org> wrote:
>>> What kind of additional sentence do you have in mind?
>>
>> It may be fine to put it into the state for 'null" returned value. For example:
>>
>>
>> The returned parameters may be the same that were used to initialize
>> this signature, or may contain additional default or random parameter
>> values used by the underlying signature implementation, or null if the
>> underlying signature implementation does not support returning the
>> parameters as {@code AlgorithmParameters}.
>>
>>
>>
>> The null return conditional in the following sentence may be able to combine together.
>>
>>
>> The returned parameters may be the same that were used to initialize
>> this signature, or may contain additional default or random parameter
>> values used by the underlying signature implementation. {@code null}
>> may be returned if the underlying signature implementation does not
>> support returning the parameters as {@code AlgorithmParameters}, or <more conditions>
>
> How about the case when no parameters are given? Say A is the user-supplied values, B is the provider specific default or random values, your suggestion has A, A+B, and null. Isn't the sentence about B needed (no A and provider can generate the parameters)?
I think this sentence covers case B, "... or may contain additional default or random parameter
values used by the underlying signature implementation."
-------------
PR: https://git.openjdk.java.net/jdk/pull/8396
More information about the security-dev
mailing list