Re: RFR: 8356644: Update encoding declaration to UTF-8

On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie wrote: > That seems reasonable, yes. However, I'd like to keep this change to the > absolute minimum. Feel free to open a separate issue for fixing this. FIled: https://bugs.openjdk.org/browse/JDK-8356937 - PR Review Comment: ht

Integrated: 8356644: Update encoding declaration to UTF-8

On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote: > A handful of html and xml files in the JDK source tree claims to have > encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. > > While perhaps technically correct, this is misleading, and goes contrary to > the eff

Re: RFR: 8356644: Update encoding declaration to UTF-8

On Tue, 13 May 2025 00:10:50 GMT, Sergey Bylokhov wrote: >> A handful of html and xml files in the JDK source tree claims to have >> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files. >> >> While perhaps technically correct, this is misleading, and goes contrary to >> the

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v15]

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE > respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK > API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net > jck:api/javax_security jck:ap

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v14]

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE > respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK > API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net > jck:api/javax_security jck:ap

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v13]

On Tue, 13 May 2025 17:41:32 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE >> respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK >> API (jck:api/java_security jck:

Re: The default HttpServer Executor

I don't have any opinion besides best do nothing, but I will note that any multi threaded executor will make apparent the existing bug/spec issue in Filter that we talked about before. On Tue, May 13, 2025, 9:27 PM Josiah Noel wrote: > The HttpServer doesn't use any default >> executor > > > I k

Re: The default HttpServer Executor

> > The HttpServer doesn't use any default > executor I know what you mean by this, but I have to point out that the class used is quite literally called DefaultExecutor

Re: The default HttpServer Executor

Hi Josiah, The HttpServer doesn't use any default executor - it has one dispatcher thread and by default serves requests serially from the dispatcher thread. For backward compatibility I don't think we will ever change that default behaviour. An executor can however be supplied to the HttpServer

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v13]

> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE > respectively. > > CSR is underway. > > Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK > API (jck:api/java_security jck:api/javax_crypto jck:api/javax_net > jck:api/javax_security jck:ap

The default HttpServer Executor

Hey Team, Has there been any discussion about changing the default executor of the JDK HTTP server implementation to use virtual threads? -- Cheers, Josiah.

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v12]

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE >> respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK >> API (jck:api/java_security jck:

Re: RFR: 8356395: Spec needs to be clarified for InterfaceAddress.getBroadcast() method [v3]

On Tue, 13 May 2025 15:08:08 GMT, kieran-farrell wrote: >> Spec currently suggests that only IPv6 addresses can return null for >> InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 >> address such as the loopback address do not support broadcasting and can >> therefor

Re: RFR: 8356395: Spec needs to be clarified for InterfaceAddress.getBroadcast() method [v3]

On Tue, 13 May 2025 13:55:49 GMT, Daniel Fuchs wrote: >> I think the original wording of the class level doc was phrased awkwardly. >> I'd like to suggest the following: >> >> * This class represents a Network Interface address. In the case of >> * IPv4, this comprises the IP address, a subne

Re: RFR: 8356395: Spec needs to be clarified for InterfaceAddress.getBroadcast() method [v3]

> Spec currently suggests that only IPv6 addresses can return null for > InterfaceAddress.getBroadcast(). Clarifying spec to state that certain IPv4 > address such as the loopback address do not support broadcasting and can > therefore also return null. kieran-farrell has updated the pull reque

Re: RFR: 8351347: HttpClient Improve logging of response headers

On Tue, 13 May 2025 08:15:34 GMT, Volkan Yazici wrote: > Includes request method, request URI, response status code, and HTTP/2 stream > ID while logging response headers in the HTTP Client. > > ### Demonstration > > Snippets from running JTreg against > `test/jdk/java/net/httpclient/HeadTest

Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v3]

