Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7]

2022-05-16 Thread Valerie Peng
On Mon, 16 May 2022 13:28:13 GMT, Sean Mullan  wrote:

>> With this modification of 2nd sentence. The whole paragraph becomes:
>> 
>>  * 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 scheme. If the required
>>  * parameters were not supplied and can be generated by the signature,
>>  * the generated parameters are returned; otherwise {@code null} is
>>  * returned. However, if the signature scheme does not support returning
>>  * the parameters as {@code AlgorithmParameters}, {@code null} is always
>>  * returned.
>> 
>> For the last sentence, would it be better to use "also" instead of "always"?
>
> I think "also" would not be quite right, because I would read that as there 
> is something else that is also returned with `null`. I think you can remove 
> the word "always" -- it isn't really necessary and that might address your 
> concern.

Max suggested moving the last sentence to a new paragraph, so I did that and 
leave the "always" in.

-

PR: https://git.openjdk.java.net/jdk/pull/8396


Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7]

2022-05-16 Thread Sean Mullan
On Fri, 13 May 2022 20:58:16 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/java/security/Signature.java line 1012:
>> 
>>> 1010:  * values used by the underlying signature scheme. If the required
>>> 1011:  * parameters were not supplied and can be generated by the 
>>> signature,
>>> 1012:  * the generated parameters are returned. However, if the 
>>> signature scheme
>> 
>> I think one small addition to the 2nd sentence would help to cover the case 
>> where null is returned if params were not set and the impl does not generate 
>> params (regardless as to whether it supports returning them as 
>> `AlgorithmParameters`): "If the required parameters were not supplied and 
>> can be generated by the signature, the generated parameters are returned; 
>> otherwise `null` is returned."
>
> With this modification of 2nd sentence. The whole paragraph becomes:
> 
>  * 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 scheme. If the required
>  * parameters were not supplied and can be generated by the signature,
>  * the generated parameters are returned; otherwise {@code null} is
>  * returned. However, if the signature scheme does not support returning
>  * the parameters as {@code AlgorithmParameters}, {@code null} is always
>  * returned.
> 
> For the last sentence, would it be better to use "also" instead of "always"?

I think "also" would not be quite right, because I would read that as there is 
something else that is also returned with `null`. I think you can remove the 
word "always" -- it isn't really necessary and that might address your concern.

-

PR: https://git.openjdk.java.net/jdk/pull/8396


Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7]

2022-05-13 Thread Valerie Peng
On Fri, 13 May 2022 20:29:11 GMT, Sean Mullan  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   fix newline.
>
> src/java.base/share/classes/java/security/Signature.java line 1012:
> 
>> 1010:  * values used by the underlying signature scheme. If the required
>> 1011:  * parameters were not supplied and can be generated by the 
>> signature,
>> 1012:  * the generated parameters are returned. However, if the 
>> signature scheme
> 
> I think one small addition to the 2nd sentence would help to cover the case 
> where null is returned if params were not set and the impl does not generate 
> params (regardless as to whether it supports returning them as 
> `AlgorithmParameters`): "If the required parameters were not supplied and can 
> be generated by the signature, the generated parameters are returned; 
> otherwise `null` is returned."

With this modification of 2nd sentence. The whole paragraph becomes:

 * 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 scheme. If the required
 * parameters were not supplied and can be generated by the signature,
 * the generated parameters are returned; otherwise {@code null} is
 * returned. However, if the signature scheme does not support returning
 * the parameters as {@code AlgorithmParameters}, {@code null} is always
 * returned.

For the last sentence, would it be better to use "also" instead of "always"?

-

PR: https://git.openjdk.java.net/jdk/pull/8396


Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7]

2022-05-13 Thread Sean Mullan
On Fri, 13 May 2022 19:35:35 GMT, Valerie Peng  wrote:

>> This is to update the method javadoc of 
>> java.security.Signature.getParameters() with the missing `@throws 
>> UnsupportedOperationException`. In addition, the wording on the returned 
>> parameters are updated to match those in Cipher and CipherSpi classes. 
>> 
>> CSR will be filed later.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   fix newline.

src/java.base/share/classes/java/security/Signature.java line 1012:

> 1010:  * values used by the underlying signature scheme. If the required
> 1011:  * parameters were not supplied and can be generated by the 
> signature,
> 1012:  * the generated parameters are returned. However, if the signature 
> scheme

I think one small addition to the 2nd sentence would help to cover the case 
where null is returned if params were not set and the impl does not generate 
params (regardless as to whether it supports returning them as 
`AlgorithmParameters`): "If the required parameters were not supplied and can 
be generated by the signature, the generated parameters are returned; otherwise 
`null` is returned."

-

PR: https://git.openjdk.java.net/jdk/pull/8396


Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v7]

2022-05-13 Thread Valerie Peng
> This is to update the method javadoc of 
> java.security.Signature.getParameters() with the missing `@throws 
> UnsupportedOperationException`. In addition, the wording on the returned 
> parameters are updated to match those in Cipher and CipherSpi classes. 
> 
> CSR will be filed later.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional 
commit since the last revision:

  fix newline.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8396/files
  - new: https://git.openjdk.java.net/jdk/pull/8396/files/7026bb65..68b36fc1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=8396=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8396=05-06

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8396.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8396/head:pull/8396

PR: https://git.openjdk.java.net/jdk/pull/8396