Hi Valerie,
Given that hasKeyAttributes is already decelared as volatile,
may I suggest the following change that uses double locking?
It will avoid synchronizing in the happy case where `hasKeyAttributes`
has already been computed.
1924 private boolean hasKeyAttributes() {
1925
Hi Valerie,
Please ignore my comment. Sorry for the noise.
I somehow clicked on the wrong webrev link :-(
best regards,
-- daniel
On 12/03/2020 11:35, Daniel Fuchs wrote:
Hi Valerie,
Given that hasKeyAttributes is already decelared as volatile,
may I suggest the following change that uses do
Please take a review at
http://cr.openjdk.java.net/~weijun/8240848/webrev.00/
The problem is that selection has a different meaning for a specified
optionType (the option value) and an unspecified one (the option index).
I also take this chance to make ConfirmationCallback more robust.
Than
Here are some more comments, all minor. I will probably need one more
round of review.
- src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java
362 /* XDH does not require native implementation */
Looks like a cut-paste error. I think you can remove this line.
- src/java.base/sh
Hi,
Could I get the following update reviewed?
CSR: https://bugs.openjdk.java.net/browse/JDK-8227395
Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/
The legacy javax.security.cert APIs and the dependent were initially
deprecated in Java SE 9 and marked for removal in Java SE 13.
And the release note task:
https://bugs.openjdk.java.net/browse/JDK-8240968
Xuelei
On 3/12/2020 9:47 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
CSR: https://bugs.openjdk.java.net/browse/JDK-8227395
Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/
The
Hi,
Could I get the following update reviewed?
Bug#: https://bugs.openjdk.java.net/browse/JDK-8219989
Webrev: http://cr.openjdk.java.net/~xuelei/8219989/webrev.00/
Release note task: https://bugs.openjdk.java.net/browse/JDK-8240967
This is a request to remove the legacy SunJSSE provider name,
Hi Xuelei,
Looks good to me.
Hai-May
> On Mar 12, 2020, at 10:39 AM, Xuelei Fan wrote:
>
> Hi,
>
> Could I get the following update reviewed?
>
> Bug#: https://bugs.openjdk.java.net/browse/JDK-8219989
> Webrev: http://cr.openjdk.java.net/~xuelei/8219989/webrev.00/
> Release note task: htt
Hi Xuelei,
Looks good to me.
Hai-May
> On Mar 12, 2020, at 10:34 AM, Xuelei Fan wrote:
>
> And the release note task:
> https://bugs.openjdk.java.net/browse/JDK-8240968
>
> Xuelei
>
> On 3/12/2020 9:47 AM, Xuelei Fan wrote:
>> Hi,
>> Could I get the following update reviewed?
>> CSR: https
The fix looks good, although I think you should also file a CSR since
this provider name was at one time documented and supported and you
mentioned that it was still supported in the previous CSR when the
com.sun.net.ssl package was removed [1].
Thanks,
Sean
[1] https://bugs.openjdk.java.net/
Looks good to me.
--Sean
On 3/12/20 12:47 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
CSR: https://bugs.openjdk.java.net/browse/JDK-8227395
Webrev: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/
The legacy javax.security.cert APIs and the dependent were initia
Hi Xuelei,
Changes look good.
It may be worthwhile for the CSR to mention that there are existing
methods which replace the to-be-removed ones so apps have a migration path.
Thanks,
Valerie
On 3/12/2020 9:47 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
CSR: https:
No problem, thanks for double checking. ;)
Valerie
On 3/12/2020 4:42 AM, Daniel Fuchs wrote:
Hi Valerie,
Please ignore my comment. Sorry for the noise.
I somehow clicked on the wrong webrev link :-(
best regards,
-- daniel
On 12/03/2020 11:35, Daniel Fuchs wrote:
Hi Valerie,
Given that ha
Good to have a CSR. Please review:
CSR: https://bugs.openjdk.java.net/browse/JDK-8240974
Thanks,
Xuelei
On 3/12/2020 2:29 PM, Sean Mullan wrote:
The fix looks good, although I think you should also file a CSR since
this provider name was at one time documented and supported and you
mentioned
14 matches
Mail list logo