On Wed, 27 Apr 2022 20:01:26 GMT, Sean Mullan wrote:
>> I don't see the ProviderException being mentioned?
>> Per the description under JDK-8209038, the requests are:
>> 1) describe the returned parameters following what's in Signature class,
>> i.e. if this object has been initialized with
On Wed, 27 Apr 2022 19:48:01 GMT, Valerie Peng wrote:
>>> As for the 2nd sentence, it boils down whether we requires provider to
>>> generate default parameters and return it when parameter is required.
>>> Existing javadoc states that null is returned when parameter is not
>>> required.
On Tue, 26 Apr 2022 19:26:41 GMT, Sean Mullan wrote:
>> I have filed the PR for the Signature at:
>> https://github.com/openjdk/jdk/pull/8396
>> Best to get it done along with this one.
>
>> As for the 2nd sentence, it boils down whether we requires provider to
>> generate default parameters
On Tue, 26 Apr 2022 18:28:03 GMT, Valerie Peng wrote:
>>> I can do the Signature update through
>>> https://bugs.openjdk.java.net/browse/JDK-8253176 which I have targeted to
>>> fix in 19 also.
>>
>> Ok.
>
> I have filed the PR for the Signature at:
> https://github.com/openjdk/jdk/pull/8396
On Mon, 25 Apr 2022 18:14:07 GMT, Sean Mullan wrote:
>> As for the 2nd sentence, it boils down whether we requires provider to
>> generate default parameters and return it when parameter is required.
>> Existing javadoc states that null is returned when parameter is not
>> required. Given
On Thu, 21 Apr 2022 23:31:37 GMT, Valerie Peng wrote:
>>> > Hmm, I tried the suggested approach in (1), the result looks very
>>> > lengthy. Actually, the Cipher.init(..) methods already has a few
>>> > paragraphs describing the behavior for parameter generation, perhaps we
>>> > should not
On Thu, 21 Apr 2022 23:15:10 GMT, Valerie Peng wrote:
>>> For (1), how about something like below:
>>>
>>> > ```
>>> > * The returned parameters may be the same that were used to initialize
>>> > * this cipher, or may contain additional default or random parameter
>>> > * values used by the
On Wed, 20 Apr 2022 16:40:34 GMT, Sean Mullan wrote:
>>> Hmm, I tried the suggested approach in (1), the result looks very lengthy.
>>> Actually, the Cipher.init(..) methods already has a few paragraphs
>>> describing the behavior for parameter generation, perhaps we should not
>>> repeat
On Wed, 20 Apr 2022 16:10:17 GMT, Sean Mullan wrote:
>> For (1), how about something like below:
>>
>>> * The returned parameters may be the same that were used to
>>> initialize
>>> * this cipher, or may contain additional default or random parameter
>>> * values used by the
On Tue, 19 Apr 2022 02:44:01 GMT, Valerie Peng wrote:
>> Hmm, I tried the suggested approach in (1), the result looks very lengthy.
>> Actually, the Cipher.init(..) methods already has a few paragraphs
>> describing the behavior for parameter generation, perhaps we should not
>> repeat
On Tue, 19 Apr 2022 02:20:10 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/javax/crypto/Cipher.java line 1054:
>>
>>> 1052: * this cipher, or may contain additional default or random
>>> parameter
>>> 1053: * values used by the underlying cipher implementation if this
>>>
On Fri, 15 Apr 2022 17:30:38 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update w/ review feedbacks
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 1054:
>
>> 1052: * this
On Wed, 13 Apr 2022 22:04:03 GMT, Valerie Peng 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
On Wed, 13 Apr 2022 22:04:03 GMT, Valerie Peng 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
On Wed, 13 Apr 2022 22:04:03 GMT, Valerie Peng 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
On Wed, 13 Apr 2022 21:53:33 GMT, Valerie Peng wrote:
>> I like the revised spec more.
>>
>> BTW, for "... contain additional default and random parameter values ...",
>> is "or" more common than "and" in English?
>
> Hmm, the original javadoc has "and", so I just picked it up. Perhaps I
> 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
17 matches
Mail list logo
