Re: RFR: 8274308: Improve efficiency for HandshakeContext initialization. [v2]

2021-10-29 Thread Xue-Lei Andrew Fan
On Fri, 29 Oct 2021 23:58:06 GMT, Clive Verghese wrote: >> Hi, >> >> We have identified that the `HandshakeContext` initialization takes up a >> close to 50% of the flame graph for startHandshake. I have moved the >> computation of the `activeProtocols` and `activeCipherSuites` from the >> Ha

Re: RFR: 8274308: Improve efficiency for HandshakeContext initialization.

2021-10-29 Thread Clive Verghese
On Sat, 2 Oct 2021 05:45:47 GMT, Clive Verghese wrote: > Hi, > > We have identified that the `HandshakeContext` initialization takes up a > close to 50% of the flame graph for startHandshake. I have moved the > computation of the `activeProtocols` and `activeCipherSuites` from the > Handshake

Re: RFR: 8274308: Improve efficiency for HandshakeContext initialization. [v2]

2021-10-29 Thread Clive Verghese
> Hi, > > We have identified that the `HandshakeContext` initialization takes up a > close to 50% of the flame graph for startHandshake. I have moved the > computation of the `activeProtocols` and `activeCipherSuites` from the > HandshakeContext constructor to SSLConfiguration class because the

Re: RFR: 8273101: Eliminate the usage of threadgroup sandboxing in the java.util.logging

2021-10-29 Thread Mandy Chung
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote: > At the time Java supported applets and webstart, a special mechanism for > launching various applications in one JVM was used to reduce memory usage and > each application was isolated from each other. > > This isolation was implemented

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v10]

2021-10-29 Thread Daniel Fuchs
On Fri, 29 Oct 2021 16:17:46 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v9]

2021-10-29 Thread Aleksei Efimov
On Wed, 27 Oct 2021 16:23:29 GMT, Michael McMahon wrote: >> Aleksei Efimov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add @ throws NPE to hosts file resolver javadoc > > src/java.base/share/classes/java/net/InetAddress.java line 841

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v10]

2021-10-29 Thread Aleksei Efimov
> This change implements a new service provider interface for host name and > address resolution, so that java.net.InetAddress API can make use of > resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate > this: > -

Re: previously prevented exploit now possible with JDK 18

2021-10-29 Thread Rick Hillegas
On 10/29/21 4:58 AM, Alan Bateman wrote: On 28/10/2021 20:14, Rick Hillegas wrote: As a canary in the mineshaft, I built and tested Apache Derby with the recent build 18-ea+20-1248 of Open JDK 18. I tripped across the following issue when running Derby's regression tests. The problem is explai

Integrated: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable

2021-10-29 Thread Sean Mullan
On Mon, 25 Oct 2021 12:53:43 GMT, Sean Mullan wrote: > The JDK implementation (as supplied by the "SUN" provider) of > `X509Certificate::getSubjectAlternativeNames` and > `X509Certificate::getIssuerAlternativeNames` returns `null` instead of > throwing a `CertificateParsingException` when the

Re: previously prevented exploit now possible with JDK 18

2021-10-29 Thread Alan Bateman
On 28/10/2021 20:14, Rick Hillegas wrote: As a canary in the mineshaft, I built and tested Apache Derby with the recent build 18-ea+20-1248 of Open JDK 18. I tripped across the following issue when running Derby's regression tests. The problem is explained in more detail at https://issues.apac

Integrated: 8273026: Slow LoginContext.login() on multi threading application

2021-10-29 Thread Larry-N
On Wed, 29 Sep 2021 10:45:41 GMT, Larry-N wrote: > This fix adds a cache of service provider classes to LoginContext (in > particular, it's a cache of LoginModules classes). The approach helps to > increase the performance of the LoginContext.login() method significantly, > especially in a mul