On Fri, 7 Jun 2024 15:21:56 GMT, Daniel Fuchs wrote:
> The test failed because the shared HttpClients were not garbage collected in
> the imparted time.
> The timeout of 500ms to wait for the clients to clean up is sufficient most
> of the time but rather small, I suspect a bit more time was
On Wed, 5 Jun 2024 10:42:15 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> noted in https://bugs.openjdk.org/browse/JDK-8333590?
>
> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an
> interna
On Wed, 5 Jun 2024 11:00:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8333590?
>>
>> As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an
&
tring` representation shows empty
> headers, even when it isn't empty. The commit in this PR fixes the issue by
> implementing `toString()` in the `UnmodifiableHeaders` to return the correct
> representation of the headers.
>
> An existing jtreg test has been updated to reproduce thi
Can I please get a review of this change which proposes to fix the issue noted
in https://bugs.openjdk.org/browse/JDK-8333590?
As noted in that issue the `sun.net.httpserver.UnmodifiableHeaders`, an
internal class, within the `jdk.httpserver` module doesn't override the
`toString()` method.
On Wed, 29 May 2024 06:28:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which marks 2 constructors on
>> `java.net.Socket` as deprecated for removal?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
>
On Wed, 29 May 2024 00:59:10 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which marks 2 constructors on
> `java.net.Socket` as deprecated for removal?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
> constructors, which al
On Wed, 29 May 2024 05:51:27 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which marks 2 constructors on
>> `java.net.Socket` as deprecated for removal?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
>
eprecated for removal to
> allow for their removal in some future release.
>
> No new tests have been added for this change. tier1, tier2 and tier3 testing
> is currently in progress.
>
> A CSR for this change is available at
> https://bugs.openjdk.org/browse/JDK-8333092
J
On Wed, 29 May 2024 00:59:10 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which marks 2 constructors on
> `java.net.Socket` as deprecated for removal?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
> constructors, which al
eprecated for removal to
> allow for their removal in some future release.
>
> No new tests have been added for this change. tier1, tier2 and tier3 testing
> is currently in progress.
>
> A CSR for this change is available at
> https://bugs.openjdk.org/browse/JDK-8333092
J
Can I please get a review of this change which marks 2 constructors on
`java.net.Socket` as deprecated for removal?
As noted in https://bugs.openjdk.org/browse/JDK-8216984 these 2 `Socket`
constructors, which allow for `stream=false` to construct a UDP socket, have
been deprecated since
On Mon, 20 May 2024 09:25:31 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
On Wed, 15 May 2024 05:06:02 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which clarifies the value
> type for the `java.net.SocketOptions.SO_LINGER` option?
This pull request has now been integrated.
Changeset: 5f804b2e
Author:Jaikiran Pa
On Fri, 17 May 2024 11:33:14 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one addition
On Wed, 15 May 2024 04:20:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal 3 methods on `java.net.MulticastSocket`? This addresses
> https://bugs.openjdk.org/browse/JDK-8332181.
>
> As noted in that issue these me
On Mon, 20 May 2024 06:02:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in
On Fri, 17 May 2024 11:33:14 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one addition
On Fri, 17 May 2024 11:50:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in
nd existing tests in tier1, tier2 and tier3
> continue to pass.
Jaikiran Pai has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/rebase. The pull request contains five additional commits since
On Fri, 17 May 2024 11:50:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
nd existing tests in tier1, tier2 and tier3
> continue to pass.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
also add forRemoval in internal classes
-
Changes:
- all: https://git.openjdk.org/jdk/pull/19242/files
- n
On Fri, 17 May 2024 11:09:31 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> also add forRemoval in internal classes
>
> src/java.base/share/classes/java/net/Ne
On Fri, 17 May 2024 10:55:26 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reword based on Alan's suggestion
>
> src/java.base/share/classes/java/net/SocketOp
> Can I please get a review of this doc-only change which clarifies the value
> type for the `java.net.SocketOptions.SO_LINGER` option?
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
linger interval instead of linger t
On Fri, 17 May 2024 08:32:07 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reword the javadoc
>
> src/java.base/share/classes/java/net/SocketOptions.java l
> Can I please get a review of this doc-only change which clarifies the value
> type for the `java.net.SocketOptions.SO_LINGER` option?
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
reword based on Alan's sugg
On Wed, 15 May 2024 11:07:05 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reword the javadoc
>
> src/java.base/share/classes/java/net/SocketOptions.java line
> Can I please get a review of this doc-only change which clarifies the value
> type for the `java.net.SocketOptions.SO_LINGER` option?
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
reword the javadoc
-
C
On Thu, 16 May 2024 11:47:13 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line
>> 72:
>>
>>> 70: \ by code in modules for which native access is not
>>> explicitly enabled.\n\
>>> 71: \ is one of
On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Wed, 15 May 2024 16:08:17 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
Can I please get a review of this doc-only change which clarifies the value
type for the `java.net.SocketOptions.SO_LINGER` option?
-
Commit messages:
- 8329825: Clarify the value type for java.net.SocketOptions.SO_LINGER
Changes: https://git.openjdk.org/jdk/pull/19243/files
On Wed, 15 May 2024 04:20:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal 3 methods on `java.net.MulticastSocket`? This addresses
> https://bugs.openjdk.org/browse/JDK-8332181.
>
> As noted in that issue these me
Can I please get a review of this change which proposes to deprecate for
removal 3 methods on `java.net.MulticastSocket`? This addresses
https://bugs.openjdk.org/browse/JDK-8332181.
As noted in that issue these methods have been deprecated since Java 1.2 and
1.4 days. They currently have
On Wed, 15 May 2024 04:20:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal 3 methods on `java.net.MulticastSocket`? This addresses
> https://bugs.openjdk.org/browse/JDK-8332181.
>
> As noted in that issue these me
On Mon, 13 May 2024 07:40:27 GMT, gt wrote:
>> Thank you both for the reviews.
>
> @jaikiran @djelinski Any chance this will be backported to JDK-17 and/or 21?
> We need this fix to download large files over SSL.
Hello @gtaylor1981, the fix is worth backporting to older releases. I am not
Hello Alessandro,
I've moved this discussion to net-dev mailing list which is more
relevant for this discussion (and Bcced core-libs-dev). If you haven't
already subscribed to net-dev, then you can do it here
https://mail.openjdk.org/mailman/listinfo/net-dev.
-Jaikiran
On 13/05/24 3:28 am,
On Fri, 10 May 2024 09:21:15 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8332020?
>
> `jwebserver` when it is launched prints a URL where the server is accessible.
> When launched usi
On Fri, 10 May 2024 14:46:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8332020?
>>
>> `jwebserver` when it is launched prints a URL where the server is
>> accessible. Wh
>
> The commit in this PR addresses that issues. A new jtreg test has been
> introduced to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
update copyright year
-
Chang
On Fri, 10 May 2024 13:58:58 GMT, Nizar Benalla wrote:
>> Passes Tier 1-3
>> Please review this change that aims to fix a bug when parsing the client's
>> request.
>>
>> RFC 9110 states
>>
>>> 11. HTTP Authentication 11.1. Authentication Scheme
>> HTTP provides a general framework for access
On Fri, 10 May 2024 10:53:36 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Daniel's suggestion - don't change resource bundle messages
>
> test/jdk/com/s
>
> The commit in this PR addresses that issues. A new jtreg test has been
> introduced to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
Use -p 0 in the test
On Fri, 10 May 2024 10:16:10 GMT, Jaikiran Pai wrote:
>> Oh - I see... Hmmm - good question. I'd say it should be OK, since it's only
>> a log message.
>> My concern here is potentially backporting this change - where we would need
>> to make sure that all resource
>
> The commit in this PR addresses that issues. A new jtreg test has been
> introduced to reproduce this issue and verify the fix.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
Daniel's suggestion - don't change res
On Fri, 10 May 2024 10:14:13 GMT, Daniel Fuchs wrote:
> My concern here is potentially backporting this change - where we would need
> to make sure that all resource bundles in all possible languages that are
> supported are correctly updated.
I hadn't considered that. Given that, I think
On Fri, 10 May 2024 10:00:57 GMT, Daniel Fuchs wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8332020?
>>
>> `jwebserver` when it is launched prints a URL where the server is
>> accessible. When launched using an IPv6 bind
Can I please get a review of this change which proposes to address
https://bugs.openjdk.org/browse/JDK-8332020?
`jwebserver` when it is launched prints a URL where the server is accessible.
When launched using an IPv6 bind address, the printed URL doesn't enclose the
IPv6 literal in `[` `]`
On Thu, 9 May 2024 12:49:09 GMT, Nizar Benalla wrote:
>> Passes Tier 1-3
>> Please review this change that aims to fix a bug when parsing the client's
>> request.
>>
>> RFC 9110 states
>>
>>> 11. HTTP Authentication 11.1. Authentication Scheme
>> HTTP provides a general framework for access
On Fri, 10 May 2024 01:22:17 GMT, SendaoYan wrote:
>> Hi,
>> The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm
>> options. With -Xcomp jvm options, the jvm consumes a lot of time to compile
>> the java code, but the timeout value is set to 5 second.
>>
>> I think it has
On Thu, 9 May 2024 16:44:23 GMT, SendaoYan wrote:
> Hi,
> The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm
> options. With -Xcomp jvm options, the jvm consumes a lot of time to compile
> the java code, but the timeout value is set to 5 second.
>
> I think it's 3 method
On Wed, 8 May 2024 04:23:47 GMT, Nizar Benalla wrote:
> Passes Tier 1-3
> Please review this change that aims to fix a bug when parsing the client's
> request.
>
> RFC 9110 states
>
>> 11. HTTP Authentication 11.1. Authentication Scheme
> HTTP provides a general framework for access control
On Sun, 5 May 2024 07:13:35 GMT, Jaikiran Pai wrote:
> Can I get a review of this test-only fix which addresses the intermittent
> failrues in `com/sun/net/httpserver/HttpsParametersClientAuthTest.java` on
> Windows?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8331334,
On Mon, 6 May 2024 05:36:10 GMT, Jaikiran Pai wrote:
>> Can I get a review of this test-only fix which addresses the intermittent
>> failrues in `com/sun/net/httpserver/HttpsParametersClientAuthTest.java` on
>> Windows?
>>
>> As noted in https://bugs.openjdk.or
On Tue, 7 May 2024 11:35:17 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> don't check for exception message (which can be localized)
>
> t
On Thu, 25 Apr 2024 17:01:52 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update copyright date
Marked as reviewed by jpai
On Wed, 1 May 2024 20:45:27 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Wed, 17 Apr 2024 22:23:41 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
and tier3 tests have been run with this change and
> those tests continue to pass.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
don't check for exception message (which can be localized)
-
Changes:
- a
On Sun, 5 May 2024 07:13:35 GMT, Jaikiran Pai wrote:
> Can I get a review of this test-only fix which addresses the intermittent
> failrues in `com/sun/net/httpserver/HttpsParametersClientAuthTest.java` on
> Windows?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8331334,
Can I get a review of this test-only fix which addresses the intermittent
failrues in `com/sun/net/httpserver/HttpsParametersClientAuthTest.java` on
Windows?
As noted in https://bugs.openjdk.org/browse/JDK-8331334, the test relies on the
TLS handshake (of a HTTP request) to fail and then
On Thu, 2 May 2024 04:26:25 GMT, Jaikiran Pai wrote:
> Can I please get a review of this copyright text only change that removes the
> "Classpath" exception from these test files and thus addresses
> https://bugs.openjdk.org/browse/JDK-8331513?
This pull request has
Can I please get a review of this copyright text only change that removes the
"Classpath" exception from these test files and thus addresses
https://bugs.openjdk.org/browse/JDK-8331513?
-
Commit messages:
- 8331513: Tests should not use the Classpath exception form of the legal
On Fri, 26 Apr 2024 17:57:57 GMT, Varada M wrote:
>> test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java line 28:
>>
>>> 26: * @summary Test to stress directory listings
>>> 27: * @library /test/lib
>>> 28: * @run testng/othervm/timeout=180 StressDirListings
>>
>> Hello
On Thu, 25 Apr 2024 17:01:52 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update copyright date
On Thu, 25 Apr 2024 15:20:34 GMT, robert engels wrote:
>> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 60:
>>
>>> 58: InetAddress loopback = InetAddress.getLoopbackAddress();
>>> 59: InetSocketAddress addr = new InetSocketAddress (loopback, 0);
>>> 60:
On Thu, 25 Apr 2024 12:45:28 GMT, robert engels wrote:
>> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired.java line 99:
>>
>>> 97: t.sendResponseHeaders(200,5);
>>> 98:
>>> t.getResponseBody().write("hello".getBytes(StandardCharsets.ISO_8859_1));
>>> 99:
On Tue, 23 Apr 2024 19:10:48 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix broken test cases
I think it might be better to
On Tue, 23 Apr 2024 19:10:48 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix broken test cases
On Tue, 23 Apr 2024 19:10:48 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix broken test cases
On Tue, 23 Apr 2024 19:10:48 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix broken test cases
On Tue, 23 Apr 2024 19:10:48 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix broken test cases
On Tue, 23 Apr 2024 19:10:48 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix broken test cases
On Thu, 25 Apr 2024 12:01:41 GMT, Jaikiran Pai wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotRequired
On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Tue, 23 Apr 2024 08:39:56 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Mon, 22 Apr 2024 11:23:59 GMT, Christoph Langer wrote:
> In su.net.www.http.KeepAliveCache we could use pattern matching for
> instanceof.
Hello Christoph, this cleanup change looks good to me.
-
Marked as reviewed by jpai (Reviewer).
PR Review:
On Fri, 19 Apr 2024 12:02:43 GMT, Nizar Benalla wrote:
> Please review this simple enhancement that is just reducing the number of
> times we call the `MethodHandles.lookup()` method, as it can be a bit slow.
> Passes tier 1-3
>
> TIA
Marked as reviewed by jpai (Reviewer).
-
PR
On Mon, 22 Apr 2024 00:50:51 GMT, Nizar Benalla wrote:
> Picking up a dropped issue please review this simple change.
> Passes tier 1-2
>
> TIA
Hello Nizar, the change looks good to me. The tests for java/net/httpclient
area reside in tier2 and I see that you have already run those.
On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> reported in https://bugs.openjdk.org/browse/JDK-8330572?
>
> As noted in that issue, the internal method `checkOpen()` should only be
> called whe
On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> reported in https://bugs.openjdk.org/browse/JDK-8330572?
>
> As noted in that issue, the internal method `checkOpen()` should only be
> called whe
On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> reported in https://bugs.openjdk.org/browse/JDK-8330572?
>
> As noted in that issue, the internal method `checkOpen()` should only be
> called whe
Can I please get a review of this change which proposes to fix the issue
reported in https://bugs.openjdk.org/browse/JDK-8330572?
As noted in that issue, the internal method `checkOpen()` should only be called
when picking a non-TLS HTTP/1.1 connection from the pool and before handing it
out.
On Wed, 17 Apr 2024 14:37:56 GMT, Daniel Fuchs wrote:
>> Sergey Chernyshev has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update src/java.base/share/classes/java/net/Inet4Address.java
>>
>>Co-authored-by: Daniel Fuchs
On Wed, 17 Apr 2024 14:16:30 GMT, Daniel Fuchs wrote:
> > Should we be setting any expectations by specifying what
> > InetAddress.getHostAddress() will return for an Inet4Address constructed
> > using this new Inet4Address.ofPosixLiteral() method? In its current form I
> > believe it will
On Thu, 11 Apr 2024 15:27:55 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai wrote:
> This brings in the CPU24_04 changes.
This pull request has now been integrated.
Changeset: d2f9a1eb
Author: Jaikiran Pai
URL:
https://git.openjdk.org/jdk/commit/d2f9a1eb9709dbd8b1e7b0d1c14b7876281d7f23
Stats: 182 li
> This brings in the CPU24_04 changes.
Jaikiran Pai has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/rebase.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18
On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai wrote:
> This brings in the CPU24_04 changes.
Thank you Daniel for the review.
> If some of the fixes had conflicts that required fixing then asking
> confirmation from one person involved in their respective reviews would b
This brings in the CPU24_04 changes.
-
Commit messages:
- 8322122: Enhance generation of addresses
- 8319851: Improve exception logging
- 8318340: Improve RSA key implementations
- 8315708: Enhance HTTP/2 client usage
The merge commit only contains trivial merges, so no
On Wed, 10 Apr 2024 15:39:54 GMT, Darragh Clarke wrote:
> After integrating [JDK-8326568](https://bugs.openjdk.org/browse/JDK-8326568),
> B6431193 has been failing due to a suspected race condition on whether the
> `handlerIsDaemon` is set.
>
> - Moved setting `handlerIsDaemon` from the
On Mon, 8 Apr 2024 15:34:11 GMT, Darragh Clarke wrote:
>> Currently this test occasionally doesn't cleanup between runs, sometimes not
>> stopping the server or leaving Streams open
>>
>> Changes:
>> - Use try-with-resources to ensure streams close.
>> - Use try-finally to make sure the server
On Sun, 7 Apr 2024 01:43:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only changes to java.net.ServerSocket
>> and java.net.Socket classes?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
>>
On Fri, 5 Apr 2024 07:31:47 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only changes to java.net.ServerSocket
> and java.net.Socket classes?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8329745, these classes
> currently refer to the legacy `java.ne
Recently on AIX the same change was needed to address the test time outs
in the
test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java test
- https://github.com/openjdk/jdk/pull/17363
-Jaikiran
On 08/04/24 1:50 pm, Daniel Jeliński wrote:
Hi Robert,
If you are on Linux, see
On Fri, 5 Apr 2024 11:49:25 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clean up
>> the documentation of `java.net.SocketOptions` interface?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8329733, the ex
1 - 100 of 745 matches
Mail list logo
