[RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported

[Sean Mullan]

On 6/3/20 10:45 PM, Anthony Scarpino wrote:
> On 6/3/20 3:05 PM, Anthony Scarpino wrote:
>> On 6/3/20 9:23 AM, Sean Mullan wrote:
>>> On 6/2/20 6:33 PM, Anthony Scarpino wrote:
>>>>> "If this signature has been previously initialized with parameters
>>>>> (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link 
>>>>> #setParameter(String, Object)}) and the underlying signature
>>>>> implementation supports returning the parameters as {@code 
>>>>> AlgorithmParameters}, this method returns the same parameters."
>>>>
>>>> If we are going to reexamine this, then I would say "previously 
>>>> initialized" is the wrong wording.  it makes it sound like it only 
>>>> applies when the signature is reset().   It should be replaced with 
>>>> "set", regardless if it is the first op or a reset op.
>>>
>>> There is no reset() method in Signature. I assume you mean when the 
>>> sign() or verify() method is complete.
>>
>> Yeah, too much time staring at Cipher and MD.
>>
>>>
>>> setParameter currently uses the following wording: "Initializes this 
>>> signature engine with the specified parameter set."
>>>
>>> I don't see a big difference between the words initialize and set.
>>>
>>> But if you change the wording here, then you should change it in 
>>> setParameter as well.
>>>
>>> --Sean
>>
>> Since setParameter says "initialized", I think just dropping 
>> "previously" keeps the same symmetry.
>>
>> Tony
> 
> updated webrev:
> https://cr.openjdk.java.net/~ascarpino/8243424/webrev.02/

Looks good. I assume we have existing tests for this. You should add a 
noreg-doc label to the bug.

--Sean