All good catches! I will make the update. No new code review.
Thanks,
Xuelei
On 4/5/2019 4:11 AM, Daniel Fuchs wrote:
Hi Xuelei,
Looks good to me.
SSLContext.java
72 throw new InternalError(e);
Why not `new ExceptionInInitializerError(e)` ?
SSLSocketImpl.java:
In `duplexC
Hi Xuelei,
Looks good to me.
SSLContext.java
72 throw new InternalError(e);
Why not `new ExceptionInInitializerError(e)` ?
SSLSocketImpl.java:
In `duplexCloseOutput()` I wonder if you should nest two
`try { } finally { }` statements to make really sure that the lock
is actually
On 04/04/2019 22:32, Xuelei Fan wrote:
Hi Daniel & Alan,
All good catches! I updated accordingly:
http://cr.openjdk.java.net/~xuelei/8221882/webrev.03/
The updates to SSLContext and HttpsURLConnectionImpl look good. The
additional cleanup you mention is fine for another follow-on issue.
-A
Hi Daniel & Alan,
All good catches! I updated accordingly:
http://cr.openjdk.java.net/~xuelei/8221882/webrev.03/
On 4/4/2019 3:01 AM, Daniel Fuchs wrote:
Hi Xuelei,
I second Alan's suggestion to use VarHandle CAS for getDefault().
Otherwise you will have a race between getDefault() and set
Hi Xuelei,
I second Alan's suggestion to use VarHandle CAS for getDefault().
Otherwise you will have a race between getDefault() and setDefault()
which will be problematic (and could make tests/app fail randomly).
WRT default factories I like the new holder class.
I wonder if you should bite the
On 03/04/2019 20:33, Xuelei Fan wrote:
:
new webrev (remove update for HttpsClient.java):
http://cr.openjdk.java.net/~xuelei/8221882/webrev.02/
In HttpsURLConnectionImpl it would be nice if delegate could be final -
can the protected constructor marked "for plugin" be removed so this
cleanu
On 4/3/2019 12:06 PM, Alan Bateman wrote:
On 03/04/2019 19:40, Xuelei Fan wrote:
Updated webrev (updated SSLContext.java, HttpsClient,
HttpsURLConnectionImpl):
http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/
This looks good to me, the only change that I'm not 100% sure on is in
Https
On 03/04/2019 19:40, Xuelei Fan wrote:
Updated webrev (updated SSLContext.java, HttpsClient,
HttpsURLConnectionImpl):
http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/
This looks good to me, the only change that I'm not 100% sure on is in
HttpsClient where the locking will not be consis
ttp://bernd.eckenfels.net
*Von:* security-dev im Auftrag
von Xuelei Fan
*Gesendet:* Mittwoch, April 3, 2019 6:48 AM
*An:* security-dev@openjdk.java.net; Alan Bateman
*Betreff:* RFR [13] JDK-8221882: Use fiber-friendly
java.util.concurrent.locks in JSSE
Hi,
Could I
Updated webrev (updated SSLContext.java, HttpsClient,
HttpsURLConnectionImpl):
http://cr.openjdk.java.net/~xuelei/8221882/webrev.01/
On 4/3/2019 1:03 AM, Alan Bateman wrote:
On 03/04/2019 04:12, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net
ftrag von Xuelei
Fan
Gesendet: Mittwoch, April 3, 2019 6:48 AM
An: security-dev@openjdk.java.net; Alan Bateman
Betreff: RFR [13] JDK-8221882: Use fiber-friendly java.util.concurrent.locks in
JSSE
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8221882/webre
On 03/04/2019 04:12, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/
To benefits from with Fibers [1], there is a need to use explicit
locks, java.util.concurrent.locks, for synchronization in JSSE and the
SunJSSE prov
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8221882/webrev.00/
To benefits from with Fibers [1], there is a need to use explicit locks,
java.util.concurrent.locks, for synchronization in JSSE and the SunJSSE
provider.
Most of the update is replacing
13 matches
Mail list logo
