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