On Tue, 13 May 2025 03:56:25 GMT, Hai-May Chao wrote: > It is nice to refactor the common code for algorithm constraints checking > into a new class, `X509KeyManagerConstraints.java`, used by both > `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a > new system propert

Re: RFR: 8356395: Spec needs to be clarified for InterfaceAddress.getBroadcast() method [v2]

On Tue, 13 May 2025 09:59:02 GMT, Michael McMahon wrote: >> Thanks Daniel, I have commited the above change in wording to the get >> broadcast method and updated the CSR to reflect (JDK-8356002). I will await >> confirmation on the class level API documentation before updating. > > I think the

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v12]

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE >> respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK >> API (jck:api/java_security jck:

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v12]

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE >> respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK >> API (jck:api/java_security jck:

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

On Tue, 13 May 2025 12:26:54 GMT, Sean Mullan wrote: >> I was following the SecretKey.getEncoded() style. I see now that >> KDF.deriveData() does do UOE. >> >> I could go either way on this. I do need to make this consistent, I have >> TLSv1.3 using KDF style, and TLSv1-TLSv1.2 using the n

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v10]

On Tue, 13 May 2025 05:13:42 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java line 254: >> >>> 252: * >>> 253: * @return a byte array of size {@code length} that contains the >>> EKM >>> 254: * material, or null if the deri

Re: RFR: 8341346: Add support for exporting TLS Keying Material [v12]

On Tue, 13 May 2025 05:32:34 GMT, Bradford Wetmore wrote: >> Adds the RFC 5705/8446 TLS Key Exporters API/implementation to JSSE/SunJSSE >> respectively. >> >> CSR is underway. >> >> Tests include new unit tests for TLSv1-1.3. Will run tier1-2, plus the JCK >> API (jck:api/java_security jck:

Integrated: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics

On Thu, 10 Apr 2025 10:38:57 GMT, Volkan Yazici wrote: > `ServerUdsChannelHolder` is introduced to manage the life cycle of a > `ServerSocketChannel` created using Unix domain sockets (UDS) in a > thread-safe manner. > > ### Testing > > Changes can be tested as follows: > > > make build-mic

Re: RFR: 8356395: Spec needs to be clarified for InterfaceAddress.getBroadcast() method [v2]

On Fri, 9 May 2025 10:02:25 GMT, kieran-farrell wrote: >> src/java.base/share/classes/java/net/InterfaceAddress.java line 67: >> >>> 65: * >>> 66: * Certain IPv4 addresses, such as the loopback address, do not >>> support >>> 67: * broadcasting and will also result in {@code nul

RFR: 8351347: HttpClient Improve logging of response headers

Includes request method, request URI, response status code, and HTTP/2 stream ID while logging response headers in the HTTP Client. ### Demonstration Snippets from running JTreg against `test/jdk/java/net/httpclient/HeadTest.java`: **Before:** INFO: HEADERS: RESPONSE HEADERS: connection:

Integrated: 8355360: -d option of jwebserver command should accept relative paths

On Thu, 8 May 2025 09:01:33 GMT, Volkan Yazici wrote: > Allows relative paths in the content root directory passed to the > `jwebserver`. Changes effect both the `jwebserver` executable and the `java > -m jdk.httpserver` execution. > > ### Implementation notes > > Received `Path` is read usin

Re: RFR: 8355360: -d option of jwebserver command should accept relative paths [v4]

On Fri, 9 May 2025 09:53:08 GMT, Volkan Yazici wrote: >> Allows relative paths in the content root directory passed to the >> `jwebserver`. Changes effect both the `jwebserver` executable and the `java >> -m jdk.httpserver` execution. >> >> ### Implementation notes >> >> Received `Path` is re

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v6]

On Mon, 12 May 2025 19:53:35 GMT, Volkan Yazici wrote: >> `ServerUdsChannelHolder` is introduced to manage the life cycle of a >> `ServerSocketChannel` created using Unix domain sockets (UDS) in a >> thread-safe manner. >> >> ### Testing >> >> Changes can be tested as follows: >> >> >> make

Re: RFR: 8354024: [JMH] Create ephemeral UnixDomainSocketAddress provider with thread-safe close semantics [v6]

On Mon, 12 May 2025 19:53:35 GMT, Volkan Yazici wrote: >> `ServerUdsChannelHolder` is introduced to manage the life cycle of a >> `ServerSocketChannel` created using Unix domain sockets (UDS) in a >> thread-safe manner. >> >> ### Testing >> >> Changes can be tested as follows: >> >> >> make