From egahlin at openjdk.org  Sun Jun  1 13:12:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 13:12:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
Message-ID: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>

On Sat, 31 May 2025 20:13:01 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 39:
> 
>> 37:  * example, {@code "100/s"}).
>> 38:  * <p>
>> 39:  * If the event class annotated with {@code Throttle} are filtered by other
> 
> "is filtered"

Will fix

> src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 148:
> 
>> 146:             return true;
>> 147:         }
>> 148:         if (superClass != null) {
> 
> Does this also need to search superClass's super?

The annotation is inherited so  superClass's super will be included.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
> 
>> 254:             // }
>> 255:             getEventConfiguration(codeBuilder);
>> 256:             codeBuilder.aload(0);
> 
> Can issue a dup() here if you want to avoid the second aload(0).

I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 257:
> 
>> 255:             getEventConfiguration(codeBuilder);
>> 256:             codeBuilder.aload(0);
>> 257:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_START_TIME);
> 
> In native,we use the endTime for duration events? Is there a need to synchronize the two?

The duration is added later, in throttle. There is no this.endTime field to read here.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 590:
> 
>> 588:     private void setDuration(CodeBuilder codeBuilder, Consumer<CodeBuilder> expression) {
>> 589:         codeBuilder.aload(0);
>> 590:         expression.accept(codeBuilder);
> 
> dont know what expression.accept() does, but does it really consume the this pointer? I see its pushed again (aload(0)) if its throttled below?

We need "this" on stack before the arguments are loaded in expression which is to be used at the end of the method by putfield

> src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 59:
> 
>> 57:     // static boolean shouldThrottleCommit(long timestamp)
>> 58:     public boolean shouldThrottleCommit(long timestamp) {
>> 59:         return throttler.sample(timestamp);
> 
> Can we assert on isEnabled?

Between the time of the enabled() check and this method, the state may change, so it could lead to false positives in testing.

> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 62:
> 
>> 60:     // Not synchronized in fast path, but uses volatile reads.
>> 61:     public boolean sample(long ticks) {
>> 62:         if (disabled) {
> 
> This volatile load is somewhat disappointing. Do you think it is needed? What happens if it is read without happens-before? It just creates an event that will most likely get discarded by the recorder engine on reset (if its set on setting update). If it's set to disabled, then the recorder engine has most likely stopped already, so the event will be discarded. Event settings are set with no visibility guarantees as to exact when they apply, so it should not really matter when it goes to disabled.

I think we can skip it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136217
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135926
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135820
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134807
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134400
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119132932
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136976

From mgronlun at openjdk.org  Sun Jun  1 19:05:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:05:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <e6_OvsZFxNg64ypSkFBoDjvls1ijTSSdXgWS0Xx0VTU=.0a41a851-5870-47fd-866b-e52414125574@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 130:

> 128:     }
> 129: 
> 130:     private long amortizedDebt(ThrottlerWindow expired) {

amortizeDept (in the present) - like this is the value we will be using to amortize (in the future)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119457164

From mgronlun at openjdk.org  Sun Jun  1 19:10:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:10:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <FEIE0-ddPBZ6gsmBek0zuu2lPmoaQLWsz8h-BfMk5fM=.17498c82-6f01-46f6-b22d-1d63a2b011a2@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 148:

> 146:         return nextGeometric(adjustBoundary(projectProbability), randomGenerator.nextDouble());
> 147:     }
> 148:      double projectPopulationSize(ThrottlerWindow expired) {

not private?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119459623

From mgronlun at openjdk.org  Sun Jun  1 19:18:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:18:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <RlRa2RB5v1Qm646gChkE1yYwCT8WcKm10nqp2sdgMVk=.071fc361-fe53-43aa-9eeb-9ae1d62388e4@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 142:

> 140:     private long deriveSamplingInterval(double sampleSize, ThrottlerWindow expired) {
> 141:         double populationSize = projectPopulationSize(expired);
> 142:         if (adjustBoundary(populationSize) <= adjustBoundary(sampleSize)) {

Do you need all these adjustBoundary() calls? It only checks if a double value is 0 or 1. Population and sample sizes will be much larger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119471003

From mgronlun at openjdk.org  Sun Jun  1 19:25:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:25:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <mldyqnpMWfzVdJXfKIrPjo4IUM4GBepsN-oCqS8ycfU=.9704ab37-e319-4289-ad1f-9e0dde646602@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottlerWindow.java line 49:

> 47:         measuredPopulationSize.set(0);
> 48:         endTicks = JVM.counterTime() +
> 49:         JVMSupport.nanosToTicks(1_000_000L * parameters.windowDurationMillis);

indent to make it clear it assigns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119475462

From egahlin at openjdk.org  Sun Jun  1 20:56:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 20:56:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Some reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/73943e7a..d0097506

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=00-01

  Stats: 10 lines in 3 files changed: 1 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Sun Jun  1 21:10:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 21:10:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
Message-ID: <alGBSpA2d3llrqNVFIf8r5jDHTM517LXhzVO_r5XK3E=.28742e7a-e306-46d4-9533-683fdb8e80a4@github.com>

On Sat, 31 May 2025 21:20:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:
> 
>> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
>> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
>> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);
> 
> Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?

We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.

We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119593028

From vyazici at openjdk.org  Mon Jun  2 09:02:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 09:02:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
Message-ID: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>

On Sun, 1 Jun 2025 20:56:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some reviewer feedback

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:

> 28: import java.util.concurrent.locks.ReentrantLock;
> 29: import jdk.jfr.internal.PlatformEventType;
> 30: public final class Throttler {

**Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.

Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we

- Revamp the JavaDoc and document the used algorithm?
- Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)

### References

- Resilience4j:
  - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
  - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
- Guava:
  - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
  - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120496703

From egahlin at openjdk.org  Mon Jun  2 10:02:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 10:02:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
 <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
Message-ID: <Vm8I6uPuFb9c9HvLs2k2AlmzzND58RLMNQSzaUJtIdY=.ed8d5612-b376-4ff3-9335-7286d5f1423c@github.com>

On Mon, 2 Jun 2025 08:59:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:
> 
>> 28: import java.util.concurrent.locks.ReentrantLock;
>> 29: import jdk.jfr.internal.PlatformEventType;
>> 30: public final class Throttler {
> 
> **Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.
> 
> Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we
> 
> - Revamp the JavaDoc and document the used algorithm?
> - Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)
> 
> ### References
> 
> - Resilience4j:
>   - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
>   - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
> - Guava:
>   - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
>   - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

I don't think we want to write the algorithm in the specification. It would make it harder for us to make adjustments in the future. The contract is x events per time unit without details on how JFR adapts the sampling. The algorithm is the same one used by the jdk.ObjectAllocationSample event, which has been in use since JDK 16, but implemented in native code and with a gtest:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/support/jfrAdaptiveSampler.cpp
 
The code in the PR is a method per method port of that code. It's hard to write stable tests that include timestamps. We have tried that in the past for other settings/events, but it only resulted in false positives.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120643350

From mgronlun at openjdk.org  Mon Jun  2 10:14:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 10:14:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
 <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
Message-ID: <nh7gTI3xUYTtMZigep1TusR2Pzu1QSdZ-zYjoMA00fs=.2ba97d70-8644-4975-8df0-96af982fc49c@github.com>

On Sun, 1 Jun 2025 13:07:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
>> 
>>> 254:             // }
>>> 255:             getEventConfiguration(codeBuilder);
>>> 256:             codeBuilder.aload(0);
>> 
>> Can issue a dup() here if you want to avoid the second aload(0).
>
> I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

No big deal, we can look into the details later.

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:
>> 
>>> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
>>> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
>>> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);
>> 
>> Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?
>
> We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.
> 
> We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

No big deal, we can look into this later if the need arises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120675164
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120676832

From michaelm at openjdk.org  Tue Jun  3 08:14:48 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 08:14:48 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into 8348986-exceptions
 - doc update to java.security
 - removed jmod/Handler change
 - doc update to java.security
 - Fixed problem with j.n.HostPortRange
 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18
  Stats: 984 lines in 47 files changed: 709 ins; 101 del; 174 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From egahlin at openjdk.org  Tue Jun  3 12:50:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 12:50:49 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix adjust boundary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/d0097506..7fa2db19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From mdonovan at openjdk.org  Tue Jun  3 13:11:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 13:11:31 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
 - Merge branch 'master' into certbuilder
 - expanded wildcard imports
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - reversed order of DN strings when making certificates.
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

-------------

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=04
  Stats: 784 lines in 3 files changed: 158 ins; 582 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/23700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700

PR: https://git.openjdk.org/jdk/pull/23700

From mdonovan at openjdk.org  Tue Jun  3 13:18:01 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 13:18:01 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
Message-ID: <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>

On Fri, 30 May 2025 19:28:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - expanded wildcard imports
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - reversed order of DN strings when making certificates.
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - changed boolean array initialization
>>  - 8325766: Review seclibs tests for cert expiry
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 109:
> 
>> 107:      */
>> 108:     public static CertificateBuilder newCertificateBuilder(String subjectName,
>> 109:                            PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
> 
> My suggestion is to make this a regular constructor and have an additional method that sets the certificate lifetime as a `Duration` parameter, ex:
> 
> `new CertificateBuilder(subject, pubKey, caPubKey, keyUsage).withValidity(Duration.ofHours(1));`

I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.

I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2123779281

From dfuchs at openjdk.org  Tue Jun  3 13:22:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 13:22:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
Message-ID: <Z9wuYyFiAHmGeI1K2E_tBDqs3kurtsXNmE327z_Io6Q=.248a8519-e3c3-436c-b597-b46195984eb2@github.com>

On Tue, 3 Jun 2025 08:14:48 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - doc update to java.security
>  - removed jmod/Handler change
>  - doc update to java.security
>  - Fixed problem with j.n.HostPortRange
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892334027

From alanb at openjdk.org  Tue Jun  3 14:02:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 14:02:18 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially
Message-ID: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>

If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.

A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358496
  Stats: 173 lines in 2 files changed: 67 ins; 11 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/25614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25614/head:pull/25614

PR: https://git.openjdk.org/jdk/pull/25614

From mgronlun at openjdk.org  Tue Jun  3 14:10:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 14:10:59 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <8jbZNr-7dzvGRglSLxMcgr5WjmSrGRChJ8MQarUTkdo=.dc1c9dff-65da-4e75-a49c-9af112b26cc7@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

Great stuff.

We have now what amounts to a carbon-copy of the existing throttling implementation used in the JVM, mainly used by the jdk.ObjectAllocationSample event. (see hotspot/src/share/jfr/support/jfrAdaptiveSampler.cpp and hotspot/src/share/jfr/recorder/service/jfrEventThrottler.cpp).

Smart work to write the Java implementation as a method-to-method comparison, which made it easier to review.

Thanks
Markus

-------------

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2892579207

From michaelm at openjdk.org  Tue Jun  3 14:27:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  uodate to JNDI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/ab6387d8..1a6f5af2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18-19

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From dfuchs at openjdk.org  Tue Jun  3 14:27:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
Message-ID: <ipCTRLZJFZ552tbf9IHpkAhXwOtPdgOXDPmliSJieUc=.f0ed0520-c99d-4d6f-ad46-03891f10ca76@github.com>

On Tue, 3 Jun 2025 14:23:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uodate to JNDI

Thanks for the last updates Michael. I believe we're good now!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892676320

From dfuchs at openjdk.org  Tue Jun  3 15:26:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 15:26:53 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>

On Tue, 3 Jun 2025 12:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

Changes LGTM. Minor comment on the test.

test/jdk/java/net/Socket/Timeouts.java line 80:

> 78:         try (Socket s = new Socket()) {
> 79:             SocketAddress remote = Utils.refusingEndpoint();
> 80:             assertThrows(ConnectException.class,  () -> s.connect(remote, 10000));

Ah! Good - you're even fixing a bug here.

test/jdk/java/net/Socket/Timeouts.java line 249:

> 247:                         () -> s.getInputStream().read());
> 248:                 int timeout = s.getSoTimeout();
> 249:                 checkDuration(startMillis, timeout-100, timeout+20_000);

Maybe it would be worth noting here that if the bug isn't fixed, the last thread to call read() would have to wait for 200 seconds, which largely exceeds 22s?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25614#pullrequestreview-2893023129
PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124221517
PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124218812

From mullan at openjdk.org  Tue Jun  3 15:33:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 15:33:56 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
Message-ID: <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>

On Tue, 3 Jun 2025 13:15:33 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.

I'm not sure what you mean - can you give an example? I don't see any advantages of using a static method here, but I agree it works either way.

> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.

I view this test utility class as being flexible enough for different cases. This is a useful method in that the other parameters are common fields that all certs usually have but it also means I can't use this method to to create a certificate with a longer, or shorter validity period. Alternatively, how about adding another method that hard-codes it as one hour:

`CertificateBuilder oneHourValidity()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124254602

From michaelm at openjdk.org  Tue Jun  3 15:39:06 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 15:39:06 GMT
Subject: Integrated: 8348986: Improve coverage of enhanced exception messages
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <ANCJMV9FtfHoAU_5eMxPFITXqxhqUwFM7UMQW1kicBQ=.57bfe450-373c-45b6-94a8-4a8b33c873f4@github.com>

On Thu, 6 Mar 2025 10:24:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: b6f827ef
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6f827ef054959662190e21ce63fc3d3c45b92f3
Stats:     984 lines in 47 files changed: 709 ins; 101 del; 174 mod

8348986: Improve coverage of enhanced exception messages

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/23929

From mdonovan at openjdk.org  Tue Jun  3 16:05:55 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 16:05:55 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
Message-ID: <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>

On Tue, 3 Jun 2025 15:31:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.
>> 
>> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.
>
>> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.
> 
> I'm not sure what you mean - can you give an example? I don't see any advantages of using a static method here, but I agree it works either way.
> 
>> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.
> 
> I view this test utility class as being flexible enough for different cases. This is a useful method in that the other parameters are common fields that all certs usually have but it also means I can't use this method to to create a certificate with a longer, or shorter validity period. Alternatively, how about adding another method that hard-codes it as one hour:
> 
> `CertificateBuilder oneHourValidity()`

As a constructor, the code would look like this


public CertificateBuilder(String subjectName,
                              PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
            throws CertificateException, IOException {
        factory = CertificateFactory.getInstance("X.509");
        SecureRandom random = new SecureRandom();

        boolean [] keyUsage = new boolean[KeyUsage.values().length];
        for (KeyUsage ku : keyUsages) {
            keyUsage[ku.ordinal()] = true;
        }

        this.subjectName = new X500Principal(subjectName);
        this.publicKey = Objects.requireNonNull(publicKey, "Caught null public key");
        notBefore = (Date)Date.from(Instant.now().minus(1, ChronoUnit.HOURS));
        notAfter = Date.from(Instant.now().plus(1, ChronoUnit.HOURS));
        serialNumber = BigInteger.valueOf(random.nextLong(1000000)+1);
        byte[] keyIdBytes = new KeyIdentifier(publicKey).getIdentifier();
        Extension e = new SubjectKeyIdentifierExtension(keyIdBytes);
        extensions.put(e.getId(), e);

        KeyIdentifier kid = new KeyIdentifier(caKey);
        e = new AuthorityKeyIdentifierExtension(kid, null, null);
        extensions.put(e.getId(), e);

        if (keyUsages.length != 0) {
            e = new KeyUsageExtension(keyUsage);
            extensions.put(e.getId(), e);
        }
    }



>   it also means I can't use this method to to create a certificate with a longer, or shorter validity period

There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:

`
newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));
`

I don't like using `Date` here and would be happy to overload it to take `Instant` as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124330323

From alanb at openjdk.org  Tue Jun  3 16:10:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 16:10:38 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Make test comment cleaner

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25614/files
  - new: https://git.openjdk.org/jdk/pull/25614/files/80fe13b1..3dc870ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25614/head:pull/25614

PR: https://git.openjdk.org/jdk/pull/25614

From alanb at openjdk.org  Tue Jun  3 16:10:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 16:10:38 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
 <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>
Message-ID: <YdG_G79PYHPkos945VgqkiENqelgzIymYdmV8Oj6EIA=.da1bcdef-630f-4bbe-aceb-8f9ca7a90235@github.com>

On Tue, 3 Jun 2025 15:20:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make test comment cleaner
>
> test/jdk/java/net/Socket/Timeouts.java line 249:
> 
>> 247:                         () -> s.getInputStream().read());
>> 248:                 int timeout = s.getSoTimeout();
>> 249:                 checkDuration(startMillis, timeout-100, timeout+20_000);
> 
> Maybe it would be worth noting here that if the bug isn't fixed, the last thread to call read() would have to wait for 200 seconds, which largely exceeds 22s?

Okay, I can make the test method description a bit clearer on this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124337179

From dfuchs at openjdk.org  Tue Jun  3 16:24:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 16:24:56 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
 <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>
Message-ID: <M0LpoQIix4h2-UdKGpKlzto-oTJlt_yVYqXuJ50QPng=.43294b15-4393-4e8e-8cbb-a9d3847ef88d@github.com>

On Tue, 3 Jun 2025 16:10:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
>> 
>> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make test comment cleaner

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25614#pullrequestreview-2893258189

From mullan at openjdk.org  Tue Jun  3 17:37:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 17:37:07 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
 <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
Message-ID: <xEMRItOXiz4QiIfzOGi5uyciDwMlL_RXN-mqbMWK7D0=.22861fb0-6375-43cc-be8f-04e42d03de5c@github.com>

On Tue, 3 Jun 2025 16:03:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> As a constructor, the code would look like this

<snip>

Ah, I see. Well technically you could call the set methods from the ctor but you would get `this-escape` compiler warnings, which you probably want to avoid.

> > it also means I can't use this method to to create a certificate with a longer, or shorter validity period
> 
> There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:
> 
> `newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));`
> 
> I don't like using `Date` here and would be happy to overload it to take `Instant` as well.

Yes, but I don't think the static method which is generically named `newCertificateBuilder` should be hard-coding a one hour validity period, that detail should be either in a different method (my preference) or this method should be named more clearly like `oneHourCertificateBuilder`. I realize this is just a test method, but this is a nicely designed API that has been very useful so I would prefer if we keep the flexibility.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124489674

From alanb at openjdk.org  Wed Jun  4 09:55:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 09:55:20 GMT
Subject: Integrated: 8358496: Concurrent reading from Socket with timeout
 executes sequentially
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <LGLho4LhsxCtg1IMn5zM3Cd9SAadVqAe379f5yresjk=.00fa5169-fca7-4f6d-8c6a-93b2e76a7d04@github.com>

On Tue, 3 Jun 2025 12:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

This pull request has now been integrated.

Changeset: 7838321b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7838321b74276e45b92c54904ea31ef70ed9e33f
Stats:     174 lines in 2 files changed: 68 ins; 11 del; 95 mod

8358496: Concurrent reading from Socket with timeout executes sequentially

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25614

From egahlin at openjdk.org  Wed Jun  4 11:34:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 11:34:24 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

@AlanBateman Do you have time for a review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939669198

From alanb at openjdk.org  Wed Jun  4 12:10:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 12:10:20 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
Message-ID: <us23R2nkGfg4Fisd7aTuf2-qDgnmaTn7sbqe0wuvphc=.ee7dcfdb-ae16-4f97-bae6-0328079a09ed@github.com>

On Wed, 4 Jun 2025 11:31:21 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> @AlanBateman Do you have time for a review?

Yes, looking at the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939787559

From duke at openjdk.org  Wed Jun  4 13:16:11 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:11 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit of 3
 retries
Message-ID: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>

The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.

This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.

The test is green with tiers 1, 2, 3 and the test is stable.

-------------

Commit messages:
 - add comment to indicate system default value
 - apply review feedback
 - fix for the http client default retry limit

Changes: https://git.openjdk.org/jdk/pull/25490/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340182
  Stats: 118 lines in 2 files changed: 116 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From vyazici at openjdk.org  Wed Jun  4 13:16:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 4 Jun 2025 13:16:17 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>

On Wed, 28 May 2025 11:26:17 GMT, p-nima <duke at openjdk.org> wrote:

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

Changes requested by vyazici (Author).

@p-nima, thanks for quickly addressing the review feedback. I've dropped some further remarks.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:

> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
> 33:  * @run junit HttpClientRetryLimitTest
> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest

@dfuch, shall we test against zero and negative values too? (Both are accepted by `AuthenticationFilter` as valid.)

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 49:

> 47: import static jdk.test.lib.Asserts.assertEquals;
> 48: 
> 49: public class HttpClientRetryLimitTest implements HttpServerAdapters {

*Nit:* [JUnit recommends the following](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods)
> It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ...

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:

> 50: 
> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);

This can be `static` too.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 53:

> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 53:     private int countRetries;

This should better be converted to a local variable.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 57:

> 55: 
> 56: 
> 57: class HttpClientRetryLimitTest implements HttpServerAdapters {

Shall we rename this to `HttpClientAuthRetryLimit`, since [there are several other retry limits](https://docs.oracle.com/en/java/javase/23/docs/api/java.net.http/module-summary.html#jdk.httpclient.auth.retrylimit)?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 58:

> 56:     public void testDefaultSystemProperty() throws Exception {
> 57: 
> 58:         try (HttpTestServer httpTestServer = HttpTestServer.create(HttpClient.Version.HTTP_1_1)) {

Don't we need to verify the behavior for HTTP/2 too? If so, can we use a `@ParameterizedTest` instead and receive the protocol version? (There are several examples you can get inspired from; `HttpResponseConnectionLabelTest`, `EmptyAuthenticate`, etc.)

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 64:

> 62:             "jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 63: 
> 64:     static Stream<HttpClient.Version> args() {

I think we should also test against with SSL and without SSL cases. See `HttpResponseLimitingTest.ServerClientPair` for inspiration.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 66:

> 64:             };
> 65: 
> 66:             httpTestServer.addHandler(httpTestHandler, "/");

In the past, there has been occasions in CI where a test server received connections from a totally unrelated test running in parallel on the same host. To avoid such mishaps, we better salt the path a bit by, say, appending the class' simple name?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 69:

> 67:             httpTestServer.start();
> 68: 
> 69:             countRetries = 0;

IMHO, this should be an `Atomic{Integer,Long}` due to the possibility of concurrent updates.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 73:

> 71:     @ParameterizedTest
> 72:     @MethodSource("args")
> 73:     public void testDefaultSystemProperty(HttpClient.Version version) throws Exception {

I see you made the class package-private in 18bac9f. You could have additionally made the method package-private too.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 87:

> 85:                         .build();
> 86: 
> 87:                 client.send(request, HttpResponse.BodyHandlers.ofString());

Since we're not interested in the response, `BodyHandlers.discarding()` might be a better fit here.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 88:

> 86:             try (
> 87:                 HttpClient client = HttpClient.newBuilder()
> 88:                         .authenticator(new Authenticator() {

To ensure the client will fire the request using the protocol version of our preference, could you also pass `version` to the client builder too, please?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 92:

> 90:                         "Expected number of retries was " + retryLimit + " but actual was "+countRetries);
> 91:                 e.printStackTrace();
> 92:             }

AFAIU, you should

1. Wrap `client::send` with `assertThrows`
2. Verify the returned exception
1. Then `assertEquals` the retry count

Otherwise, if `client::send` _unexpectedly_ doesn't throw anything, your test will incorrectly succeed.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 99:

> 97:                 HttpRequest request = HttpRequest.newBuilder()
> 98:                         .GET()
> 99:                         .uri(new URI("http://" + httpTestServer.serverAuthority() + "/" + this.getClass().getSimpleName() + "/"))

To ensure the client will fire the request using the protocol version of our preference, could you also pass `version` to the request builder too, please?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 113:

> 111:                 }
> 112:                 e.printStackTrace();
> 113:             }

AFAICT, you should be using `assertThrows` as follows:


IOException exception = assertThrows(...);
assertEquals(exception.message(), "too many authentication attempts. Limit: " + RETRY_LIMIT);
assertEquals(requestCount.get(), RETRY_LIMIT > 0 ? RETRY_LIMIT : 1);

-------------

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2874776142
Changes requested by vyazici (Author).

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2880603038
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111767554
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111701285
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111701781
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111702335
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2116087627
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111743245
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2116060516
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111722490
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111704822
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115470192
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111730359
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115451397
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111760843
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115449940
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115466187

From myankelevich at openjdk.org  Wed Jun  4 13:16:17 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 4 Jun 2025 13:16:17 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>

On Wed, 28 May 2025 11:26:17 GMT, p-nima <duke at openjdk.org> wrote:

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:

> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
> 33:  * @run junit HttpClientRetryLimitTest
> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest

Do you think adding a retrylimit=0 would be beneficial too? This way every scenario would be covered

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 47:

> 45: import java.net.http.HttpResponse;
> 46: 
> 47: import static jdk.test.lib.Asserts.assertEquals;

minor: Did you mean `import static org.junit.jupiter.api.Assertions.assertEquals;` here, as you're using junit?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:

> 50: 
> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);

Nit: This feels a bit confusing to me when reading it the first time, why not have a retry limit of 1 or 0 as a default and then specify if you want more retries in `@test`?
I think it might be a bit easier to read, but if you want to keep it, it's fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111682350
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111670821
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111681002

From dfuchs at openjdk.org  Wed Jun  4 13:16:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>

On Wed, 28 May 2025 12:46:25 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:
> 
>> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
>> 33:  * @run junit HttpClientRetryLimitTest
>> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest
> 
> @dfuch, shall we test against zero and negative values too? (Both are accepted by `AuthenticationFilter` as valid.)

We could. We could also throw in garbage to see what happens.

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 57:
> 
>> 55: 
>> 56: 
>> 57: class HttpClientRetryLimitTest implements HttpServerAdapters {
> 
> Shall we rename this to `HttpClientAuthRetryLimit`, since [there are several other retry limits](https://docs.oracle.com/en/java/javase/23/docs/api/java.net.http/module-summary.html#jdk.httpclient.auth.retrylimit)?

Sounds reasonable to rename - and fix the `@summary` in the jtreg headers too

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111954811
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2116093435

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
Message-ID: <MKkfHg-OsQHJ6cwoY-5Tt1Y3gSf9EiRqL6ldmUpiSFE=.4d3f89cd-d0a3-428c-81bb-a1eb675505f5@github.com>

On Wed, 28 May 2025 12:05:20 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:
> 
>> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
>> 33:  * @run junit HttpClientRetryLimitTest
>> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest
> 
> Do you think adding a retrylimit=0 would be beneficial too? This way every scenario would be covered

Added additional test case scenarios in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 47:
> 
>> 45: import java.net.http.HttpResponse;
>> 46: 
>> 47: import static jdk.test.lib.Asserts.assertEquals;
> 
> minor: Did you mean `import static org.junit.jupiter.api.Assertions.assertEquals;` here, as you're using junit?

Thank you for your review. The changes have been made in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114264448
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114259866

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
Message-ID: <eHpcyAO3EKv_a0ulfsGhwxC5gA0NDe1Z0At_7f0Jrwg=.f3d853f1-c592-433b-aa8a-0199b207d91b@github.com>

On Wed, 28 May 2025 13:40:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:
>> 
>>> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
>>> 33:  * @run junit HttpClientRetryLimitTest
>>> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest
>> 
>> @dfuch, shall we test against zero and negative values too? (Both are accepted by `AuthenticationFilter` as valid.)
>
> We could. We could also throw in garbage to see what happens.

New test scenarios have been added in https://github.com/openjdk/jdk/commit/18bac9fa64f81110c2894f5f141e88ec5dc20b03. We have default, positive, zero and negative values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114286157

From dclarke at openjdk.org  Wed Jun  4 13:16:18 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
Message-ID: <0SU8NcW9k69ItdVQnpm03vHFyfyVAuPXnpoNXfUNEP4=.96272fae-273d-4ce3-b3da-511aa23680c7@github.com>

On Wed, 28 May 2025 12:04:31 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:
> 
>> 50: 
>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 
> Nit: This feels a bit confusing to me when reading it the first time, why not have a retry limit of 1 or 0 as a default and then specify if you want more retries in `@test`?
> I think it might be a bit easier to read, but if you want to keep it, it's fine with me.

This line is grabbing the value of the `jdk.httpclient.auth.retrylimit` system property, and if it hasn't been set then it defaults to 3. This is based on [AuthenticationFilter.java](https://github.com/openjdk/jdk/blob/e89aa7c712be8e576b640a123da52e7f4f5f9391/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L57)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2112017438

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>

On Wed, 28 May 2025 12:16:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 49:
> 
>> 47: import static jdk.test.lib.Asserts.assertEquals;
>> 48: 
>> 49: public class HttpClientRetryLimitTest implements HttpServerAdapters {
> 
> *Nit:* [JUnit recommends the following](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods)
>> It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ...

Thank you for your feedback. The public modifier has been discarded in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:
> 
>> 50: 
>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 
> This can be `static` too.

Updated this in https://github.com/openjdk/jdk/commit/18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 53:
> 
>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
>> 53:     private int countRetries;
> 
> This should better be converted to a local variable.

Discarded the above local variable and introduced a AtomicInteger variable in  18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 66:
> 
>> 64:             };
>> 65: 
>> 66:             httpTestServer.addHandler(httpTestHandler, "/");
> 
> In the past, there has been occasions in CI where a test server received connections from a totally unrelated test running in parallel on the same host. To avoid such mishaps, we better salt the path a bit by, say, appending the class' simple name?

Thanks for the catch - the class simple name has been appended in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 69:
> 
>> 67:             httpTestServer.start();
>> 68: 
>> 69:             countRetries = 0;
> 
> IMHO, this should be an `Atomic{Integer,Long}` due to the possibility of concurrent updates.

Agreed. This has been updated in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 87:
> 
>> 85:                         .build();
>> 86: 
>> 87:                 client.send(request, HttpResponse.BodyHandlers.ofString());
> 
> Since we're not interested in the response, `BodyHandlers.discarding()` might be a better fit here.

Updated this in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 92:
> 
>> 90:                         "Expected number of retries was " + retryLimit + " but actual was "+countRetries);
>> 91:                 e.printStackTrace();
>> 92:             }
> 
> AFAIU, you should
> 
> 1. Wrap `client::send` with `assertThrows`
> 2. Verify the returned exception
> 1. Then `assertEquals` the retry count
> 
> Otherwise, if `client::send` _unexpectedly_ doesn't throw anything, your test will incorrectly succeed.

Yes, agreed - the changes have been made in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114266126
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114275602
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114269419
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114274151
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114270266
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114274886
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114298224

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <0SU8NcW9k69ItdVQnpm03vHFyfyVAuPXnpoNXfUNEP4=.96272fae-273d-4ce3-b3da-511aa23680c7@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
 <0SU8NcW9k69ItdVQnpm03vHFyfyVAuPXnpoNXfUNEP4=.96272fae-273d-4ce3-b3da-511aa23680c7@github.com>
Message-ID: <cWJDpK3Lt6VnxM0R5bWiCX1ZkN8VaHZqdah88cJqxT4=.73917af7-1e89-4d52-bbf0-60c419998be5@github.com>

On Wed, 28 May 2025 14:07:37 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:
>> 
>>> 50: 
>>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
>> 
>> Nit: This feels a bit confusing to me when reading it the first time, why not have a retry limit of 1 or 0 as a default and then specify if you want more retries in `@test`?
>> I think it might be a bit easier to read, but if you want to keep it, it's fine with me.
>
> This line is grabbing the value of the `jdk.httpclient.auth.retrylimit` system property, and if it hasn't been set then it defaults to 3. This is based on [AuthenticationFilter.java](https://github.com/openjdk/jdk/blob/e89aa7c712be8e576b640a123da52e7f4f5f9391/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L57)

A comment has been added for it in cdf78127351df62193e0ec5a09851de1c32e16e2

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114263430

From vyazici at openjdk.org  Wed Jun  4 13:16:18 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
Message-ID: <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>

On Thu, 29 May 2025 16:03:11 GMT, p-nima <duke at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 66:
>> 
>>> 64:             };
>>> 65: 
>>> 66:             httpTestServer.addHandler(httpTestHandler, "/");
>> 
>> In the past, there has been occasions in CI where a test server received connections from a totally unrelated test running in parallel on the same host. To avoid such mishaps, we better salt the path a bit by, say, appending the class' simple name?
>
> Thanks for the catch - the class simple name has been appended in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

@p-nima, the handler still accepts all calls to `/`, you only salted the request URI. Would you mind doing the same in `httpTestServer.addHandler(...)` too, please? (You better create a `String requestPath` variable and use it both at the handler and the request.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115448674

From michaelm at openjdk.org  Wed Jun  4 13:31:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 4 Jun 2025 13:31:11 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
Message-ID: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>

Hi,

This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
are present in a cookie, the Max-Age should take precedence.

Thanks
Michael

-------------

Commit messages:
 - whitespace
 - update
 - impl and test + doc update
 - Merge branch 'master' into cookie-8351983
 - doc update
 - further doc update
 - doc update only

Changes: https://git.openjdk.org/jdk/pull/25636/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351983
  Stats: 153 lines in 2 files changed: 126 ins; 24 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From dfuchs at openjdk.org  Wed Jun  4 13:49:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 13:49:56 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
 <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>
Message-ID: <0C_sJwloPs7L7VPd4UpmVUTJaYt2MBFY34kikdMZvh4=.3409bced-ec41-4ff2-ba15-6d5ee97d95f4@github.com>

On Fri, 30 May 2025 08:57:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Thanks for the catch - the class simple name has been appended in 18bac9fa64f81110c2894f5f141e88ec5dc20b03
>
> @p-nima, the handler still accepts all calls to `/`, you only salted the request URI. Would you mind doing the same in `httpTestServer.addHandler(...)` too, please? (You better create a `String requestPath` variable and use it both at the handler and the request.)

Yes - this line needs to be modified too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2126651002

From dfuchs at openjdk.org  Wed Jun  4 14:27:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 14:27:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>

On Wed, 4 Jun 2025 11:12:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

LGTM. A minor suggestion for the test.

test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:

> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),

Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.

Something like:


static final String NOW_PLUS_500 =
    DateTimeFormatter.RFC_1123_DATE_TIME.format(
        java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));

...


    new Test(1000, NOW_PLUS_500, 1000, false),


Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2896962645
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2126738975

From alanb at openjdk.org  Wed Jun  4 14:35:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 14:35:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

src/java.base/share/classes/java/net/Socket.java line 970:

> 968:             long end = SocketReadEvent.timestamp();
> 969:             long duration = end - start;
> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {

The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.

Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:

> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
> 76:      *
> 77:      * @return the throttle value, default {@code "off"} not {@code null}

I think it would be clear to drop "not null" from the return description.

src/jdk.jfr/share/conf/jfr/default.jfc line 762:

> 760:       <setting name="enabled">true</setting>
> 761:       <setting name="stackTrace">true</setting>
> 762:       <setting name="threshold">20 ms</setting>

I agree FileForce isn't a good candidate to throttle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126765474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126722810
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126719134

From dfuchs at openjdk.org  Wed Jun  4 15:46:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 15:46:36 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:

 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - Remove cryptic TODO
 - Remove outdated TODO
 - Fix race in test server's Http3StreamDispatcher
 - Test H3 server: close connection if control stream closed
 - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=05
  Stats: 103642 lines in 473 files changed: 100781 ins; 1345 del; 1516 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From egahlin at openjdk.org  Wed Jun  4 15:59:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 15:59:03 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <wJSneY7Iw7SjTULCVaLikMyjKH7L9q5sn4ZuAQcx8lA=.15ec6ced-d662-474b-99a1-b7937c7ceb68@github.com>

On Wed, 4 Jun 2025 14:16:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:
> 
>> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
>> 76:      *
>> 77:      * @return the throttle value, default {@code "off"} not {@code null}
> 
> I think it would be clearer to drop "not null" from the return description.

We have "not null" with Threshold, but not with "Period". I filed a bug to make it consistent for all JFR annotations and I can bring Throttle into the same CSR. 

https://bugs.openjdk.org/browse/JDK-8358602

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126946237

From egahlin at openjdk.org  Wed Jun  4 16:06:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 16:06:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>

On Wed, 4 Jun 2025 14:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/java.base/share/classes/java/net/Socket.java line 970:
> 
>> 968:             long end = SocketReadEvent.timestamp();
>> 969:             long duration = end - start;
>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
> 
> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
> 
> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.

We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126960704

From dfuchs at openjdk.org  Wed Jun  4 16:08:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 16:08:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
 <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
Message-ID: <UngOa-uQ8FF4qZk_AdQcyxqGWy_EsLCwDJDFv7MQqMQ=.a822c514-86df-452a-b63a-2716cc50b238@github.com>

On Fri, 16 May 2025 10:26:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
>> 
>>  - merge latest changes from master branch
>>  - Undo whitespace change
>>  - Remove unnecessary import
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - Fix test license
>>  - Remove leftover file (test was moved to parent directory)
>>  - Remove unnecessary import
>>  - Update throws clauses
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737:
> 
>> 735:         // channel, and a single selector thread, so we can do
>> 736:         // the reading directly in the selector thread and offload
>> 737:         // the parsing (the readLoop) to the executor.
> 
> This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822:
> 
>> 820:                     if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
>> 821:                         pauseReading();
>> 822:                         readLoopScheduler.runOrSchedule(executor);
> 
> This line should not be needed: we should already have kicked the read loop at line 797.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126958527
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126959414

From dfuchs at openjdk.org  Wed Jun  4 17:54:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 17:54:25 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
Message-ID: <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>

On Wed, 4 Jun 2025 15:46:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:
> 
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - Remove cryptic TODO
>  - Remove outdated TODO
>  - Fix race in test server's Http3StreamDispatcher
>  - Test H3 server: close connection if control stream closed
>  - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

src/java.net.http/share/classes/jdk/internal/net/http/hpack/HPACK.java line 176:

> 174: 
> 175:     @FunctionalInterface
> 176:     interface BufferUpdateConsumer {

@AlekseiEfimov It looks like this change is no longer required and could be reverted

src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java line 43:

> 41: // The encoding is simple and well known: 1 byte <-> 1 char
> 42: //
> 43: final class ISO_8859_1 {

OK - this class is actually used in QPack as well as HPack. Same for the `QuickHuffman` class below (notice that this is Quick - not Quic ;-) )

It might be interesting to investigate if we could pull out these classes to a common location to break the tie between QPack and HPack. Something to think about after integration maybe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126966393
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2127123043

From smarks at openjdk.org  Thu Jun  5 00:24:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 5 Jun 2025 00:24:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
Message-ID: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>

On Wed, 4 Jun 2025 16:04:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 970:
>> 
>>> 968:             long end = SocketReadEvent.timestamp();
>>> 969:             long duration = end - start;
>>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
>> 
>> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
>> 
>> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.
>
> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
> 
> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
> 
> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.

I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.

To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)

But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2127716516

From vyazici at openjdk.org  Thu Jun  5 05:36:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 05:36:50 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>

On Wed, 4 Jun 2025 11:12:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

src/java.base/share/classes/java/net/HttpCookie.java line 1:

> 1: /*

Copyright year needs to be updated.

test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 27:

> 25:  * @test
> 26:  * @bug 8351983
> 27:  * @summary HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute

Aren't we missing a `@run` tag?

test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 63:

> 61:     }
> 62: 
> 63:     static Test[] tests = new Test[] {

*Tip:* JUnit `@ParameterizedTest @CsvSource` can save us some boilerplate here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127988396
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127987557
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127987253

From vyazici at openjdk.org  Thu Jun  5 05:36:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 05:36:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>
Message-ID: <CiYqkEPrqUFI0pTty0rmfqNhiCai5qzBlLWErW7shsQ=.1781f325-bc7a-4e88-bc6f-4f0e57acdca3@github.com>

On Wed, 4 Jun 2025 14:23:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:
> 
>> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
>> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
> 
> Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.
> 
> Something like:
> 
> 
> static final String NOW_PLUS_500 =
>     DateTimeFormatter.RFC_1123_DATE_TIME.format(
>         java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));
> 
> ...
> 
> 
>     new Test(1000, NOW_PLUS_500, 1000, false),
> 
> 
> Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.

Alternatively, we could create a `HttpCookie::parse` method<sup>1</sup> accepting a `long currentTimeMillis`, and precisely determine the expected value?

<sup>1</sup> This can either be private and accessed via reflection, or package-private and accessed by placing the test in the same package.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127986120

From egahlin at openjdk.org  Thu Jun  5 08:10:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:10:42 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v4]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <72MCuwD8Jd9igYMm5C4yZyxh-8xLnnKePImAaep3p2U=.49745a1b-7f46-4a07-a150-4c243683068f@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7fa2db19..59278ca8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=02-03

  Stats: 26802 lines in 553 files changed: 20626 ins; 2170 del; 4006 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Thu Jun  5 08:13:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:13:21 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v5]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <8opPh4lTfGQBzlleDOuxmi3QyhF3M9M7U7MpIoFWUCE=.a14d1385-e759-4fa5-8733-5ebb162d20a7@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/59278ca8..535d458a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=03-04

  Stats: 2776 lines in 58 files changed: 477 ins; 2217 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Thu Jun  5 08:40:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:40:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 nine additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/535d458a..8259ff41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=04-05

  Stats: 2319 lines in 41 files changed: 2179 ins; 128 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From aturbanov at openjdk.org  Thu Jun  5 09:02:57 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:02:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
Message-ID: <bPhyUNuWlTSgWzVu0XGymtuPwYZa2VqhcLPb7siVcmU=.60458892-b041-4fa8-8237-094f995e50c6@github.com>

On Thu, 5 Jun 2025 08:40:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin 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 nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Fix adjust boundary
>  - Some reviewer feedback
>  - Consistent annotation
>  - Fix typos
>  - Fix whitespace
>  - Initial

src/java.base/share/classes/java/io/RandomAccessFile.java line 594:

> 592:         } finally {
> 593:             long end = FileWriteEvent.timestamp();
> 594:             long duration =  end - start;

Suggestion:

            long duration = end - start;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 65:

> 63: public final class EventInstrumentation {
> 64:     public static final long MASK_THROTTLE              = 1 << 62;
> 65:     public static final long MASK_THROTTLE_CHECK        = 1 << 63;

Let's align
Suggestion:

    public static final long MASK_THROTTLE               = 1 << 62;
    public static final long MASK_THROTTLE_CHECK         = 1 << 63;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 593:

> 591:         if (throttled) {
> 592:             codeBuilder.aload(0);
> 593:             getfield(codeBuilder, eventClassDesc,  ImplicitFields.FIELD_DURATION);

Suggestion:

            getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);

test/jdk/jdk/jfr/api/recording/settings/TestSettingsAvailability.java line 93:

> 91:         testSetting(EventNames.JVMInformation, "enabled", "period");
> 92:         testSetting(EventNames.FileRead, "enabled", "threshold", "stackTrace", "throttle");
> 93:         testSetting(EventNames.FileWrite, "enabled", "threshold","stackTrace", "throttle");

Suggestion:

        testSetting(EventNames.FileWrite, "enabled", "threshold", "stackTrace", "throttle");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322876
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128321445
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128323708

From egahlin at openjdk.org  Thu Jun  5 09:26:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:26:13 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Use offer method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8259ff41..7f26f172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=05-06

  Stats: 570 lines in 10 files changed: 455 ins; 88 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From alanb at openjdk.org  Thu Jun  5 09:28:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:28:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
Message-ID: <g4wakHQv7Fsl1YNLYTUXAPUC7WwQb7CM3wV9FrJMNYs=.b91f4a96-a4ec-4bd2-9ddc-67409d4097b4@github.com>

On Thu, 5 Jun 2025 09:26:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use offer method

t.txt line 1:

> 1: diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java

t.txt added by mistake.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128388583

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:

 - Remove the mistakenly added file.
 - Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7f26f172..8beb194a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=06-07

  Stats: 414 lines in 3 files changed: 0 ins; 410 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <APXhHhCmSmtSgE7-D_oiy7_DFNdzKqfEdkOmQUkXVMc=.e66a486a-0074-4756-a5d5-903fc4a4cbd0@github.com>

On Thu, 5 Jun 2025 09:37:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/java/io/FileInputStream.java line 219:

> 217:             }
> 218:         } finally {
> 219:             FileReadEvent.offer(start, path, bytesRead);

Thanks for this update, this looks much better. It think would be better again if `start = FileReadEvent.timestamp()` is moved to before the try.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 328:

> 326:         } finally {
> 327:             long end = FileReadEvent.timestamp();
> 328:             FileReadEvent.offer(start, path, bytesRead);

I don't think "end" is needed now.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 382:

> 380:             FileWriteEvent.offer(start, path, bytes);
> 381:         }
> 382:         return bytes;

The method returns the number of bytes written and traceImplRead uses bytesRead for the number of bytes read. So I think better to leave it as bytesWritten.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128400058
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128401565
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128406420

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
Message-ID: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>

On Thu, 5 Jun 2025 00:21:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
>> 
>> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
>> 
>> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.
>
> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
> 
> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
> 
> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128398824

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
 <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
Message-ID: <Zwcb_hQVZmXxEiB91eADdb60FeRk8-8g5VfbolZa1FA=.3d4e5d5b-6653-4adc-9c9d-06e06b7d2977@github.com>

On Thu, 5 Jun 2025 09:31:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
>> 
>> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
>> 
>> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.
>
> I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

Thank you for this update, it looks much better now. I chatted briefly with Stuart yesterday and mostly agreed there would need to be some follow-up cleanup of the use-sites. Doing in now is good as it addresses our grumblings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128410969

From alanb at openjdk.org  Thu Jun  5 09:48:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:48:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <QzDSW4zb1mvKE02K7Lqu-i0ORDvEpXM5AXglPU0MkrM=.8cb32924-10cf-4734-8bef-ca5820d47ac2@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1252:

> 1250:         } finally {
> 1251:             long bytes = bytesWritten > 0 ? bytesWritten : 0;
> 1252:             FileWriteEvent.offer(start, path, bytes);

The number of bytes written is >=0, it can't be < 0, so I'm not sure why the existing code checks bytesWritten > 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128429546

From alanb at openjdk.org  Thu Jun  5 09:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:54:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/jdk.jfr/share/conf/jfr/default.jfc line 845:

> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
> 844:       <setting name="stackTrace">true</setting>
> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>

What was used to proposed 100/s as the default and 300/s in profile.jfc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128442250

From egahlin at openjdk.org  Thu Jun  5 10:10:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:10:41 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8beb194a..45adc081

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=07-08

  Stats: 35 lines in 4 files changed: 0 ins; 16 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From alanb at openjdk.org  Thu Jun  5 10:37:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 10:37:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

src/java.base/share/classes/java/lang/Throwable.java line 124:

> 122:      * exceptions should be traced by JFR.
> 123:      */
> 124:     static boolean jfrTracing;

Are you sure this is okay?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128525269

From egahlin at openjdk.org  Thu Jun  5 10:51:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:51:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
 <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
Message-ID: <-LaEF0pmA3xzw9HcVJlYD91h2ek-nUAfB3BQ1NG--Is=.381146ec-7a22-4fc1-aa2c-032726bc134b@github.com>

On Thu, 5 Jun 2025 09:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the mistakenly added file.
>>  - Fix whitespace
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 845:
> 
>> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
>> 844:       <setting name="stackTrace">true</setting>
>> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>
> 
> What was used to propose 100/s as the default and 300/s in profile.jfc?  Just curious if there was a benchmark or test to see the overhead.

It's hard to benchmark since it depends on the application, but we have used 150 events / second for the Object Allocation Sample event without complaints. If you divide one second by 20 ms, the previous threshold, you end up with at most 50 events / second per thread. That said, I think few applications actually have socket read/write around 20-25 ms, so I don't think we should draw too many conclusions from that.

Another way of thinking about it is that the cost of walking maximum 64 stack frames is roughly 5000 ns, so we end up with 100 * 5000 = 500 000 ns or 0.05% of CPU usage. There is also the cost of sampling, and that's why I put in the 1 ms threshold, which puts an upper bound of 1000 sampling attempts per thread.

For profile, I used the same value as Object Allocation Sample.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128549389

From alanb at openjdk.org  Thu Jun  5 11:07:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 11:07:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <iDfQv5IiGJsRClkYco3XrTBrU1XbMUPxSXQ9YlwfA88=.5656cc2f-d519-4eab-951a-5c36babd57c0@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

The usages are much cleaner in the update so I think this all good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899855765

From egahlin at openjdk.org  Thu Jun  5 11:10:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:10:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
 <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
Message-ID: <dk_r3oQg_7Ir8nrdVEVm3K3iJ8JX5GM6Bx9iC8k7jXc=.35d39c84-62a2-474a-9c3d-8496474dddee@github.com>

On Thu, 5 Jun 2025 10:35:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code
>
> src/java.base/share/classes/java/lang/Throwable.java line 124:
> 
>> 122:      * exceptions should be traced by JFR.
>> 123:      */
>> 124:     static boolean jfrTracing;
> 
> Are you sure this is okay?

When JFR starts the JVM is brought to safepoint so the whole heap becomes visible. We have used it for socket events without any issues.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128580995

From egahlin at openjdk.org  Thu Jun  5 11:20:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:20:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <FjjoB-kxB5mI8i2jb_jxw9kkTbwzudcRZnmXQmdWdms=.4446bbc6-7c65-4200-8fd8-9660b7dc30cb@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Thanks for the reviews, the offer methods turned out nicely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2943787262

From mgronlun at openjdk.org  Thu Jun  5 11:35:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 5 Jun 2025 11:35:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <gn5HwfhUBgCGFVHOTLTYdpOyCN1GJ2_cJtAmKGIsiBI=.7a0fd2dd-0584-4b56-a15b-29dcf16c7b7d@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899934064

From egahlin at openjdk.org  Thu Jun  5 11:39:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:39:01 GMT
Subject: Integrated: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <AhEyXqirLtAgGs8Pkoa2uv6V1EyWqdENXIwyjcE_lxY=.957d323b-e3cd-413f-934d-e183bf6b43e5@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: eb770a06
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb770a060ad86d69b38df7d11622e9e25a528e1d
Stats:     1346 lines in 37 files changed: 1056 ins; 174 del; 116 mod

8351594: JFR: Rate-limited sampling of Java events

Reviewed-by: mgronlun, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Thu Jun  5 12:59:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 12:59:01 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594
Message-ID: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>

Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?

Testing:  make test TEST="micro:java.net.SocketEventOverhead"

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25661/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358689
  Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25661/head:pull/25661

PR: https://git.openjdk.org/jdk/pull/25661

From alanb at openjdk.org  Thu Jun  5 13:01:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 13:01:52 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594
In-Reply-To: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
Message-ID: <n5dJ49i91RaJF6nksJXkkcaxn1ChP8h2GDGW25nFq9E=.5ebb0f5b-6625-4f03-b01a-0c13e2282159@github.com>

On Thu, 5 Jun 2025 12:49:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
> 
> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
> 
> Thanks
> Erik

I assume you'll bump the copyright header date before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25661#pullrequestreview-2900233674

From alanb at openjdk.org  Thu Jun  5 13:08:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 13:08:37 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594 [v2]
In-Reply-To: <SJbRU5TUwuClu518OxbrWgS6FlAjWyLHDsgv_JQxoI8=.4bca96b2-6cd5-4e9d-9822-396106e518c2@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
 <SJbRU5TUwuClu518OxbrWgS6FlAjWyLHDsgv_JQxoI8=.4bca96b2-6cd5-4e9d-9822-396106e518c2@github.com>
Message-ID: <INWvZPDKCK2brT4tRVULII5aQpz1m410AGhceg0PbYY=.017aad4d-4140-49ad-b716-9ca1b4a9501e@github.com>

On Thu, 5 Jun 2025 13:05:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
>> 
>> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright header date

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25661#pullrequestreview-2900255555

From egahlin at openjdk.org  Thu Jun  5 13:08:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 13:08:37 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594 [v2]
In-Reply-To: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
Message-ID: <SJbRU5TUwuClu518OxbrWgS6FlAjWyLHDsgv_JQxoI8=.4bca96b2-6cd5-4e9d-9822-396106e518c2@github.com>

> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
> 
> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright header date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25661/files
  - new: https://git.openjdk.org/jdk/pull/25661/files/d7fac3dc..9720d063

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25661&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25661&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25661/head:pull/25661

PR: https://git.openjdk.org/jdk/pull/25661

From egahlin at openjdk.org  Thu Jun  5 13:11:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 13:11:56 GMT
Subject: Integrated: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594
In-Reply-To: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
Message-ID: <r_MPuRk3gTEN5qXaceNF8A7JQN4JiHciDqLonPRJvBg=.e3153a6a-038d-4d2a-952d-140853ab6d3b@github.com>

On Thu, 5 Jun 2025 12:49:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
> 
> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 33ed7c18
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33ed7c1842e61664c1ad0ea4d29f20728c89e06c
Stats:     13 lines in 1 file changed: 0 ins; 6 del; 7 mod

8358689: test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build  after JDK-8351594

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25661

From vyazici at openjdk.org  Thu Jun  5 13:36:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 13:36:00 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
Message-ID: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>

Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.

Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.

`tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

-------------

Commit messages:
 - Remove redundant tests
 - Remove redundant OIO usage in `RequestPublishers`

Changes: https://git.openjdk.org/jdk/pull/25662/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358688
  Stats: 744 lines in 3 files changed: 10 ins; 731 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From michaelm at openjdk.org  Thu Jun  5 13:41:51 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Jun 2025 13:41:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <CiYqkEPrqUFI0pTty0rmfqNhiCai5qzBlLWErW7shsQ=.1781f325-bc7a-4e88-bc6f-4f0e57acdca3@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>
 <CiYqkEPrqUFI0pTty0rmfqNhiCai5qzBlLWErW7shsQ=.1781f325-bc7a-4e88-bc6f-4f0e57acdca3@github.com>
Message-ID: <tzuoZ1uxqjAS6n7iWittbisexIBAy5juTyhKY6-hNlw=.2c40e15e-3543-4e26-9898-bdf4ee75e443@github.com>

On Thu, 5 Jun 2025 05:31:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:
>> 
>>> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>>> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
>>> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>> 
>> Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.
>> 
>> Something like:
>> 
>> 
>> static final String NOW_PLUS_500 =
>>     DateTimeFormatter.RFC_1123_DATE_TIME.format(
>>         java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));
>> 
>> ...
>> 
>> 
>>     new Test(1000, NOW_PLUS_500, 1000, false),
>> 
>> 
>> Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.
>
> Alternatively, we could create a `HttpCookie::parse` method<sup>1</sup> accepting a `long currentTimeMillis`, and precisely determine the expected value?
> 
> <sup>1</sup> This can either be private and accessed via reflection, or package-private and accessed by placing the test in the same package.

I'll look into doing both of those. So long as we are immune to timing related issues it seems reasonable. By the way, I will push an implementation update first, which results from existing cookie regression failures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2128885121

From michaelm at openjdk.org  Thu Jun  5 13:48:15 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Jun 2025 13:48:15 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v2]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <TROcHX3i30qFRqW6TMktbK2I21tJ7BwaHRCo970SoxQ=.b883f00f-758c-4f01-a17d-27bd538e8f3b@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - copyright
 - impl update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/cf25c055..53d5c25e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=00-01

  Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From michaelm at openjdk.org  Thu Jun  5 13:48:15 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Jun 2025 13:48:15 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v2]
In-Reply-To: <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>
Message-ID: <LKv5Ilu5XVcEkrOmBRHYHsVA77stsf8BNC8cs73jIME=.66b2b095-14f3-4e18-b1f3-6c3b86c11775@github.com>

On Thu, 5 Jun 2025 05:32:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Aren't we missing a `@run` tag?

@run defaults to running the main method

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2128895452

From jpai at openjdk.org  Thu Jun  5 14:02:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 14:02:49 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:

> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");

Hello Volkan, just some initial comments. I think this `Files.isRegularFile(...)` check and the `Files.newInputStream(...)` call should be done in `RequestPublishers.create(...)` instead of here in subscribe. That way the checks happen when the `BodyPublishers.ofFile(...)` gets invoked instead of at subscription time. That then means that this `FilePublisher` will continue to accept a `InputStream` in its constructor, created out of a successful call to `Files.newInputStream()`. 

Moving these checks and call into `RequestPublishers.create(...)` will also mean that we won't need the code comments explaining why a `FileNotFoundException` gets thrown, because both `BodyPublishers.ofFile(...)` and the (internal) `RequestPublishers.create(...)` are already specified to throw `FileNotFoundException`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2128933747

From jpai at openjdk.org  Thu Jun  5 14:05:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 14:05:50 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Also removing certain test files which were rendered redundant after SecurityManager removal. We do this in this PR, since tests were added due to touched lines.

I think, if it's possible, then it might still be better to remove those tests independently in a separate task. That way that issue can be linked to the SecurityManager removal work in https://bugs.openjdk.org/browse/JDK-8338411. But please wait for Daniel's suggestion on whether it needs to be a separate task.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2944565919

From jpai at openjdk.org  Thu Jun  5 14:09:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 14:09:51 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <2yNe_fisaiWeFYpJl03YfXn0pD064-TXp192iM23ObE=.96a8ae4d-469a-4090-92c4-aaaca921c75b@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

While at it, I think we should also introduce a regression test which does a `BodyPublishers.ofFile(Path)` against a `Path` provided by a ZIP filesystem or some such filesystem which was the cause for failures reported in https://bugs.openjdk.org/browse/JDK-8235459.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2944592755

From dfuchs at openjdk.org  Thu Jun  5 15:21:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 5 Jun 2025 15:21:51 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
Message-ID: <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>

On Thu, 5 Jun 2025 13:59:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
> 
>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
> 
> Hello Volkan, just some initial comments. I think this `Files.isRegularFile(...)` check and the `Files.newInputStream(...)` call should be done in `RequestPublishers.create(...)` instead of here in subscribe. That way the checks happen when the `BodyPublishers.ofFile(...)` gets invoked instead of at subscription time. That then means that this `FilePublisher` will continue to accept a `InputStream` in its constructor, created out of a successful call to `Files.newInputStream()`. 
> 
> Moving these checks and call into `RequestPublishers.create(...)` will also mean that we won't need the code comments explaining why a `FileNotFoundException` gets thrown, because both `BodyPublishers.ofFile(...)` and the (internal) `RequestPublishers.create(...)` are already specified to throw `FileNotFoundException`

Good idea. FWIW, and ulness I'm mistaken, I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if  using  a non-default filesystem. If `FileNotFoundException` is specified and `NoSuchFileException` is not then that's probably a good change of behaviour.

Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2129108800

From dfuchs at openjdk.org  Thu Jun  5 15:26:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 5 Jun 2025 15:26:54 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <Na5AXkI3TELZroBSi9CnRpgiRVXomFi6pVqIvvXyt_Y=.ade76034-384c-4fb9-9b21-b28f11e94473@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Yes on both counts. Note that the removed tests where also using ZipFileSystem. It would be better to remove them with another PR, after this change is integrated, and only if we can say with certainty that whatever they test is already covered by other tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2944977728

From mullan at openjdk.org  Thu Jun  5 17:47:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 17:47:54 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

Some initial comments.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:

> 262:      * the peer (if any).
> 263:      *
> 264:      * @since 1.5

I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:

> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 394:                     SSLLogger.fine("Ignore alias " + alias +
> 395:                             ": certificate list does not conform to " +

suggest saying "certificate chain" not "certificate list".

test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:

> 242:      * @throws IOException if an encoding error occurs.
> 243:      */
> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)

variables usually start with lower case letter, so suggest `ipAddresses`

-------------

PR Review: https://git.openjdk.org/jdk/pull/25016#pullrequestreview-2900744862
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129536065
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129556680
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129090967

From mullan at openjdk.org  Thu Jun  5 19:34:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 19:34:53 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1:

> 1: /*

Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT.

test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:

> 1: /*

I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.

Please add some more comments explaining how the exception case occurs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129881920
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2130018039

From vyazici at openjdk.org  Fri Jun  6 07:41:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:41:00 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
Message-ID: <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>

On Thu, 5 Jun 2025 15:19:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
>> 
>>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
>> 
>> Hello Volkan, just some initial comments. I think this `Files.isRegularFile(...)` check and the `Files.newInputStream(...)` call should be done in `RequestPublishers.create(...)` instead of here in subscribe. That way the checks happen when the `BodyPublishers.ofFile(...)` gets invoked instead of at subscription time. That then means that this `FilePublisher` will continue to accept a `InputStream` in its constructor, created out of a successful call to `Files.newInputStream()`. 
>> 
>> Moving these checks and call into `RequestPublishers.create(...)` will also mean that we won't need the code comments explaining why a `FileNotFoundException` gets thrown, because both `BodyPublishers.ofFile(...)` and the (internal) `RequestPublishers.create(...)` are already specified to throw `FileNotFoundException`
>
> Good idea. FWIW, and ulness I'm mistaken, I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if  using  a non-default filesystem. If `FileNotFoundException` is specified and `NoSuchFileException` is not then that's probably a good change of behaviour.
> 
> Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.

Placing `isRegularFile()` check to `create()` indeed was my initial attempt too. Though that resulted in a behavior change: Earlier the regular file check was performed by `FIS::new` at subscription, hence, `NSFE` (yes, `FIS::new` throws `NSFE` when passed a not-regular file, e.g., a directory) was thrown at `subscribe()`. Moving this check from `subscribe()` to `create()` breaks the `RelayingPublishers` test, since failure gets moved from subscription-time to [reactive pipeline] assembly-time.

Would you prefer me to

1. keep things as is,
2. move `isRegularFile()` to `create()`, or
3. move `isRegularFile()` to `create()` and file a CSR?

Note that I don't think we can avoid the `NSFE`-to-`FNFE` translation in `subscribe()`, since, whatever earlier check we do before `Files::newIS`, file might get changed afterwards, and `NSFE` can still be thrown at the `Files::newIS` invocation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131681143

From vyazici at openjdk.org  Fri Jun  6 07:46:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:46:56 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
Message-ID: <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>

On Fri, 6 Jun 2025 07:38:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Good idea. FWIW, and ulness I'm mistaken, I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if  using  a non-default filesystem. If `FileNotFoundException` is specified and `NoSuchFileException` is not then that's probably a good change of behaviour.
>> 
>> Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.
>
> Placing `isRegularFile()` check to `create()` indeed was my initial attempt too. Though that resulted in a behavior change: Earlier the regular file check was performed by `FIS::new` at subscription, hence, `NSFE` (yes, `FIS::new` throws `NSFE` when passed a not-regular file, e.g., a directory) was thrown at `subscribe()`. Moving this check from `subscribe()` to `create()` breaks the `RelayingPublishers` test, since failure gets moved from subscription-time to [reactive pipeline] assembly-time.
> 
> Would you prefer me to
> 
> 1. keep things as is,
> 2. move `isRegularFile()` to `create()`, or
> 3. move `isRegularFile()` to `create()` and file a CSR?
> 
> Note that I don't think we can avoid the `NSFE`-to-`FNFE` translation in `subscribe()`, since, whatever earlier check we do before `Files::newIS`, file might get changed afterwards, and `NSFE` can still be thrown at the `Files::newIS` invocation.

> I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if using a non-default filesystem.

@dfuch, correct. If `Path` is associated with a file system that doesn't support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` exceptions (which were indeed undocumented), whereas others would get `FIS::new` exceptions.

<sup>1</sup> Allow me to note that I intentionally avoid using "default file system" term, since, IMHO, that distracts us from the problem: file systems that don't support `Path::toFile`. The "default file system" is required to support that feature, but there can be other file systems that support that too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131690023

From vyazici at openjdk.org  Fri Jun  6 07:49:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:49:52 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>
Message-ID: <Etcw0mg_sgramkurmIIbMUrNa0sOab7UUjFTebx-x4g=.b132b48c-c265-469d-9b2d-98197cad628a@github.com>

On Thu, 5 Jun 2025 14:03:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> it might still be better to remove those tests independently in a separate task.

@jaikiran, sure, will do.

> While at it, I think we should also introduce a regression test which does a `BodyPublishers.ofFile(Path)` against a `Path` provided by a ZIP filesystem or some such filesystem which was the cause for failures reported in https://bugs.openjdk.org/browse/JDK-8235459.

Such a test already exists: `FilePublisherTest`. I deleted its SM counterpart: `FilePublisherPermsTest`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948394630

From vyazici at openjdk.org  Fri Jun  6 08:11:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 08:11:35 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Add back removed SM tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/b5f3c8dc..0a7800ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=00-01

  Stats: 701 lines in 2 files changed: 701 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From dfuchs at openjdk.org  Fri Jun  6 08:11:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:11:36 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <Etcw0mg_sgramkurmIIbMUrNa0sOab7UUjFTebx-x4g=.b132b48c-c265-469d-9b2d-98197cad628a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>
 <Etcw0mg_sgramkurmIIbMUrNa0sOab7UUjFTebx-x4g=.b132b48c-c265-469d-9b2d-98197cad628a@github.com>
Message-ID: <6bVFj_49jC11m63oxVFaKgIv0vMr6FsW7PmNrkerp1E=.5b4e8ee8-a5d3-4cc8-a200-91d5cf3a08bf@github.com>

On Fri, 6 Jun 2025 07:47:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Such a test already exists: FilePublisherTest. I deleted its SM counterpart: FilePublisherPermsTest.

This test seems to test more things and less things than FilePublisherTest (typically it does test FileNotFoundException). We shouldn't simply delete it, but potentially migrate the parts that are not covered by FilePublisherTest into FilePublisherTest first. Best done in another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948435629

From dfuchs at openjdk.org  Fri Jun  6 08:23:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:23:55 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
Message-ID: <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>

On Fri, 6 Jun 2025 07:44:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Placing `isRegularFile()` check to `create()` indeed was my initial attempt too. Though that resulted in a behavior change: Earlier the regular file check was performed by `FIS::new` at subscription, hence, `NSFE` (yes, `FIS::new` throws `NSFE` when passed a not-regular file, e.g., a directory) was thrown at `subscribe()`. Moving this check from `subscribe()` to `create()` breaks the `RelayingPublishers` test, since failure gets moved from subscription-time to [reactive pipeline] assembly-time.
>> 
>> Would you prefer me to
>> 
>> 1. keep things as is,
>> 2. move `isRegularFile()` to `create()`, or
>> 3. move `isRegularFile()` to `create()` and file a CSR?
>> 
>> Note that I don't think we can avoid the `NSFE`-to-`FNFE` translation in `subscribe()`, since, whatever earlier check we do before `Files::newIS`, file might get changed afterwards, and `NSFE` can still be thrown at the `Files::newIS` invocation.
>
>> I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if using a non-default filesystem.
> 
> @dfuch, correct. If `Path` is associated with a file system that doesn't support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` exceptions (which were indeed undocumented), whereas others would get `FIS::new` exceptions.
> 
> <sup>1</sup> Allow me to note that I intentionally avoid using "default file system" term, since, IMHO, that distracts us from the problem: file systems that don't support `Path::toFile`. The "default file system" is required to support that feature, but there can be other file systems that support that too.

OK

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131745751

From dfuchs at openjdk.org  Fri Jun  6 08:30:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:30:50 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
Message-ID: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>

On Fri, 6 Jun 2025 08:11:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back removed SM tests

The new version LGTM. I wonder if we should add `@bug 8358688` to the various FilePublisher test - or just consider the fix as noreg-cleanup. On the one hand those tests might have failed if you hadn't catched and transformed NSFE. On the other hand they should pass whether this fix is present or not...

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:

> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");

I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948485426
PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131758853

From vyazici at openjdk.org  Fri Jun  6 11:07:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:07:34 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Update tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/0a7800ab..9fce1c3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=01-02

  Stats: 29 lines in 2 files changed: 23 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From vyazici at openjdk.org  Fri Jun  6 11:07:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:07:34 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
Message-ID: <Kg5B8VmeMikyLo8su3hCkKp3-HX4UY8BfNY6Oh-8IYU=.6bb19b5a-3d26-4292-b0f3-a0ada1e57b30@github.com>

On Fri, 6 Jun 2025 08:25:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I wonder if we should add `@bug 8358688` to the various FilePublisher test - or just consider the fix as noreg-cleanup. On the one hand those tests might have failed if you hadn't catched and transformed NSFE. On the other hand they should pass whether this fix is present or not...

In 9fce1c3b763, I've

- Added `@bug 8358688` to both `RelayingPublishers` and `FilePublisherTest`
- Copied missing `testFileNotFound()` from `FilePublisherPermsTest` to `FilePublisherTest`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948901297

From vyazici at openjdk.org  Fri Jun  6 11:09:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:09:51 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
Message-ID: <_EMK2LGYPHG7H97xiE92w2nVTO18Xf0TQMv3-wreRE8=.88849d54-f02f-4e8a-842f-db9da6c91606@github.com>

On Fri, 6 Jun 2025 08:28:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back removed SM tests
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
> 
>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
> 
> I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

I also wanted to keep the `nsfe` as the cause, though `FNFE::new` doesn't have a public ctor accepting a `Throwable`.

> Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

Not really:


jshell> java.nio.file.Files.newInputStream(java.nio.file.Path.of("/foo"))
|  Exception java.nio.file.NoSuchFileException: /foo
|        at UnixException.translateToIOException (UnixException.java:92)
|        at UnixException.rethrowAsIOException (UnixException.java:106)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131998716

From dfuchs at openjdk.org  Fri Jun  6 11:15:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 11:15:54 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
Message-ID: <wk8UD9XvDgqanuaFhXuwpC_Xh1DRnQAV2MDXCKIauHc=.d862f1a9-80bb-4aec-9e5b-35c6af19395c@github.com>

On Fri, 6 Jun 2025 11:07:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update tests

LGTM. Maybe wait for comments from @jaikiran before integrating

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2904613238

From dfuchs at openjdk.org  Fri Jun  6 11:15:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 11:15:57 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <_EMK2LGYPHG7H97xiE92w2nVTO18Xf0TQMv3-wreRE8=.88849d54-f02f-4e8a-842f-db9da6c91606@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
 <_EMK2LGYPHG7H97xiE92w2nVTO18Xf0TQMv3-wreRE8=.88849d54-f02f-4e8a-842f-db9da6c91606@github.com>
Message-ID: <NdCTzAMJy09mLdEqbFzzbk1CgGHk4znzb9LxHvKAMaQ=.736d0591-116e-4865-8ef6-71ae5cfeec51@github.com>

On Fri, 6 Jun 2025 11:07:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
>> 
>>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
>> 
>> I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?
>
> I also wanted to keep the `nsfe` as the cause, though `FNFE::new` doesn't have a public ctor accepting a `Throwable`.
> 
>> Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?
> 
> Not really:
> 
> 
> jshell> java.nio.file.Files.newInputStream(java.nio.file.Path.of("/foo"))
> |  Exception java.nio.file.NoSuchFileException: /foo
> |        at UnixException.translateToIOException (UnixException.java:92)
> |        at UnixException.rethrowAsIOException (UnixException.java:106)

Ok - doesn't look too useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132003924

From vyazici at openjdk.org  Fri Jun  6 11:15:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:15:58 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
Message-ID: <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>

On Fri, 6 Jun 2025 08:21:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if using a non-default filesystem.
>> 
>> @dfuch, correct. If `Path` is associated with a file system that doesn't support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` exceptions (which were indeed undocumented), whereas others would get `FIS::new` exceptions.
>> 
>> <sup>1</sup> Allow me to note that I intentionally avoid using "default file system" term, since, IMHO, that distracts us from the problem: file systems that don't support `Path::toFile`. The "default file system" is required to support that feature, but there can be other file systems that support that too.
>
> OK

> The "default file system" is required to support that feature, but there can be other file systems that support that too.

I need to amend this statement: Per [`Path::toFile` specification]( https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()), except the default one obtained by `FileSystems::getDefault`, `FileSystem` implementations are expected to throw `UnsupportedOperationException` on `Path::toFile`. Note that this is enforced by the specification; there is technically nothing blocking a custom `FileSystem` implementation from returning a `File` (i.e., not throwing `UOE`) from `Path::toFile`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132007324

From dfuchs at openjdk.org  Fri Jun  6 11:51:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 11:51:49 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
 <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
Message-ID: <qPDBtQfr4R0zffTC5tVfG40jB7oxwTvtEK0MMYPP33E=.8b344ae4-dbeb-4bde-91a1-b434efa994b3@github.com>

On Fri, 6 Jun 2025 11:13:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> OK
>
>> The "default file system" is required to support that feature, but there can be other file systems that support that too.
> 
> I need to amend this statement: Per [`Path::toFile` specification]( https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()), except the default one obtained by `FileSystems::getDefault`, `FileSystem` implementations are expected to throw `UnsupportedOperationException` on `Path::toFile`. Note that this is enforced by the specification; there is technically nothing blocking a custom `FileSystem` implementation from returning a `File` (i.e., not throwing `UOE`) from `Path::toFile`.

Thanks for the clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132050544

From dfuchs at openjdk.org  Fri Jun  6 12:00:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 12:00:37 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:

 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - Improve key destruction
 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=06
  Stats: 103750 lines in 473 files changed: 100888 ins; 1345 del; 1517 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From duke at openjdk.org  Fri Jun  6 14:39:16 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:39:16 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v2]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <iAIKam-Y0DptYiFNv8b89gA5VOVXc45Jm1Hc4OjH8fs=.43c78b9f-0337-42c0-a623-bffe50fa0cef@github.com>

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

p-nima has updated the pull request incrementally with one additional commit since the last revision:

  apply review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/cdf78127..2d032564

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=00-01

  Stats: 252 lines in 2 files changed: 136 ins; 116 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Fri Jun  6 14:50:52 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:50:52 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v2]
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <5Nw4daRUMKo4zKdiidcXAPovdy2dmjXILgFYDxxv9xY=.4702cc59-03ea-4178-b2f8-2767f1a23f47@github.com>

On Fri, 30 May 2025 09:06:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   apply review feedback
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 113:
> 
>> 111:                 }
>> 112:                 e.printStackTrace();
>> 113:             }
> 
> AFAICT, you should be using `assertThrows` as follows:
> 
> 
> IOException exception = assertThrows(...);
> assertEquals(exception.message(), "too many authentication attempts. Limit: " + RETRY_LIMIT);
> assertEquals(requestCount.get(), RETRY_LIMIT > 0 ? RETRY_LIMIT : 1);

The changes have been made in 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9- We decrement the request count because we authenticate the request at least once before the limit is checked. A call to math.max can be done but I think the ternary operator helps to reduce the overhead of the call, wdyt?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132339249

From duke at openjdk.org  Fri Jun  6 14:58:47 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:58:47 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <YDBkhUM6CsyFC-R7BFtO3KllioNrEm4i8rIiugG02Qc=.777450cf-af08-4074-8f80-af3eb9c78cfb@github.com>

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

p-nima has updated the pull request incrementally with one additional commit since the last revision:

  update summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/2d032564..24cc8944

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Fri Jun  6 14:58:48 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:58:48 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
Message-ID: <Eq0VGcGQWCBew_NDHtivWFUDBc3_KrXm9OjGMDPK18w=.6868817e-675c-4b12-abba-885f12ecd531@github.com>

On Fri, 30 May 2025 15:01:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 57:
>> 
>>> 55: 
>>> 56: 
>>> 57: class HttpClientRetryLimitTest implements HttpServerAdapters {
>> 
>> Shall we rename this to `HttpClientAuthRetryLimit`, since [there are several other retry limits](https://docs.oracle.com/en/java/javase/23/docs/api/java.net.http/module-summary.html#jdk.httpclient.auth.retrylimit)?
>
> Sounds reasonable to rename - and fix the `@summary` in the jtreg headers too

This has been updated in 24cc89442f55434c6c9cc2f625981cd7e11eba45

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132352498

From duke at openjdk.org  Fri Jun  6 15:23:59 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 15:23:59 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <j8kATbwXIRZTjbxtiU-8AhBrowm_9mpkOKBcIewOh_0=.05c56b0d-4d1a-4b04-9206-5fe8dfdea18e@github.com>

On Fri, 30 May 2025 14:42:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update summary
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 64:
> 
>> 62:             "jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
>> 63: 
>> 64:     static Stream<HttpClient.Version> args() {
> 
> I think we should also test against with SSL and without SSL cases. See `HttpResponseLimitingTest.ServerClientPair` for inspiration.

We now test it with both the scenarios - 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 88:
> 
>> 86:             try (
>> 87:                 HttpClient client = HttpClient.newBuilder()
>> 88:                         .authenticator(new Authenticator() {
> 
> To ensure the client will fire the request using the protocol version of our preference, could you also pass `version` to the client builder too, please?

As we now set the version on the request, so we no longer need to set it on the client - 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132392565
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132394794

From mullan at openjdk.org  Fri Jun  6 15:24:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 6 Jun 2025 15:24:04 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
>> 
>> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 401:

> 399:                 continue;
> 400:             }
> 401: 

I think we should also call `CertType.check` here, like in `X509KeyManagerImpl`. Since this change is now only selecting certificates with algorithms that are not disabled, I think it also makes sense to select certificates that have the proper extensions, etc and will not cause subsequent certificate chain validation failures.

This means we would have to change the name of the property so that it isn't only about disabling constraints checking. Perhaps: `jdk.tls.keymanager.disableCertSelectionChecking`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerConstraints.java line 170:

> 168:     }
> 169: 
> 170:     protected boolean isConstraintsDisabled() {

Make this private? Not sure why it would need to be overridden.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132394682
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132187663

From duke at openjdk.org  Fri Jun  6 16:03:54 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 16:03:54 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <eUKTQoMLizthB1AosSLK-iRspUOs09DVlVTjqYYsc34=.5d4e1c09-ce04-4205-bb31-c127afef425b@github.com>

On Fri, 30 May 2025 09:08:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update summary
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 73:
> 
>> 71:     @ParameterizedTest
>> 72:     @MethodSource("args")
>> 73:     public void testDefaultSystemProperty(HttpClient.Version version) throws Exception {
> 
> I see you made the class package-private in 18bac9f. You could have additionally made the method package-private too.

I have changed it to default - Based on the junit [documentation](https://junit.org/junit5/docs/5.11.0/api/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedTest.html) we should not mark such methods as private or static


> @ParameterizedTest is used to signal that the annotated method is a parameterized test method.
> Such methods must not be private or static.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132462294

From abarashev at openjdk.org  Fri Jun  6 16:21:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 16:21:59 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
Message-ID: <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>

On Thu, 5 Jun 2025 19:31:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
> 
>> 1: /*
> 
> I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.
> 
> Please add some more comments explaining how the exception case occurs.

Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests for each:

1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132486696

From abarashev at openjdk.org  Fri Jun  6 16:53:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 16:53:51 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
Message-ID: <Dr8nXtVReKyM-yLEjr8LBerGUo-GjP_HhhmqTujd3S8=.44c27f3a-63ac-4b07-9e76-7c23b61c3d49@github.com>

On Fri, 6 Jun 2025 13:20:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerConstraints.java line 170:
> 
>> 168:     }
>> 169: 
>> 170:     protected boolean isConstraintsDisabled() {
> 
> Make this private? Not sure why it would need to be overridden.

If we have a consensus on keeping `jdk.tls.keymanager.disableConstraintsChecking` toggle as is, then I'm going to remove this method and do this check directly in the constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132534993

From hchao at openjdk.org  Fri Jun  6 20:03:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 6 Jun 2025 20:03:57 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
 <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
Message-ID: <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>

On Thu, 15 May 2025 19:29:07 GMT, Sean Mullan <mullan at openjdk.org> 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 property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> > 
> > 
> > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> > @seanjmullan What do you think?
> 
> Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.

I'd agree. As I mentioned in my earlier comment, if the new system property ends up toggling behavior in both `SunX509KeyManager` and `X509KeyManagerImpl`, we could run into an unintended side effect. While we're adding compliant algorithm constraints checking to `SunX509KeyManager`, turning on the property to disable it for compatibility reasons would also disable the already-existing checking in `X509KeyManagerImpl`. The applications already relying on the stricter checks in `X509KeyManagerImpl` might lose that enforcement unintentionally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2950663297

From abarashev at openjdk.org  Fri Jun  6 21:13:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 21:13:51 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
Message-ID: <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>

On Fri, 6 Jun 2025 15:20:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 401:
> 
>> 399:                 continue;
>> 400:             }
>> 401: 
> 
> I think we should also call `CertType.check` here, like in `X509KeyManagerImpl`. Since this change is now only selecting certificates with algorithms that are not disabled, I think it also makes sense to select certificates that have the proper extensions, etc and will not cause subsequent certificate chain validation failures.
> 
> This means we would have to change the name of the property so that it isn't only about disabling constraints checking. Perhaps: `jdk.tls.keymanager.disableCertSelectionChecking`.

Yes, makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132913338

From abarashev at openjdk.org  Fri Jun  6 21:21:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 21:21:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
Message-ID: <EW0TYxe6HMEHe7iAFt3W70PGrm3ZpCy6cZhzWe1GR2Q=.00e86f02-0bd4-46dc-97b1-7f5c8b3173a9@github.com>

On Thu, 5 Jun 2025 17:40:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:
> 
>> 262:      * the peer (if any).
>> 263:      *
>> 264:      * @since 1.5
> 
> I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

Done.

> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:
> 
>> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 394:                     SSLLogger.fine("Ignore alias " + alias +
>> 395:                             ": certificate list does not conform to " +
> 
> suggest saying "certificate chain" not "certificate list".

Done. Also changing the same message in `X509KeyManagerImpl`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132920769
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132919667

From abarashev at openjdk.org  Fri Jun  6 23:22:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 23:22:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
Message-ID: <gcFQMFOoDfItWveSNHHS_NcV5dqK4EdvUh556otCgsQ=.ab3ae941-5a95-43fb-a541-a7e280cd6346@github.com>

On Thu, 5 Jun 2025 15:10:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:
> 
>> 242:      * @throws IOException if an encoding error occurs.
>> 243:      */
>> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)
> 
> variables usually start with lower case letter, so suggest `ipAddresses`

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2133067693

From abarashev at openjdk.org  Fri Jun  6 23:34:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 23:34:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
Message-ID: <3EASChBurpIG_iq35iGkr7MYrc79c0jl_RNb7sbqYkk=.65d9df1a-9e96-4e8e-a409-c9f9d7eef597@github.com>

On Thu, 5 Jun 2025 19:00:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1:
> 
>> 1: /*
> 
> Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT.

You mean `SunX509` KeyManager? All these existing tests I'm modifying in this PR are using it together with the certificates signed with `MD5withRSA` algorithm. That's why they fail when we add algorithm constraints to SunX509KeyManagerImpl - MD5 is not allowed in TLSv1.3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2133073579

From julian.reschke at gmx.de  Sun Jun  8 15:23:22 2025
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sun, 8 Jun 2025 17:23:22 +0200
Subject: https://bugs.openjdk.org/browse/JDK-8294196
In-Reply-To: <bb67daf7-8cc3-4848-be41-9a12bad6f866@gmx.de>
References: <bb67daf7-8cc3-4848-be41-9a12bad6f866@gmx.de>
Message-ID: <175c5353-3add-4d31-9a28-f5125e1cae5c@gmx.de>

On 09.01.2025 15:30, Julian Reschke wrote:
> Hi there.
> 
> I'd like to get back to the topic
> 
> "Investigate introducing an API on the HttpClient which allows
> applications to get access to "interim" HTTP responses" --
> https://bugs.openjdk.org/browse/JDK-8294196
> 
> To avoid confusion: the *bugs* with respect to handling 1xx responses
> have been thankfully fixed (see
> https://github.com/openjdk/jdk/pull/10229 and
> https://github.com/openjdk/jdk/pull/10169).
> 
> What's still missing is a way to actually inspect the contents of the
> 1xx messages while waiting for a final response (status >= 200). That
> could be a callback that provides the status code and the response
> header fiels when 1xx messages are received.
> 
> This would be useful when processing 103 messages (Early Hints - RFC
> 8297) or 104 messages (Upload Resumption Supported - used for
> "draft-ietf-httpbis-resumable-upload").
> 
> Use cases are summarized over here:
> 
>  ?https://github.com/greenbytes/java-http-1xx-tests
> 
> (tests live here as well).
> 
> Let me know if more information is needed.
> 
> Best regards, Julian

Ping. What is the best way to get this considered? I was asked to 
document use cases, and I think I did. Is there anything missing? I'll 
happily expand that section if needed...

Best regards, Julian

From jai.forums2013 at gmail.com  Sun Jun  8 16:05:53 2025
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 8 Jun 2025 21:35:53 +0530
Subject: https://bugs.openjdk.org/browse/JDK-8294196
In-Reply-To: <175c5353-3add-4d31-9a28-f5125e1cae5c@gmx.de>
References: <bb67daf7-8cc3-4848-be41-9a12bad6f866@gmx.de>
 <175c5353-3add-4d31-9a28-f5125e1cae5c@gmx.de>
Message-ID: <70f521c9-48fe-4be5-a883-2dc4b750b1ee@gmail.com>

I've assigned that issue to myself. I haven't checked the latest state 
of some of the (draft) RFCs linked in this discussion. I will do so in 
the coming days.

-Jaikiran

On 08/06/25 8:53 pm, Julian Reschke wrote:
> On 09.01.2025 15:30, Julian Reschke wrote:
>> Hi there.
>>
>> I'd like to get back to the topic
>>
>> "Investigate introducing an API on the HttpClient which allows
>> applications to get access to "interim" HTTP responses" --
>> https://bugs.openjdk.org/browse/JDK-8294196
>>
>> To avoid confusion: the *bugs* with respect to handling 1xx responses
>> have been thankfully fixed (see
>> https://github.com/openjdk/jdk/pull/10229 and
>> https://github.com/openjdk/jdk/pull/10169).
>>
>> What's still missing is a way to actually inspect the contents of the
>> 1xx messages while waiting for a final response (status >= 200). That
>> could be a callback that provides the status code and the response
>> header fiels when 1xx messages are received.
>>
>> This would be useful when processing 103 messages (Early Hints - RFC
>> 8297) or 104 messages (Upload Resumption Supported - used for
>> "draft-ietf-httpbis-resumable-upload").
>>
>> Use cases are summarized over here:
>>
>> ??https://github.com/greenbytes/java-http-1xx-tests
>>
>> (tests live here as well).
>>
>> Let me know if more information is needed.
>>
>> Best regards, Julian
>
> Ping. What is the best way to get this considered? I was asked to 
> document use cases, and I think I did. Is there anything missing? I'll 
> happily expand that section if needed...
>
> Best regards, Julian

From jpai at openjdk.org  Sun Jun  8 16:40:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 8 Jun 2025 16:40:55 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <qPDBtQfr4R0zffTC5tVfG40jB7oxwTvtEK0MMYPP33E=.8b344ae4-dbeb-4bde-91a1-b434efa994b3@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
 <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
 <qPDBtQfr4R0zffTC5tVfG40jB7oxwTvtEK0MMYPP33E=.8b344ae4-dbeb-4bde-91a1-b434efa994b3@github.com>
Message-ID: <bOSSIEW9loQca0FR2ha-R8F1EHz9Ep-Q_JpbARcvA4Y=.eda33611-24b7-4379-8cd8-40a7bffe9e9e@github.com>

On Fri, 6 Jun 2025 11:49:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> The "default file system" is required to support that feature, but there can be other file systems that support that too.
>> 
>> I need to amend this statement: Per [`Path::toFile` specification]( https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()), except the default one obtained by `FileSystems::getDefault`, `FileSystem` implementations are expected to throw `UnsupportedOperationException` on `Path::toFile`. Note that this is enforced by the specification; there is technically nothing blocking a custom `FileSystem` implementation from returning a `File` (i.e., not throwing `UOE`) from `Path::toFile`.
>
> Thanks for the clarification.

Hello Volkan,

> Earlier the regular file check was performed by FIS::new at subscription, hence, NSFE (yes, FIS::new throws NSFE when passed a not-regular file, e.g., a directory) was thrown at subscribe()

The `NoSuchFileException` is a NIO construct and resides in `java.nio.file` package. So the older `java.io.FileInputStream`'s constructor throwing a `NoSuchFileException` felt odd to me. So I tried this:


jshell> new FileInputStream(new File("/tmp"))


that throws a `FileNotFoundException` (which is understandable) and not a `NoSuchFileException`


|  Exception java.io.FileNotFoundException: /tmp (Is a directory)
|        at FileInputStream.open0 (Native Method)
|        at FileInputStream.open (FileInputStream.java:185)
|        at FileInputStream.<init> (FileInputStream.java:139)
|        at (#1:1)


Was it something else in that test failure which was throwing the `NoSuchFileException`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2134763715

From alan.bateman at oracle.com  Sun Jun  8 17:22:17 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 8 Jun 2025 18:22:17 +0100
Subject: Suggestion needed to port the fix to JDK17 and JDK11S
In-Reply-To: <SJ0PR15MB4663D5C27435718507DBA5C0CC60A@SJ0PR15MB4663.namprd15.prod.outlook.com>
References: <SJ0PR15MB4663E34342AC2F9AC8A876AACCFC2@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB46631AD45E4B42C4A39F008DCCC22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ef07a775-f954-4051-a0e9-59100c7715c3@oracle.com>
 <SJ0PR15MB46638A0DE787D32EFABAA8E1CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ec39b10b-5271-41cf-aa7f-d3f915ee0a18@oracle.com>
 <SJ0PR15MB4663123A5C03544060DC27E9CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <8861a349-6446-4326-b168-e9594aeef70b@oracle.com>
 <SJ0PR15MB4663C04ADCBC69EFEF78C71CCCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <d79fdfb8-e717-4c73-8c0c-3fae0fadce01@oracle.com>
 <SJ0PR15MB4663218DFB930F6B6EF9F211CCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <a8254bdf-a678-4ceb-94d7-77253372101e@oracle.com>
 <SJ0PR15MB4663B9DE26624483CA466C4CCCB52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB466351A414A67F29EC88EC19CC98A@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB4663D5C27435718507DBA5C0CC60A@SJ0PR15MB4663.namprd15.prod.outlook.com>
Message-ID: <0fc08923-09de-47d2-8b95-e4132df8a857@oracle.com>

On 31/05/2025 20:12, Shruthi . wrote:
> Hi Alan,
>
> I wanted to follow up on the update I shared earlier
> I?ve successfully backported the preClose re-order changes to *JDK 
> 17*?and ran the |Race.java|?test case *500 times*. It passed 
> consistently without any failures. For validation, I also ran the test 
> *without the patch*, and it failed on the *first iteration*. I ran the 
> tests under *java/nio*?to see if there is any regression and all the 
> testcases are passing.
> Currently, we are running the tests under |java/net|.
>
>  *
>     Do you recommend running any additional test groups?
>  *
>     Also, can we proceed with porting the preClose re-order fix to
>     *headstream*?
>
> Please let me know your thoughts.

Good to hear that the preClose changes helped. I think the next step is 
to create a PR for JDK main line.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250608/fe63284c/attachment.htm>

From julian.reschke at gmx.de  Mon Jun  9 05:14:56 2025
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 9 Jun 2025 07:14:56 +0200
Subject: https://bugs.openjdk.org/browse/JDK-8294196
In-Reply-To: <2cc32bfa-11fc-4b4d-96b6-1f88101a501a@gmail.com>
References: <bb67daf7-8cc3-4848-be41-9a12bad6f866@gmx.de>
 <2cc32bfa-11fc-4b4d-96b6-1f88101a501a@gmail.com>
Message-ID: <7cce1101-9c4f-4af9-be7b-04b706a90bd8@gmx.de>

On 28.01.2025 15:05, Jaikiran Pai wrote:
> Thank you Julian for this. We do plan to pursue this enhancement further 
> with the inputs that we have received so far. Once the change/PR is 
> ready for review, I'll respond here.
> ...

Thanks a lot.

Best regards, Julian

From jpai at openjdk.org  Mon Jun  9 07:44:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Jun 2025 07:44:32 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout
Message-ID: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>

Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.

As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.

If this requires a CSR, I'll open one once we settle on the proposed text.

-------------

Commit messages:
 - 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout

Changes: https://git.openjdk.org/jdk/pull/25690/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7116990
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25690/head:pull/25690

PR: https://git.openjdk.org/jdk/pull/25690

From dfuchs at openjdk.org  Mon Jun  9 10:01:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 10:01:59 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout
In-Reply-To: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
Message-ID: <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>

On Mon, 9 Jun 2025 07:39:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
> 
> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
> 
> If this requires a CSR, I'll open one once we settle on the proposed text.

src/java.base/share/classes/java/net/Socket.java line 625:

> 623:      *
> 624:      * @apiNote Establishing a TCP/IP connection is subject to connection timeout settings
> 625:      * in the operating system. The typical timeout is 60 seconds. If the operating system

Suggestion:

     * in the operating system. The typical operating system timeout is 60 seconds. If the operating system


I would suggest repeating "operating system timeout" here too, to remove confusion with the simple API `timeout` which also appears later in this paragraph.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2135432484

From duke at openjdk.org  Mon Jun  9 10:59:26 2025
From: duke at openjdk.org (kieran-farrell)
Date: Mon, 9 Jun 2025 10:59:26 GMT
Subject: RFR: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
Message-ID: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>

Intermittent failures have been seen with HttpURLConnectionExpectContinueTest on macOS possible due to the test using the host systems proxy configuations. 
 
Failures seen on JDK11 and JDK17 but adding no proxy conifguration to other JDK versions as a preventative measure.

Mach5 results:
https://mach5.us.oracle.com/mdash/jobs?search=id:kieranfarrell-jdk25u-20250609-0917-29256940

-------------

Commit messages:
 - noproxy

Changes: https://git.openjdk.org/jdk/pull/25692/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25692&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358617
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25692/head:pull/25692

PR: https://git.openjdk.org/jdk/pull/25692

From dfuchs at openjdk.org  Mon Jun  9 11:17:19 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 11:17:19 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v3]
In-Reply-To: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
Message-ID: <gSs6LZaFYB1bYsiNnaKUaktbpz1-EjDi0ZyW_vlznRQ=.743a20b6-98c4-428e-94ca-8c141793d814@github.com>

> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
> 
> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
> 
> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
> 
> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.

Daniel Fuchs 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 six additional commits since the last revision:

 - A better fix
 - Merge branch 'master' into DigestEchoClient-cleanup-8357639
 - Access pendingSubscriptions only from InternalReadSubscriptionImpl - and synchronize offer/handle to avoid concurrent removal from the queue
 - Merge branch 'master' into DigestEchoClient-cleanup-8357639
 - Avoid unnecessary volatile reads
 - 8357639

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25416/files
  - new: https://git.openjdk.org/jdk/pull/25416/files/ad1b28a1..8d728707

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=01-02

  Stats: 50263 lines in 838 files changed: 26474 ins; 14478 del; 9311 mod
  Patch: https://git.openjdk.org/jdk/pull/25416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25416/head:pull/25416

PR: https://git.openjdk.org/jdk/pull/25416

From dfuchs at openjdk.org  Mon Jun  9 11:33:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 11:33:55 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v3]
In-Reply-To: <gSs6LZaFYB1bYsiNnaKUaktbpz1-EjDi0ZyW_vlznRQ=.743a20b6-98c4-428e-94ca-8c141793d814@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
 <gSs6LZaFYB1bYsiNnaKUaktbpz1-EjDi0ZyW_vlznRQ=.743a20b6-98c4-428e-94ca-8c141793d814@github.com>
Message-ID: <AAG1isU4EzwImX670fsvyCQkMcZ7ITjZVWvjTM8CSbw=.e56c0e9d-c164-4924-a351-9ef225d8565f@github.com>

On Mon, 9 Jun 2025 11:17:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
>> 
>> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
>> 
>> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
>> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
>> 
>> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.
>
> Daniel Fuchs 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 six additional commits since the last revision:
> 
>  - A better fix
>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>  - Access pendingSubscriptions only from InternalReadSubscriptionImpl - and synchronize offer/handle to avoid concurrent removal from the queue
>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>  - Avoid unnecessary volatile reads
>  - 8357639

@djelinski managed to find the exact place where to put a Thread.sleep() to reproduce the issue more often. Thanks to that I was able to come with a better fix. The issue no longer reproduces. The fix is too call `handle` in the read subscribe event, instead of `readScheduler.readOrSchedule`. Indeed the `read` loop calls `handle` and is supposed to return after handling pending subscriptions. But if the pending subscription has been already handled it could proceed to read and end up reading from the socket at the wrong time. I also changed the `pendingSubscriptions` from queue to `AtomicReference` since with the additional synchronization we are now certain that there can be only one pending subscriber in the queue at any given time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25416#issuecomment-2955521761

From jpai at openjdk.org  Mon Jun  9 11:43:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Jun 2025 11:43:04 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
Message-ID: <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>

> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
> 
> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
> 
> If this requires a CSR, I'll open one once we settle on the proposed text.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25690/files
  - new: https://git.openjdk.org/jdk/pull/25690/files/909d7d27..d6978f0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25690/head:pull/25690

PR: https://git.openjdk.org/jdk/pull/25690

From jpai at openjdk.org  Mon Jun  9 11:43:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 9 Jun 2025 11:43:04 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
Message-ID: <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>

On Mon, 9 Jun 2025 09:59:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Daniel's suggestion
>
> src/java.base/share/classes/java/net/Socket.java line 625:
> 
>> 623:      *
>> 624:      * @apiNote Establishing a TCP/IP connection is subject to connection timeout settings
>> 625:      * in the operating system. The typical timeout is 60 seconds. If the operating system
> 
> Suggestion:
> 
>      * in the operating system. The typical operating system timeout is 60 seconds. If the operating system
> 
> 
> I would suggest repeating "operating system timeout" here too, to remove confusion with the simple API `timeout` which also appears later in this paragraph.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2135566991

From alanb at openjdk.org  Mon Jun  9 12:02:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Jun 2025 12:02:10 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
Message-ID: <dOq3vfPZvj2c_T16QcZ4W4PPFRKUFc4Z2qwq1f1JvnY=.09745d9b-40b5-4e34-80ac-6e73361d32ac@github.com>

On Mon, 9 Jun 2025 11:43:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion

Good

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2909850481

From dfuchs at openjdk.org  Mon Jun  9 13:01:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 13:01:50 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
Message-ID: <f5VsDyt2BL5BIMibUiRr-g_gC65hr5LRGdV-NaY8bcw=.dd92eea2-0c0f-4244-a510-ce9f40aee3cc@github.com>

On Mon, 9 Jun 2025 11:43:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion

Not sure this requires a CSR. It might - if only for the sake of clarifying expectations for JCK too.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2909999468

From msheppar at openjdk.org  Mon Jun  9 13:01:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 9 Jun 2025 13:01:52 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
Message-ID: <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>

On Mon, 9 Jun 2025 11:40:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 625:
>> 
>>> 623:      *
>>> 624:      * @apiNote Establishing a TCP/IP connection is subject to connection timeout settings
>>> 625:      * in the operating system. The typical timeout is 60 seconds. If the operating system
>> 
>> Suggestion:
>> 
>>      * in the operating system. The typical operating system timeout is 60 seconds. If the operating system
>> 
>> 
>> I would suggest repeating "operating system timeout" here too, to remove confusion with the simple API `timeout` which also appears later in this paragraph.
>
> Done

FWIW:
Stating a typical value of 60 seconds timeout can lead to a misconception ... From from TCP standards and depending on which literature you read (OS docs or unix networking socket programming) then 75 secs should be a more typical default 

I think the 60 seconds comes from a perceived setting on linux.

It would be better to say that, the value is OS dependent, influenced by OS network setting relating to syn receive timeouts and the number of syn retries, and governed by the TCP retransmission timer implementation, rather than stating a particular value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2135676303

From dfuchs at openjdk.org  Mon Jun  9 13:56:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 13:56:13 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v4]
In-Reply-To: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
Message-ID: <PgrJMvSAkHFXvSO-4KTBtaYTBOmqlaJG1vZkKWFFr3U=.04e7e8ac-b311-489c-bdcb-a784701d0541@github.com>

> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
> 
> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
> 
> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
> 
> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.

Daniel Fuchs 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 eight additional commits since the last revision:

 - Merge branch 'master' into DigestEchoClient-cleanup-8357639
 - Logging
 - A better fix
 - Merge branch 'master' into DigestEchoClient-cleanup-8357639
 - Access pendingSubscriptions only from InternalReadSubscriptionImpl - and synchronize offer/handle to avoid concurrent removal from the queue
 - Merge branch 'master' into DigestEchoClient-cleanup-8357639
 - Avoid unnecessary volatile reads
 - 8357639

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25416/files
  - new: https://git.openjdk.org/jdk/pull/25416/files/8d728707..b27f1220

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=02-03

  Stats: 991 lines in 79 files changed: 713 ins; 126 del; 152 mod
  Patch: https://git.openjdk.org/jdk/pull/25416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25416/head:pull/25416

PR: https://git.openjdk.org/jdk/pull/25416

From dfuchs at openjdk.org  Mon Jun  9 14:25:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 14:25:57 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <YDBkhUM6CsyFC-R7BFtO3KllioNrEm4i8rIiugG02Qc=.777450cf-af08-4074-8f80-af3eb9c78cfb@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YDBkhUM6CsyFC-R7BFtO3KllioNrEm4i8rIiugG02Qc=.777450cf-af08-4074-8f80-af3eb9c78cfb@github.com>
Message-ID: <aAbCopwwh7CTC321_DmmM9bxB9gl4-vdOtQjaZWspxk=.0a34a096-7685-4e52-9341-dd901bc1dad1@github.com>

On Fri, 6 Jun 2025 14:58:47 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update summary

test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 132:

> 130:                 assertEquals("too many authentication attempts. Limit: " + RETRY_LIMIT, exception.getMessage());
> 131:                 assertEquals(RETRY_LIMIT > 0 ? RETRY_LIMIT : 0,
> 132:                         RETRY_LIMIT > 0 ? requestCount.get():requestCount.decrementAndGet());

Could you split that in two statements for better readability? The double ternary operator makes it difficult to parse.


    if (RETRY_LIMIT > 0) {
        assertEquals(...);
    } else {
        assertEquals(...);
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2135814102

From dfuchs at openjdk.org  Mon Jun  9 14:25:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 14:25:58 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <aAbCopwwh7CTC321_DmmM9bxB9gl4-vdOtQjaZWspxk=.0a34a096-7685-4e52-9341-dd901bc1dad1@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YDBkhUM6CsyFC-R7BFtO3KllioNrEm4i8rIiugG02Qc=.777450cf-af08-4074-8f80-af3eb9c78cfb@github.com>
 <aAbCopwwh7CTC321_DmmM9bxB9gl4-vdOtQjaZWspxk=.0a34a096-7685-4e52-9341-dd901bc1dad1@github.com>
Message-ID: <j1uGlFviosLmF4a7ma0Y_1tVFX_F9nLOHZNHIKlhqUI=.0401df70-4063-4143-9ab5-e8619e81f580@github.com>

On Mon, 9 Jun 2025 14:19:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update summary
>
> test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 132:
> 
>> 130:                 assertEquals("too many authentication attempts. Limit: " + RETRY_LIMIT, exception.getMessage());
>> 131:                 assertEquals(RETRY_LIMIT > 0 ? RETRY_LIMIT : 0,
>> 132:                         RETRY_LIMIT > 0 ? requestCount.get():requestCount.decrementAndGet());
> 
> Could you split that in two statements for better readability? The double ternary operator makes it difficult to parse.
> 
> 
>     if (RETRY_LIMIT > 0) {
>         assertEquals(...);
>     } else {
>         assertEquals(...);
>     }

Also it would be better not to change the request count. The request count should only be changed by the Authenticator. Maybe introducing a variable:

   int expectedRequetedCount = ...;

would be beneficial.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2135819215

From michaelm at openjdk.org  Mon Jun  9 14:40:41 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 9 Jun 2025 14:40:41 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v3]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <z5_7vlLZhekitwmejaDRkAjUVJ2dmB0U6GO6Nb0_wwk=.e8de4331-4071-4af9-b063-cc5811b124ea@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon 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 10 additional commits since the last revision:

 - Merge branch 'master' into cookie-8351983
 - copyright
 - impl update
 - whitespace
 - update
 - impl and test + doc update
 - Merge branch 'master' into cookie-8351983
 - doc update
 - further doc update
 - doc update only

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/53d5c25e..ef975706

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=01-02

  Stats: 22681 lines in 502 files changed: 18987 ins; 1928 del; 1766 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From dfuchs at openjdk.org  Mon Jun  9 16:27:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Jun 2025 16:27:52 GMT
Subject: RFR: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
In-Reply-To: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>
References: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>
Message-ID: <1ctOUyZg-APa3LWeZrsU1_zCKLaHU6WUxLIh_Xwq0ag=.efa31e44-f2ff-4933-a9cf-5438de96564f@github.com>

On Mon, 9 Jun 2025 10:54:29 GMT, kieran-farrell <duke at openjdk.org> wrote:

> Intermittent failures have been seen with HttpURLConnectionExpectContinueTest on macOS possible due to the test using the host systems proxy configuations. 
>  
> Failures seen on JDK11 and JDK17 but adding no proxy conifguration to other JDK versions as a preventative measure.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25692#pullrequestreview-2910589619

From duke at openjdk.org  Mon Jun  9 16:39:51 2025
From: duke at openjdk.org (duke)
Date: Mon, 9 Jun 2025 16:39:51 GMT
Subject: RFR: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
In-Reply-To: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>
References: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>
Message-ID: <bUGIZ-aR4vj7m7JoknrUWmNygbxzvR4RzoQd80Fw_kA=.1667298d-5726-47e8-810a-21a0c28b217f@github.com>

On Mon, 9 Jun 2025 10:54:29 GMT, kieran-farrell <duke at openjdk.org> wrote:

> Intermittent failures have been seen with HttpURLConnectionExpectContinueTest on macOS possible due to the test using the host systems proxy configuations. 
>  
> Failures seen on JDK11 and JDK17 but adding no proxy conifguration to other JDK versions as a preventative measure.

@kieran-farrell 
Your change (at version c78ddbd64846ede3711949523bd7d25522d60f99) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25692#issuecomment-2956315050

From duke at openjdk.org  Mon Jun  9 17:42:57 2025
From: duke at openjdk.org (kieran-farrell)
Date: Mon, 9 Jun 2025 17:42:57 GMT
Subject: Integrated: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
In-Reply-To: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>
References: <csyWD3ekLkLqRes9ZBnMygH0W5q6WrzhplyNSHLRIUY=.47dd5827-10ee-4b3e-9343-5967748d992f@github.com>
Message-ID: <IUH5bcRWkN67qE329LOk96kV-04ncq_macy85neR_wQ=.6ddc8b49-e1f7-462f-930d-5b93be350c92@github.com>

On Mon, 9 Jun 2025 10:54:29 GMT, kieran-farrell <duke at openjdk.org> wrote:

> Intermittent failures have been seen with HttpURLConnectionExpectContinueTest on macOS possibly due to the test using the host systems proxy configurations. 
>  
> Failures seen on JDK11 and JDK17 but adding no proxy conifguration to other JDK versions as a preventative measure.

This pull request has now been integrated.

Changeset: a377773f
Author:    kieran-farrell <kieran.farrell at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a377773fa76b46ac98533c61bc1410485390115e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358617: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with 403 due to system proxies

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25692

From abarashev at openjdk.org  Mon Jun  9 21:51:38 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 9 Jun 2025 21:51:38 GMT
Subject: RFR: 8273042: TLS Certificate Compression
In-Reply-To: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
References: <WZJV1PTvW-BUS7sqMuFhHI5P-KvOTWpqPskHNyefKRg=.63da5c42-4c76-40f5-a470-074724c124bb@github.com>
Message-ID: <r5qFM-YedWRWurk1oi0ykWAfkuV-FCKO-LpEL5c3kFk=.c7af1248-767f-4fe1-861d-fcb41f144b93@github.com>

On Wed, 23 Feb 2022 20:15:24 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> Please review the implementation of RFC 8879, TLS Certificate Compression, in JDK.  The TLS Certificate Compression standard is an essential part for QUIC connections and performance improvement for TLS connections.  More details, please refer to the [JEP](https://bugs.openjdk.java.net/browse/JDK-8281710) proposal.
> 
> The JEP was submitted, and it may take time for the final approval.  But let me know you ideas and concerns about the proposal and implementation.
> 
> JEP: https://bugs.openjdk.java.net/browse/JDK-8281710

test/jdk/javax/net/ssl/HttpsURLConnection/HttpsCompressedCert.java line 64:

> 62:     public static void main(String[] args) throws Exception {
> 63:         SSLParameters sslParameters = new SSLParameters();
> 64:         sslParameters.setCertificateInflaters(Map.of("brotli", certInflater));

Why `brotli` compression is being requested here when JDK doesn't support it? Looks like Google doesn't send a compressed certificate back, that's why this test works, the supplied `certInflater` function is using ZLIB.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/7599#discussion_r2136560698

From djelinski at openjdk.org  Tue Jun 10 07:11:31 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Jun 2025 07:11:31 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v4]
In-Reply-To: <PgrJMvSAkHFXvSO-4KTBtaYTBOmqlaJG1vZkKWFFr3U=.04e7e8ac-b311-489c-bdcb-a784701d0541@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
 <PgrJMvSAkHFXvSO-4KTBtaYTBOmqlaJG1vZkKWFFr3U=.04e7e8ac-b311-489c-bdcb-a784701d0541@github.com>
Message-ID: <WovqGt-RHteKh-wMAWSMfikhbXCNdFDCv2xQjh5sO8Q=.fc853a11-e445-43ce-aebc-af0de546bfae@github.com>

On Mon, 9 Jun 2025 13:56:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
>> 
>> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
>> 
>> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
>> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
>> 
>> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.
>
> Daniel Fuchs 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>  - Logging
>  - A better fix
>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>  - Access pendingSubscriptions only from InternalReadSubscriptionImpl - and synchronize offer/handle to avoid concurrent removal from the queue
>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>  - Avoid unnecessary volatile reads
>  - 8357639

LGTM.

src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java line 931:

> 929:             synchronized void offer(TubeSubscriber sub) {
> 930:                 ReadSubscription target = new ReadSubscription(this, sub);
> 931:                 ReadSubscription previous = pendingSubscriptions.getAndSet(target);

now that all access to pendingSubscription is synchronized, it doesn't need to be an AtomicReference, a regular field will work just as well.

src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java line 956:

> 954:                 ReadSubscription current = subscription;
> 955:                 ReadSubscription pending = pendingSubscriptions.getAndSet(null);
> 956:                 if (pending  != null) {

Suggestion:

                if (pending != null) {

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25416#pullrequestreview-2912234681
PR Review Comment: https://git.openjdk.org/jdk/pull/25416#discussion_r2137077228
PR Review Comment: https://git.openjdk.org/jdk/pull/25416#discussion_r2137083771

From dfuchs at openjdk.org  Tue Jun 10 09:54:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 09:54:47 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v5]
In-Reply-To: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
Message-ID: <rqUmru6kNW9IAZQmA49ZZB20hNubRdQ2gZr-2frBeK0=.6c6f512e-8b6e-42d7-b994-5e1bfdd9e689@github.com>

> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
> 
> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
> 
> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
> 
> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25416/files
  - new: https://git.openjdk.org/jdk/pull/25416/files/b27f1220..eb8d0df7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25416&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25416/head:pull/25416

PR: https://git.openjdk.org/jdk/pull/25416

From dfuchs at openjdk.org  Tue Jun 10 09:54:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 09:54:48 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v4]
In-Reply-To: <WovqGt-RHteKh-wMAWSMfikhbXCNdFDCv2xQjh5sO8Q=.fc853a11-e445-43ce-aebc-af0de546bfae@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
 <PgrJMvSAkHFXvSO-4KTBtaYTBOmqlaJG1vZkKWFFr3U=.04e7e8ac-b311-489c-bdcb-a784701d0541@github.com>
 <WovqGt-RHteKh-wMAWSMfikhbXCNdFDCv2xQjh5sO8Q=.fc853a11-e445-43ce-aebc-af0de546bfae@github.com>
Message-ID: <7b4mV-i-S-_3YNRQNgskuVXg_6-IhWLE1WJBJ6aOqWc=.ceef12f3-b005-48ee-8360-123754af4389@github.com>

On Tue, 10 Jun 2025 07:03:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs 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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>>  - Logging
>>  - A better fix
>>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>>  - Access pendingSubscriptions only from InternalReadSubscriptionImpl - and synchronize offer/handle to avoid concurrent removal from the queue
>>  - Merge branch 'master' into DigestEchoClient-cleanup-8357639
>>  - Avoid unnecessary volatile reads
>>  - 8357639
>
> src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java line 931:
> 
>> 929:             synchronized void offer(TubeSubscriber sub) {
>> 930:                 ReadSubscription target = new ReadSubscription(this, sub);
>> 931:                 ReadSubscription previous = pendingSubscriptions.getAndSet(target);
> 
> now that all access to pendingSubscription is synchronized, it doesn't need to be an AtomicReference, a regular field will work just as well.

Ah, good point. But it makes it possible to use getAndSet(). I'm inclined to keep it just for that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25416#discussion_r2137417591

From jpai at openjdk.org  Tue Jun 10 10:31:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Jun 2025 10:31:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <VK3OPea665iZC9L0afD3lLokdgrTbNj_kbiYZFe2Xf8=.885395b6-9daa-421b-8c5a-09722b236052@github.com>
Message-ID: <USriuw2Xh65pMGKkP2rtqvWiOfWEs_8hj_V18XdgH9A=.f0225d4f-95e2-4a10-9514-a4c595dc6035@github.com>

On Fri, 25 Apr 2025 19:07:37 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 192:
> 
>> 190:      */
>> 191:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 192:                                         String[] allowedAlgorithms,
> 
> This should probably be renamed to `supportedAlgorithms` for consistency, to match SSLEngine and SSLSocket methods.

Done, the PR has been updated to rename this to supportedAlgorithms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2137500358

From djelinski at openjdk.org  Tue Jun 10 10:43:34 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Jun 2025 10:43:34 GMT
Subject: RFR: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool [v5]
In-Reply-To: <rqUmru6kNW9IAZQmA49ZZB20hNubRdQ2gZr-2frBeK0=.6c6f512e-8b6e-42d7-b994-5e1bfdd9e689@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
 <rqUmru6kNW9IAZQmA49ZZB20hNubRdQ2gZr-2frBeK0=.6c6f512e-8b6e-42d7-b994-5e1bfdd9e689@github.com>
Message-ID: <qcq88nDwDiW_sLP_9FBWSH5rxfYMb4f_62QNJOTH_r4=.b1b21ec1-9826-4d95-9ae2-948182c2fbb9@github.com>

On Tue, 10 Jun 2025 09:54:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
>> 
>> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
>> 
>> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
>> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
>> 
>> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25416#pullrequestreview-2912955239

From dfuchs at openjdk.org  Tue Jun 10 11:04:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 11:04:33 GMT
Subject: Integrated: 8357639: DigestEchoClient fails intermittently due to:
 java.io.IOException: Data received while in pool
In-Reply-To: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
References: <YKXbun0Klo3E0NBb3T2kU-ikqbQY-ti_JhZmQg0RhfI=.545e98a9-3079-4999-9e5b-f717326650b1@github.com>
Message-ID: <UkakAXS7ODfKUgyYmaMQK4IdskaWuFr48P6-GE-SjDo=.b2a384a0-3fe3-4825-8e23-4065c91e462d@github.com>

On Fri, 23 May 2025 14:35:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The java/net/httpclient/DigestEchoClient.java fails intemittently with IOException: HTTP/1.1 header parser received no bytes.
> 
> Analysis shows that this is caused by the CleanupTrigger which receives data after the reused connection has been taken out of the HTTP/1.1 clear pool (Caused by: java.io.IOException: Data received while in pool). This should not happen.
> 
> The fix for [JDK-8338569](https://bugs.openjdk.org/browse/JDK-8338569) has improved the situation but apparently didn't fix the issue completely.
> The issue is that the write publisher manages to come active before the read subscriber has been switched, which opens a window in which the old read subscriber receives the data that should have been passed to the new one.
> 
> To fix that, this change  proposes to pause reading at the selector level before connecting the flows with the new publisher /subscriber pair. This should ensure that data doesn't reach the "old" subscriber, if the new write publisher manage to send data before the new read subscriber is subscribed.

This pull request has now been integrated.

Changeset: 0582bd29
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0582bd290d5a8b6344ae7ada36492cc2f33df050
Stats:     67 lines in 1 file changed: 26 ins; 30 del; 11 mod

8357639: DigestEchoClient fails intermittently due to: java.io.IOException: Data received while in pool

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/25416

From duke at openjdk.org  Tue Jun 10 13:39:19 2025
From: duke at openjdk.org (p-nima)
Date: Tue, 10 Jun 2025 13:39:19 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

p-nima has updated the pull request incrementally with one additional commit since the last revision:

  apply review feedback and improve readability

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/24cc8944..7a9eb0b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=02-03

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Tue Jun 10 13:51:30 2025
From: duke at openjdk.org (p-nima)
Date: Tue, 10 Jun 2025 13:51:30 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <j1uGlFviosLmF4a7ma0Y_1tVFX_F9nLOHZNHIKlhqUI=.0401df70-4063-4143-9ab5-e8619e81f580@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YDBkhUM6CsyFC-R7BFtO3KllioNrEm4i8rIiugG02Qc=.777450cf-af08-4074-8f80-af3eb9c78cfb@github.com>
 <aAbCopwwh7CTC321_DmmM9bxB9gl4-vdOtQjaZWspxk=.0a34a096-7685-4e52-9341-dd901bc1dad1@github.com>
 <j1uGlFviosLmF4a7ma0Y_1tVFX_F9nLOHZNHIKlhqUI=.0401df70-4063-4143-9ab5-e8619e81f580@github.com>
Message-ID: <06MQt6qYpum9MTReDbCHkU6sPZUoPECKsWx-jFjzJFI=.54caa827-c7c2-43ea-8a32-1e250d006df9@github.com>

On Mon, 9 Jun 2025 14:21:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 132:
>> 
>>> 130:                 assertEquals("too many authentication attempts. Limit: " + RETRY_LIMIT, exception.getMessage());
>>> 131:                 assertEquals(RETRY_LIMIT > 0 ? RETRY_LIMIT : 0,
>>> 132:                         RETRY_LIMIT > 0 ? requestCount.get():requestCount.decrementAndGet());
>> 
>> Could you split that in two statements for better readability? The double ternary operator makes it difficult to parse.
>> 
>> 
>>     if (RETRY_LIMIT > 0) {
>>         assertEquals(...);
>>     } else {
>>         assertEquals(...);
>>     }
>
> Also it would be better not to change the request count. The request count should only be changed by the Authenticator. Maybe introducing a variable:
> 
>    int expectedRequetedCount = ...;
> 
> would be beneficial.

Thank you for your review. The changes have been made in 7a9eb0b2969991aafc3d1bdfba283ece6e458370

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2137959494

From duke at openjdk.org  Tue Jun 10 14:38:29 2025
From: duke at openjdk.org (p-nima)
Date: Tue, 10 Jun 2025 14:38:29 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <0C_sJwloPs7L7VPd4UpmVUTJaYt2MBFY34kikdMZvh4=.3409bced-ec41-4ff2-ba15-6d5ee97d95f4@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
 <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>
 <0C_sJwloPs7L7VPd4UpmVUTJaYt2MBFY34kikdMZvh4=.3409bced-ec41-4ff2-ba15-6d5ee97d95f4@github.com>
Message-ID: <BaOA7G0VmLwgnZ4vrSpQv0RFGlHe_xK6Zt0EqOjgfjk=.4aace7d9-230d-48bb-8639-27569b851c8c@github.com>

On Wed, 4 Jun 2025 13:46:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @p-nima, the handler still accepts all calls to `/`, you only salted the request URI. Would you mind doing the same in `httpTestServer.addHandler(...)` too, please? (You better create a `String requestPath` variable and use it both at the handler and the request.)
>
> Yes - this line needs to be modified too.

The changes have been made in 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9. The server handler path has been salted with the requestPath.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2138073937

From dfuchs at openjdk.org  Tue Jun 10 15:13:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 15:13:30 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
Message-ID: <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>

On Tue, 10 Jun 2025 15:09:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   apply review feedback and improve readability
>
> test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 136:
> 
>> 134:                 } else {
>> 135:                     assertEquals(0, totalRequestCount - 1);
>> 136:                 }
> 
> Ok - so now we're getting somewhere. This lets me think that the change in the AuthenticationFilter is not right. The specification says:
> 
>> jdk.httpclient.auth.retrylimit (default: 3)
>> The number of attempts the Basic authentication filter will attempt to retry a failed authentication. 
> 
> When I read this, I expect that if the limit is 0, no retries, then the Authenticator will be called once, and if the authentication fails with these credentials, then the request will fail.
> If the limit is 1, then we will retry once, which means the Authenticator should be called twice, and so on.
> 
> So maybe we should always assert that totalRequestCount == `Math.max(RETRY_LIMIT, 0) + 1`?

@Michael-Mc-Mahon Is my interpretation above correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2138162592

From dfuchs at openjdk.org  Tue Jun 10 15:13:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 10 Jun 2025 15:13:30 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
Message-ID: <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>

On Tue, 10 Jun 2025 13:39:19 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review feedback and improve readability

test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 136:

> 134:                 } else {
> 135:                     assertEquals(0, totalRequestCount - 1);
> 136:                 }

Ok - so now we're getting somewhere. This lets me think that the change in the AuthenticationFilter is not right. The specification says:

> jdk.httpclient.auth.retrylimit (default: 3)
> The number of attempts the Basic authentication filter will attempt to retry a failed authentication. 

When I read this, I expect that if the limit is 0, no retries, then the Authenticator will be called once, and if the authentication fails with these credentials, then the request will fail.
If the limit is 1, then we will retry once, which means the Authenticator should be called twice, and so on.

So maybe we should always assert that totalRequestCount == `Math.max(RETRY_LIMIT, 0) + 1`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2138160412

From abarashev at openjdk.org  Tue Jun 10 22:04:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:04:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <w_IZtUmgo7JbvZayavQbvsBLhMesF1P60iZ-tMJU5-w=.3bd35485-107b-4e10-9a65-b9acb64811f8@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 243:

> 241:         }
> 242:         // QUIC TLS version is mandated to be always TLSv1.3
> 243:         if (!ProtocolVersion.useTLS12PlusSpec(session.getProtocol())) {

Should be `useTLS13PlusSpec`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138839652

From abarashev at openjdk.org  Tue Jun 10 22:12:46 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:12:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <6AU7lGXUVGbSk3B65aPdjokTF3j91LjG445kzW5Hq1Y=.c1580e0d-3ebe-4b0b-8e58-b0233639b295@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 229:

> 227:             // any algorithm constraints when choosing the client alias and
> 228:             // just call the functionally limited
> 229:             // javax.net.ssl.X509KeyManager.chooseClientAlias(...)

This comment should be updated as we do take into account algorithm constraints. I would remove `TODO` word as well, maybe replace it with `NOTE`

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 328:

> 326:                 // any algorithm constraints when choosing the server alias
> 327:                 // and just call the functionally limited
> 328:                 // javax.net.ssl.X509KeyManager.chooseServerAlias(...)

Same as above, update the comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138847212
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138847768

From abarashev at openjdk.org  Tue Jun 10 22:19:41 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:19:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 164:

> 162:      */
> 163:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 164:                                         boolean applyCertPathAlgConstraints) {

This parameter should be called `withDefaultCertPathConstraints` for consistency with other methods.

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 188:

> 186:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
> 187:                                         String[] supportedAlgorithms,
> 188:                                         boolean applyCertPathAlgConstraints) {

Same as above:  should be called `withDefaultCertPathConstraints`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138853006
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138853942

From abarashev at openjdk.org  Tue Jun 10 22:24:42 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:24:42 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
Message-ID: <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>

On Fri, 6 Jun 2025 12:00:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
> 
>  - merge latest changes from master branch
>  - http3: improve H3ConnectionPoolTest.java
>  - Fix snippet
>  - Improve key destruction
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:

> 245:         if (quicEngine != null) {
> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
> 247:                 return engineImpl.getAlgorithmConstraints();

Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138858886

From abarashev at openjdk.org  Tue Jun 10 22:58:44 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 10 Jun 2025 22:58:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
Message-ID: <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>

On Tue, 22 Apr 2025 19:36:00 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:
> 
>> 1219:                         tm.checkClientTrusted(
>> 1220:                                 certs.clone(),
>> 1221:                                 authType);
> 
> This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.

What would be the reason it's not addressed like in `checkServerCerts` below?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2138892993

From vyazici at openjdk.org  Wed Jun 11 08:58:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 08:58:30 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <bOSSIEW9loQca0FR2ha-R8F1EHz9Ep-Q_JpbARcvA4Y=.eda33611-24b7-4379-8cd8-40a7bffe9e9e@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
 <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
 <qPDBtQfr4R0zffTC5tVfG40jB7oxwTvtEK0MMYPP33E=.8b344ae4-dbeb-4bde-91a1-b434efa994b3@github.com>
 <bOSSIEW9loQca0FR2ha-R8F1EHz9Ep-Q_JpbARcvA4Y=.eda33611-24b7-4379-8cd8-40a7bffe9e9e@github.com>
Message-ID: <XQRtuTiqE_5m0TzYXQatlJlTDspB3AYPtiMHuz3xU54=.5bf1b43b-d24d-4df8-bf81-2f90c1787e87@github.com>

On Sun, 8 Jun 2025 16:38:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Thanks for the clarification.
>
> Hello Volkan,
> 
>> Earlier the regular file check was performed by FIS::new at subscription, hence, NSFE (yes, FIS::new throws NSFE when passed a not-regular file, e.g., a directory) was thrown at subscribe()
> 
> The `NoSuchFileException` is a NIO construct and resides in `java.nio.file` package. So the older `java.io.FileInputStream`'s constructor throwing a `NoSuchFileException` felt odd to me. So I tried this:
> 
> 
> jshell> new FileInputStream(new File("/tmp"))
> 
> 
> that throws a `FileNotFoundException` (which is understandable) and not a `NoSuchFileException`
> 
> 
> |  Exception java.io.FileNotFoundException: /tmp (Is a directory)
> |        at FileInputStream.open0 (Native Method)
> |        at FileInputStream.open (FileInputStream.java:185)
> |        at FileInputStream.<init> (FileInputStream.java:139)
> |        at (#1:1)
> 
> 
> Was it something else in that test failure which was throwing the `NoSuchFileException`?

@jaikiran, your observation is correct. My explanation was worded poorly: I did not want to mean `NSFE` was thrown by `FIS::new`, instead I was stressing that _the exception_ was thrown at subscription-time. All in all, my point still stands: I could not move certain checks from `subscribe()` to `create()`, because of subscription- versus assembly-time difference in exception semantics. I will try to rephrase:

* In the old version,
  * if the passed `Path` was associated with the default file system, and hence, supports `Path::toFile`, `FIS::new` of OIO was used and it throws `FNFE` of OIO.
  * Otherwise, `Files::newIS` of NIO was used throwing `NSFE` of NIO.
  * There was no `NSFE`-to-`FNFE` translation for the latter case.
  * Both `FIS::new`/`Files::newIS` invocations were at subscription-time.
* In the new version, only `Files::newIS` is used, at subscription-time, with (hopefully) sufficient `NSFE`-to-`FNFE` translation to preserve the old exception semantics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2139586673

From vyazici at openjdk.org  Wed Jun 11 09:15:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 09:15:29 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
Message-ID: <EaKEgPd_u5FcY0wssudxdx9eL3MpG_sMcNpPXtdP1ic=.a5fbf8e7-4acd-4711-b630-f448fe12eda3@github.com>

On Fri, 6 Jun 2025 11:07:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update tests

> Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.

@dfuch, created [JDK-8359215](https://bugs.openjdk.org/browse/JDK-8359215) for the release note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2961854320

From jpai at openjdk.org  Wed Jun 11 09:53:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 09:53:35 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
Message-ID: <Q2V2lMSGtVqtzS8nKwrqs00mrZZFJ7aBD62cIB7rXcM=.e2b3c80b-9c0a-4ee9-9334-8535a3f3ba03@github.com>

On Fri, 6 Jun 2025 11:07:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update tests

The changes look good to me.

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 268:

> 266:             } catch (NoSuchFileException nsfe) {
> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:

Nit - since the BodyPublishers.ofFile(...) specifies a `FileNotFoundException`, I think a better comment here and a few lines above might be: "// Throw FileNotFoundException to match the specification of BodyPublishers.ofFile()"

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2916446710
PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2139713022

From jpai at openjdk.org  Wed Jun 11 09:53:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 09:53:35 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <XQRtuTiqE_5m0TzYXQatlJlTDspB3AYPtiMHuz3xU54=.5bf1b43b-d24d-4df8-bf81-2f90c1787e87@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
 <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
 <qPDBtQfr4R0zffTC5tVfG40jB7oxwTvtEK0MMYPP33E=.8b344ae4-dbeb-4bde-91a1-b434efa994b3@github.com>
 <bOSSIEW9loQca0FR2ha-R8F1EHz9Ep-Q_JpbARcvA4Y=.eda33611-24b7-4379-8cd8-40a7bffe9e9e@github.com>
 <XQRtuTiqE_5m0TzYXQatlJlTDspB3AYPtiMHuz3xU54=.5bf1b43b-d24d-4df8-bf81-2f90c1787e87@github.com>
Message-ID: <ZZfQY2HGFjwiyf_UT4mMj4CaiAFZFU3uXDUX5KVZdCw=.2cef538d-31c7-49c1-945b-0c6cda16675c@github.com>

On Wed, 11 Jun 2025 08:56:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Hello Volkan,
>> 
>>> Earlier the regular file check was performed by FIS::new at subscription, hence, NSFE (yes, FIS::new throws NSFE when passed a not-regular file, e.g., a directory) was thrown at subscribe()
>> 
>> The `NoSuchFileException` is a NIO construct and resides in `java.nio.file` package. So the older `java.io.FileInputStream`'s constructor throwing a `NoSuchFileException` felt odd to me. So I tried this:
>> 
>> 
>> jshell> new FileInputStream(new File("/tmp"))
>> 
>> 
>> that throws a `FileNotFoundException` (which is understandable) and not a `NoSuchFileException`
>> 
>> 
>> |  Exception java.io.FileNotFoundException: /tmp (Is a directory)
>> |        at FileInputStream.open0 (Native Method)
>> |        at FileInputStream.open (FileInputStream.java:185)
>> |        at FileInputStream.<init> (FileInputStream.java:139)
>> |        at (#1:1)
>> 
>> 
>> Was it something else in that test failure which was throwing the `NoSuchFileException`?
>
> @jaikiran, your observation is correct. My explanation was worded poorly: I did not want to mean `NSFE` was thrown by `FIS::new`, instead I was stressing that _the exception_ was thrown at subscription-time. All in all, my point still stands: I could not move certain checks from `subscribe()` to `create()`, because of subscription- versus assembly-time difference in exception semantics. I will try to rephrase:
> 
> * In the old version,
>   * if the passed `Path` was associated with the default file system, and hence, supports `Path::toFile`, `FIS::new` of OIO was used and it throws `FNFE` of OIO.
>   * Otherwise, `Files::newIS` of NIO was used throwing `NSFE` of NIO.
>   * There was no `NSFE`-to-`FNFE` translation for the latter case.
>   * Both `FIS::new`/`Files::newIS` invocations were at subscription-time.
> * In the new version, only `Files::newIS` is used, at subscription-time, with (hopefully) sufficient `NSFE`-to-`FNFE` translation to preserve the old exception semantics.

Hello Volkan, what you have looks good to me. Daniel too explained to me yesterday why this proposed way is a better idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2139714335

From jpai at openjdk.org  Wed Jun 11 10:11:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 10:11:41 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
Message-ID: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>

Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 

The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:


public void setTTL(byte ttl) throws IOException
public byte getTTL() throws IOException


and this other one on `MulticastSocket`:


public void send(DatagramPacket p, byte ttl) throws IOException 


have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.

The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.

Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

-------------

Commit messages:
 - 8332623: Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket, byte)

Changes: https://git.openjdk.org/jdk/pull/25744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332623
  Stats: 442 lines in 19 files changed: 12 ins; 408 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/25744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25744/head:pull/25744

PR: https://git.openjdk.org/jdk/pull/25744

From alanb at openjdk.org  Wed Jun 11 10:26:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 10:26:31 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <splwdKURAY698rTNujlB48ksxTaR7BEPjDXuQRBRCGc=.430d0072-8413-4039-afad-2abb2a578b20@github.com>

On Wed, 11 Jun 2025 10:05:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java line 564:

> 562:     @SuppressWarnings("removal")
> 563:     public void send(DatagramPacket p, byte ttl) throws IOException {
> 564:         sendLock.lock();

sendLock can be removed too, it's only need because of this send method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139773421

From duke at openjdk.org  Wed Jun 11 10:29:35 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 11 Jun 2025 10:29:35 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
Message-ID: <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>

On Tue, 10 Jun 2025 15:10:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 136:
>> 
>>> 134:                 } else {
>>> 135:                     assertEquals(0, totalRequestCount - 1);
>>> 136:                 }
>> 
>> Ok - so now we're getting somewhere. This lets me think that the change in the AuthenticationFilter is not right. The specification says:
>> 
>>> jdk.httpclient.auth.retrylimit (default: 3)
>>> The number of attempts the Basic authentication filter will attempt to retry a failed authentication. 
>> 
>> When I read this, I expect that if the limit is 0, no retries, then the Authenticator will be called once, and if the authentication fails with these credentials, then the request will fail.
>> If the limit is 1, then we will retry once, which means the Authenticator should be called twice, and so on.
>> 
>> So maybe we should always assert that totalRequestCount == `Math.max(RETRY_LIMIT, 0) + 1`?
>
> @Michael-Mc-Mahon Is my interpretation above correct?

@dfuch As per my understanding, the current changes do reflect the correct behaviour, as when the request comes in it first goes through the authenticator. If the authentication fails we need to consider this failure in no of retries. (as the client should not try to get the credentials again) 
@Michael-Mc-Mahon if you could please provide some additional context on this and if my interpretation is correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2139779099

From alanb at openjdk.org  Wed Jun 11 10:30:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 10:30:34 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <4HVVzzXtybAGhlzTgO9OO9i0gY6jOXMFifw-4DgVZHg=.66092864-4ba9-4535-a54c-3adea5f4b3c4@github.com>

On Wed, 11 Jun 2025 10:05:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

test/jdk/java/net/MulticastSocket/SetTTLTo0.java line 26:

> 24: /* @test
> 25:  * @bug 4148757
> 26:  * @summary Make sure MulticastSocket.setTimeToLive() can be set to 0

I think the original okay as this test just checks that you are set the TTL to 0.

test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java line 410:

> 408:         DatagramPacket p = new DatagramPacket(message, message.length);
> 409:         p.setSocketAddress(target);
> 410:         final int oldTTL = s.getTimeToLive();

Just replacing it with s.send(p) should be okay here, no need to set/restore TTL.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139782287
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139778959

From jpai at openjdk.org  Wed Jun 11 10:42:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 10:42:12 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v2]
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - no need to setTimeToLive() in AdaptorMulticasting test
 - undo change to "@summary" of a test
 - remove sendLock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25744/files
  - new: https://git.openjdk.org/jdk/pull/25744/files/934d3357..c0017d07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25744&range=00-01

  Stats: 31 lines in 3 files changed: 0 ins; 26 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25744/head:pull/25744

PR: https://git.openjdk.org/jdk/pull/25744

From jpai at openjdk.org  Wed Jun 11 10:42:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 10:42:12 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v2]
In-Reply-To: <splwdKURAY698rTNujlB48ksxTaR7BEPjDXuQRBRCGc=.430d0072-8413-4039-afad-2abb2a578b20@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <splwdKURAY698rTNujlB48ksxTaR7BEPjDXuQRBRCGc=.430d0072-8413-4039-afad-2abb2a578b20@github.com>
Message-ID: <1_InbStWgQLW4U57SPscWpKF5Zy4QYJyKYulsWNsZwU=.a39fd476-348c-4f1a-89f8-79c8514edd89@github.com>

On Wed, 11 Jun 2025 10:23:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - no need to setTimeToLive() in AdaptorMulticasting test
>>  - undo change to "@summary" of a test
>>  - remove sendLock
>
> src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java line 564:
> 
>> 562:     @SuppressWarnings("removal")
>> 563:     public void send(DatagramPacket p, byte ttl) throws IOException {
>> 564:         sendLock.lock();
> 
> sendLock can be removed too, it's only need because of this send method.

I hadn't noticed that. I have removed it now and updated the PR.

> test/jdk/java/net/MulticastSocket/SetTTLTo0.java line 26:
> 
>> 24: /* @test
>> 25:  * @bug 4148757
>> 26:  * @summary Make sure MulticastSocket.setTimeToLive() can be set to 0
> 
> I think the original okay as this test just checks that you are set the TTL to 0.

Done - reverted the `@summary` to the original one.

> test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java line 410:
> 
>> 408:         DatagramPacket p = new DatagramPacket(message, message.length);
>> 409:         p.setSocketAddress(target);
>> 410:         final int oldTTL = s.getTimeToLive();
> 
> Just replacing it with s.send(p) should be okay here, no need to set/restore TTL.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139801248
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139802233
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139801483

From vyazici at openjdk.org  Wed Jun 11 10:49:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:49:48 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v4]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <fPVhwHfAP2kebuK9yeW-EuKguCd0zt-8upCoODeD8Y0=.af8adb63-91d2-48e2-a7d5-39ca4c7f4803@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into requestPublishersDefaultFs
 - Improve comments
 - Update tests
 - Add back removed SM tests
 - Remove redundant tests
 - Remove redundant OIO usage in `RequestPublishers`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/9fce1c3b..b01448a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=02-03

  Stats: 21809 lines in 498 files changed: 17163 ins; 3210 del; 1436 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From vyazici at openjdk.org  Wed Jun 11 10:49:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 10:49:48 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <Q2V2lMSGtVqtzS8nKwrqs00mrZZFJ7aBD62cIB7rXcM=.e2b3c80b-9c0a-4ee9-9334-8535a3f3ba03@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
 <Q2V2lMSGtVqtzS8nKwrqs00mrZZFJ7aBD62cIB7rXcM=.e2b3c80b-9c0a-4ee9-9334-8535a3f3ba03@github.com>
Message-ID: <12_O9BM-lHm177xLuSoHKDw9E9KouKsfRdgA72xClGI=.3a40fbab-5cf7-4276-93b4-c5a88cb71aa8@github.com>

On Wed, 11 Jun 2025 09:50:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update tests
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 268:
> 
>> 266:             } catch (NoSuchFileException nsfe) {
>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
> 
> Nit - since the BodyPublishers.ofFile(...) specifies a `FileNotFoundException`, I think a better comment here and a few lines above might be: "// Throw FileNotFoundException to match the specification of BodyPublishers.ofFile()"

This indeed sounds better, and is also shorter. Implemented in 3fbb8cd63a8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2139814236

From vyazici at openjdk.org  Wed Jun 11 11:11:06 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 11:11:06 GMT
Subject: RFR: 8359223: HttpClient: Remove leftovers from the SecurityManager
 cleanup
Message-ID: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>

Removes following files added in [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) and are forgotten to be removed during the `SecurityManager`-removal ([JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228)):


test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java
test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java

-------------

Commit messages:
 - Remove leftover tests from the SecurityManager cleanup

Changes: https://git.openjdk.org/jdk/pull/25747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359223
  Stats: 701 lines in 2 files changed: 0 ins; 701 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25747/head:pull/25747

PR: https://git.openjdk.org/jdk/pull/25747

From dfuchs at openjdk.org  Wed Jun 11 11:16:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 11:16:30 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
 <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
Message-ID: <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>

On Wed, 11 Jun 2025 10:27:05 GMT, p-nima <duke at openjdk.org> wrote:

>> @Michael-Mc-Mahon Is my interpretation above correct?
>
> @dfuch As per my understanding, the current changes do reflect the correct behaviour, as when the request comes in it first goes through the authenticator. If the authentication fails we need to consider this failure in no of retries. (as the client should not try to get the credentials again) 
> @Michael-Mc-Mahon if you could please provide some additional context on this and if my interpretation is correct.

There is a difference between the number of attempts and the number of retries. One attempt means no retry; two attempts mean one retry. Maybe the confusion partly comes from this sentence:

> jdk.httpclient.auth.retrylimit (default: 3)
> The number of attempts the Basic authentication filter will attempt to retry a failed authentication.

1. what is a failed authentication? Is it when you receive 401/407, or is it when you receive 401/407 *after* having provided credential?
2. There are two many "attempts" in the sentence above. One of them should be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2139871586

From jpai at openjdk.org  Wed Jun 11 11:50:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 11:50:26 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
Message-ID: <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>

On Mon, 9 Jun 2025 12:58:24 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Done
>
> FWIW:
> Stating a typical value of 60 seconds timeout can lead to a misconception or set an expectation ... From from TCP standards and depending on which literature you read (OS docs or unix networking socket programming) then 75 secs should be a more typical default 
> 
> I think the 60 seconds comes from a perceived setting on linux. For example if a linux config of
> net.ipv4.tcp_syn_retries = 6 is set and the RTO == 1 sec, with a backoff policy of doubling the timeout each retry, then the connect timeout would expect to be 63 secs
> 
> It would be better to say that, the value is OS dependent, influenced by OS network setting relating to syn receive timeouts and the number of syn retries, and governed by the TCP retransmission timer implementation, rather than stating a particular value.

Hello Mark,
Alan's thought was that it might be OK to have that sentence about the typical 60 second timeout. The primary guidance to developers here is that "The {@code timeout} specified to this method is typically a timeout value that is shorter than the operating system timeout." so that they set a lower value when appropriate.

Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2139931318

From dfuchs at openjdk.org  Wed Jun 11 11:54:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 11:54:33 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v2]
In-Reply-To: <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>
Message-ID: <53H1sX7ZGsgiaIt4F_nnUelj-59ZxxIn8XgfuBb8vGA=.8ecc01f6-7cb8-46c1-a001-842e9f9e94c5@github.com>

On Wed, 11 Jun 2025 10:42:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - no need to setTimeToLive() in AdaptorMulticasting test
>  - undo change to "@summary" of a test
>  - remove sendLock

Generally look good. One question on one of the tests.

test/jdk/java/net/DatagramSocket/SendCheck.java line 133:

> 131:                 Sender.of(DatagramChannel.open().socket()),
> 132:                 Sender.of((MulticastSocket)
> 133:                         DatagramChannel.open().socket(), (byte) 0)

Should we instead just remove the ttl parameter and test with plain MulticastSocket::send?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25744#pullrequestreview-2916814072
PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139934428

From jpai at openjdk.org  Wed Jun 11 11:56:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 11:56:36 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v4]
In-Reply-To: <fPVhwHfAP2kebuK9yeW-EuKguCd0zt-8upCoODeD8Y0=.af8adb63-91d2-48e2-a7d5-39ca4c7f4803@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <fPVhwHfAP2kebuK9yeW-EuKguCd0zt-8upCoODeD8Y0=.af8adb63-91d2-48e2-a7d5-39ca4c7f4803@github.com>
Message-ID: <PW_FUg8Vyf__488mKx_ef4wuPqb0hlpl64NqD4tqSIg=.bb9db1fc-fdd4-41f9-92f4-6f7472c34b81@github.com>

On Wed, 11 Jun 2025 10:49:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into requestPublishersDefaultFs
>  - Improve comments
>  - Update tests
>  - Add back removed SM tests
>  - Remove redundant tests
>  - Remove redundant OIO usage in `RequestPublishers`

Thank you for the updates Volkan. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2916818453

From dfuchs at openjdk.org  Wed Jun 11 11:56:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 11:56:37 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v4]
In-Reply-To: <fPVhwHfAP2kebuK9yeW-EuKguCd0zt-8upCoODeD8Y0=.af8adb63-91d2-48e2-a7d5-39ca4c7f4803@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <fPVhwHfAP2kebuK9yeW-EuKguCd0zt-8upCoODeD8Y0=.af8adb63-91d2-48e2-a7d5-39ca4c7f4803@github.com>
Message-ID: <RL-ZTtXn0mZIIEBydRxyAkeZBCw8bsgQHjY5YQ2IW-I=.5246d9a1-995c-438a-8f83-cf9db4eb948e@github.com>

On Wed, 11 Jun 2025 10:49:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into requestPublishersDefaultFs
>  - Improve comments
>  - Update tests
>  - Add back removed SM tests
>  - Remove redundant tests
>  - Remove redundant OIO usage in `RequestPublishers`

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2916825131

From jpai at openjdk.org  Wed Jun 11 12:07:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 12:07:51 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's review - continue to test MulticastSocket in SendCheck

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25744/files
  - new: https://git.openjdk.org/jdk/pull/25744/files/c0017d07..7a33f351

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25744&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25744&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25744/head:pull/25744

PR: https://git.openjdk.org/jdk/pull/25744

From jpai at openjdk.org  Wed Jun 11 12:07:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 12:07:51 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <53H1sX7ZGsgiaIt4F_nnUelj-59ZxxIn8XgfuBb8vGA=.8ecc01f6-7cb8-46c1-a001-842e9f9e94c5@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <BgNh7VcZDDn_hixD1p8-ABb7ISHL0jbo35AzotAh7aU=.bdcc6f92-5fec-4a03-a0be-cb4feb187cfc@github.com>
 <53H1sX7ZGsgiaIt4F_nnUelj-59ZxxIn8XgfuBb8vGA=.8ecc01f6-7cb8-46c1-a001-842e9f9e94c5@github.com>
Message-ID: <ZPFRxkh98gS2h8zwULd_fjKNHzMb_RjAXbwq-sGzuCg=.23160510-30df-45a7-89d8-33af7286d38a@github.com>

On Wed, 11 Jun 2025 11:49:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Daniel's review - continue to test MulticastSocket in SendCheck
>
> test/jdk/java/net/DatagramSocket/SendCheck.java line 133:
> 
>> 131: 
>> 132:         List<Object[]> testcases = new ArrayList<>();
>> 133:         for (var packet : Packets) {
> 
> Should we instead just remove the ttl parameter and test with plain MulticastSocket::send?

That's a good catch. The test description of this test states that it's meant to test DatagramSocket, the adaptor, the DatagramChannel and the MulticastSocket. The change I did would have stopped testing MulticastSocket altogether. I have now updated the PR to only remove the use of a setTTL() from this test and it now continues to test the send() methods of these classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25744#discussion_r2139961400

From msheppar at openjdk.org  Wed Jun 11 12:17:30 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 11 Jun 2025 12:17:30 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
Message-ID: <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>

On Wed, 11 Jun 2025 11:47:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> FWIW:
>> Stating a typical value of 60 seconds timeout can lead to a misconception or set an expectation ... From from TCP standards and depending on which literature you read (OS docs or unix networking socket programming) then 75 secs should be a more typical default 
>> 
>> I think the 60 seconds comes from a perceived setting on linux. For example if a linux config of
>> net.ipv4.tcp_syn_retries = 6 is set and the RTO == 1 sec, with a backoff policy of doubling the timeout each retry, then the connect timeout would expect to be 63 secs
>> 
>> It would be better to say that, the value is OS dependent, influenced by OS network setting relating to syn receive timeouts and the number of syn retries, and governed by the TCP retransmission timer implementation, rather than stating a particular value.
>
> Hello Mark,
> Alan's thought was that it might be OK to have that sentence about the typical 60 second timeout. The primary guidance to developers here is that "The {@code timeout} specified to this method is typically a timeout value that is shorter than the operating system timeout." so that they set a lower value when appropriate.
> 
> Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?

I think it is an unnecessary quantification, is somewhat inaccurate, and set an expectation of a developer that this is gospel or axiomatic. Indicating that  it is OS dependent should be sufficient.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2139979786

From vyazici at openjdk.org  Wed Jun 11 12:32:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 11 Jun 2025 12:32:13 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v5]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <IUkHXI5oK7BpXxJXkvBySZC87CR51rjCe3knHR0Pu24=.39bb4f1c-e8b6-4120-b8f0-f0c4205f6887@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Fix `FilePublisherTest`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/b01448a0..de20dae0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=03-04

  Stats: 12 lines in 1 file changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From alanb at openjdk.org  Wed Jun 11 12:41:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 12:41:31 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
Message-ID: <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>

On Wed, 11 Jun 2025 12:14:59 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Hello Mark,
>> Alan's thought was that it might be OK to have that sentence about the typical 60 second timeout. The primary guidance to developers here is that "The {@code timeout} specified to this method is typically a timeout value that is shorter than the operating system timeout." so that they set a lower value when appropriate.
>> 
>> Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?
>
> I think it is an unnecessary quantification, is somewhat inaccurate, and set an expectation of a developer that this is gospel or axiomatic. Indicating that  it is OS dependent should be sufficient.

> Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?

I think it's helpful here to give some indication in this API note as what the timeout might be. It doesn't really matter if it says 60s or 75s, the point is that establishing a TCP connection is subject to a timeout imposed by the operating system. It helps for cases where someone calls connect with a timeout of say 300_000 (5 minutes) and is surprised to get ConnectException "Operation timed out" after a minute or so. This is exactly what prompted JDK-7116990, someone called connect with a timeout that is larger than the OS configured timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2140026351

From dfuchs at openjdk.org  Wed Jun 11 13:18:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 13:18:30 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <Uc5Y1fDXYcMc4XREU_sxh3PQaFnC6AfIoQlVBOwHSPY=.bb3284ba-16da-412e-9a32-32a59d263702@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25744#pullrequestreview-2917111623

From michaelm at openjdk.org  Wed Jun 11 13:31:50 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 11 Jun 2025 13:31:50 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v4]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <A32SGkGUfcriB-IeUhX4cCVqnjAMnlvZ0CqvADOIBOA=.269a5069-8e01-409f-a081-3e457a53890d@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  test and impl update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/ef975706..e44ccf94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=02-03

  Stats: 252 lines in 4 files changed: 165 ins; 77 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From dfuchs at openjdk.org  Wed Jun 11 13:47:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 13:47:05 GMT
Subject: [jdk25] RFR: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
Message-ID: <9wRPOnAiCRR-mvzRxbFEeSYQruqQUDIIINcRkuyNTIQ=.44c51527-626d-4f58-a23f-a2a8d1d044a2@github.com>

I would like to backport this trivial test-only change to JDK 25.
This one-liner ensures that the test will not depend on the host proxy configuration when running in the CI.
This is a clean backport.

-------------

Commit messages:
 - Backport a377773fa76b46ac98533c61bc1410485390115e

Changes: https://git.openjdk.org/jdk/pull/25755/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25755&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358617
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25755.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25755/head:pull/25755

PR: https://git.openjdk.org/jdk/pull/25755

From jpai at openjdk.org  Wed Jun 11 13:57:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 13:57:28 GMT
Subject: [jdk25] RFR: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
In-Reply-To: <9wRPOnAiCRR-mvzRxbFEeSYQruqQUDIIINcRkuyNTIQ=.44c51527-626d-4f58-a23f-a2a8d1d044a2@github.com>
References: <9wRPOnAiCRR-mvzRxbFEeSYQruqQUDIIINcRkuyNTIQ=.44c51527-626d-4f58-a23f-a2a8d1d044a2@github.com>
Message-ID: <edZqGumJihKmcw_HC1kuZiWsyY6rNyfjxDVtf4nm4Cw=.bf1799f1-d857-42fa-a454-1706c0f20e46@github.com>

On Wed, 11 Jun 2025 13:42:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I would like to backport this trivial test-only change to JDK 25.
> This one-liner ensures that the test will not depend on the host proxy configuration when running in the CI.
> This is a clean backport.

This looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25755#pullrequestreview-2917328443

From dfuchs at openjdk.org  Wed Jun 11 16:25:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 11 Jun 2025 16:25:32 GMT
Subject: [jdk25] Integrated: 8358617:
 java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with
 403 due to system proxies
In-Reply-To: <9wRPOnAiCRR-mvzRxbFEeSYQruqQUDIIINcRkuyNTIQ=.44c51527-626d-4f58-a23f-a2a8d1d044a2@github.com>
References: <9wRPOnAiCRR-mvzRxbFEeSYQruqQUDIIINcRkuyNTIQ=.44c51527-626d-4f58-a23f-a2a8d1d044a2@github.com>
Message-ID: <Luj6ZW9QSDtj0u_IqCzrgR2qrcZNrL-K9M6nF700XqE=.033df6a7-5080-4e8d-a214-b946ce54aac7@github.com>

On Wed, 11 Jun 2025 13:42:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I would like to backport this trivial test-only change to JDK 25.
> This one-liner ensures that the test will not depend on the host proxy configuration when running in the CI.
> This is a clean backport.

This pull request has now been integrated.

Changeset: aa4f79ea
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa4f79eaec618093b8e2ae9447d25b0633d29065
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358617: java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java fails with 403 due to system proxies

Reviewed-by: jpai
Backport-of: a377773fa76b46ac98533c61bc1410485390115e

-------------

PR: https://git.openjdk.org/jdk/pull/25755

From djelinski at openjdk.org  Wed Jun 11 16:33:38 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Jun 2025 16:33:38 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
Message-ID: <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>

On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
> 
> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

src/java.base/share/native/libnet/net_util.c line 77:

> 75:     CHECK_NULL_RETURN(s, JNI_VERSION_1_2);
> 76:     preferIPv4Stack = (*env)->CallStaticBooleanMethod(env, iCls, mid, s);
> 77:     JNU_CHECK_EXCEPTION_RETURN(env, JNI_VERSION_1_2);

The exception check is technically not necessary because no other JNI methods are called before the function exits, but it wasn't always the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2140117524

From djelinski at openjdk.org  Wed Jun 11 16:33:38 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Jun 2025 16:33:38 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
Message-ID: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>

Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.

I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

-------------

Commit messages:
 - Fix JNICheck issue

Changes: https://git.openjdk.org/jdk/pull/25754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8131136
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25754/head:pull/25754

PR: https://git.openjdk.org/jdk/pull/25754

From jpai at openjdk.org  Wed Jun 11 17:32:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Jun 2025 17:32:28 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
Message-ID: <rg-LLrsB8WaBWJUCepNPsolk7mFFpOclG29o_9oY-e4=.2fe483fb-f480-4867-a345-53413201c5c4@github.com>

On Mon, 9 Jun 2025 11:43:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion

The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8359249

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25690#issuecomment-2963633115

From alanb at openjdk.org  Wed Jun 11 18:34:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Jun 2025 18:34:32 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <rg-LLrsB8WaBWJUCepNPsolk7mFFpOclG29o_9oY-e4=.2fe483fb-f480-4867-a345-53413201c5c4@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
 <rg-LLrsB8WaBWJUCepNPsolk7mFFpOclG29o_9oY-e4=.2fe483fb-f480-4867-a345-53413201c5c4@github.com>
Message-ID: <-JZRG2bNPZc17ewJehHJMuDnWxgVC1sbsxVz8AafNG0=.31d12218-6d28-404e-bcd7-ab995bdc3f19@github.com>

On Wed, 11 Jun 2025 17:29:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8359249

It's okay to have a CSR but no usually needed for API notes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25690#issuecomment-2963794320

From serb at openjdk.org  Wed Jun 11 19:03:30 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:03:30 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>
Message-ID: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com>

On Wed, 11 Jun 2025 13:19:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
>> 
>> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.
>
> src/java.base/share/native/libnet/net_util.c line 77:
> 
>> 75:     CHECK_NULL_RETURN(s, JNI_VERSION_1_2);
>> 76:     preferIPv4Stack = (*env)->CallStaticBooleanMethod(env, iCls, mid, s);
>> 77:     JNU_CHECK_EXCEPTION_RETURN(env, JNI_VERSION_1_2);
> 
> The exception check is technically not necessary because no other JNI methods are called before the function exits, but it wasn't always the case.

If this check is not needed, then why are we adding it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2140875632

From msheppar at openjdk.org  Wed Jun 11 21:22:28 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 11 Jun 2025 21:22:28 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
Message-ID: <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>

On Wed, 11 Jun 2025 12:38:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think it is an unnecessary quantification, is somewhat inaccurate, and set an expectation of a developer that this is gospel or axiomatic. Indicating that  it is OS dependent should be sufficient.
>
>> Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?
> 
> I think it's helpful here to give some indication in this API note as what the timeout might be. It doesn't really matter if it says 60s or 75s, the point is that establishing a TCP connection is subject to a timeout imposed by the operating system. It helps for cases where someone calls connect with a timeout of say 300_000 (5 minutes) and is surprised to get ConnectException "Operation timed out" after a minute or so. This is exactly what prompted JDK-7116990, someone called connect with a timeout that is larger than the OS configured timeout.

Looking at this on the 3 main OS platforms (Windows, OL and macOS) and running a simple test to trigger a connect timeout then finding are

macOS the connect timeout is 75 seconds as this is derived from 4.3 BSD

If OL linux has a syn retries set to 6 and an RTO == 1 sec then it?s connect timeout is 130 seconds approx 
That?s initial syn timeout of 1 seconds and then 6 retries totalling 127 seconds

Windows by default connect is 21 seconds
RTT == 3 seconds and two connect retries
Initial syn timeout 3 seconds + 2 retries at 6 and 12 seconds == 21 seconds

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2141133716

From alanb at openjdk.org  Thu Jun 12 06:46:31 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Jun 2025 06:46:31 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <g3bH3ZlX4XGGP62pDKP5Nch8H6IA6xiYchVJ3Z97_WU=.dbb32788-8978-4f58-b736-f0c669906c55@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25744#pullrequestreview-2919730619

From vyazici at openjdk.org  Thu Jun 12 08:17:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 08:17:28 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
Message-ID: <cyE5mlFNWujCb1RbL7yNW5o7yqR5gcU80NM-Us2WfGI=.26277dfe-2dba-463d-8d28-d3247bf9af98@github.com>

On Fri, 6 Jun 2025 08:25:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back removed SM tests
>
> The new version LGTM. I wonder if we should add `@bug 8358688` to the various FilePublisher test - or just consider the fix as noreg-cleanup. On the one hand those tests might have failed if you hadn't catched and transformed NSFE. On the other hand they should pass whether this fix is present or not...

@dfuch, @jaikiran, I needed to push a test fix (de20dae) for `tier1,2` to pass ? results are attached to the JBS issue. Would one of you mind approving the most recent changes, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2965595660

From jpai at openjdk.org  Thu Jun 12 08:36:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 08:36:31 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v5]
In-Reply-To: <IUkHXI5oK7BpXxJXkvBySZC87CR51rjCe3knHR0Pu24=.39bb4f1c-e8b6-4120-b8f0-f0c4205f6887@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <IUkHXI5oK7BpXxJXkvBySZC87CR51rjCe3knHR0Pu24=.39bb4f1c-e8b6-4120-b8f0-f0c4205f6887@github.com>
Message-ID: <2omAEI83W8U14RyTcsNhrGyiS330IN3JRIEwD7rYlrQ=.405c000b-522e-4074-910a-b5aa3b1b07c2@github.com>

On Wed, 11 Jun 2025 12:32:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix `FilePublisherTest`

test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java line 168:

> 166:         try (FileSystem fs = newZipFs(zipPath)) {
> 167:             Path fileInZip = zipFsFile(fs);
> 168:             Files.deleteIfExists(fileInZip);

Now that I look at this, perhaps we should just change these 2 lines:

Path fileInZip = zipFsFile(fs);
Files.deleteIfExists(fileInZip);

 to:


Path fileInZip = fs.getPath("non-existent.txt");

The call to `zipFsFile(...)` creates a ZIP entry within the ZIP and we then delete it immediately here with the deleteIfExists(...) call. At least for this new test, this creation followed by the deletion isn't necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2142061997

From vyazici at openjdk.org  Thu Jun 12 09:21:08 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 09:21:08 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v6]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Simplify `FilePublisherTest`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/de20dae0..1eadf2dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=04-05

  Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From vyazici at openjdk.org  Thu Jun 12 09:24:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 09:24:33 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v5]
In-Reply-To: <2omAEI83W8U14RyTcsNhrGyiS330IN3JRIEwD7rYlrQ=.405c000b-522e-4074-910a-b5aa3b1b07c2@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <IUkHXI5oK7BpXxJXkvBySZC87CR51rjCe3knHR0Pu24=.39bb4f1c-e8b6-4120-b8f0-f0c4205f6887@github.com>
 <2omAEI83W8U14RyTcsNhrGyiS330IN3JRIEwD7rYlrQ=.405c000b-522e-4074-910a-b5aa3b1b07c2@github.com>
Message-ID: <LPy5WDlxVTGHpXDchotczWke6V0NoWqUg9tPfODx6p4=.e8631434-d555-44a8-bce7-c4ab7fa1c20d@github.com>

On Thu, 12 Jun 2025 08:34:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix `FilePublisherTest`
>
> test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java line 168:
> 
>> 166:         try (FileSystem fs = newZipFs(zipPath)) {
>> 167:             Path fileInZip = zipFsFile(fs);
>> 168:             Files.deleteIfExists(fileInZip);
> 
> Now that I look at this, perhaps we should just change these 2 lines:
> 
> Path fileInZip = zipFsFile(fs);
> Files.deleteIfExists(fileInZip);
> 
>  to:
> 
> 
> Path fileInZip = fs.getPath("non-existent.txt");
> 
> The call to `zipFsFile(...)` creates a ZIP entry within the ZIP and we then delete it immediately here with the deleteIfExists(...) call. At least for this new test, this creation followed by the deletion isn't necessary.

Simplified as suggested in 1eadf2dc4b8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2142155769

From jpai at openjdk.org  Thu Jun 12 09:36:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 09:36:34 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v6]
In-Reply-To: <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
Message-ID: <Na0Q2WJ3wNomMB-n_0ZhTmZQB26T-XNqKsry1WisoXI=.22f9a300-3563-42bb-b9c8-b60cfae766c7@github.com>

On Thu, 12 Jun 2025 09:21:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify `FilePublisherTest`

This looks good to me. I don't expect this latest change to cause a failure in CI, but it would be good to have this test run on all platforms before integrating (doesn't have to be the entire tier).

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2920296403

From vyazici at openjdk.org  Thu Jun 12 10:07:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 10:07:29 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v6]
In-Reply-To: <Na0Q2WJ3wNomMB-n_0ZhTmZQB26T-XNqKsry1WisoXI=.22f9a300-3563-42bb-b9c8-b60cfae766c7@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
 <Na0Q2WJ3wNomMB-n_0ZhTmZQB26T-XNqKsry1WisoXI=.22f9a300-3563-42bb-b9c8-b60cfae766c7@github.com>
Message-ID: <J1OrAsNJIO1PJWxukGb9e5-EOb2SLWNsEUW30LrMmnI=.1bcb72ba-876f-466f-a5b3-29d98f0f472c@github.com>

On Thu, 12 Jun 2025 09:33:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This looks good to me. I don't expect this latest change to cause a failure in CI, but it would be good to have this test run on all platforms before integrating (doesn't have to be the entire tier).

@jaikiran, I've already run the updated `FilePublisherTest` (and only that test) against the last build before pushing the commit ? ? the details are attached to the JBS issue. Would that suffice?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2965985477

From msheppar at openjdk.org  Thu Jun 12 10:21:28 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 12 Jun 2025 10:21:28 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
Message-ID: <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>

On Wed, 11 Jun 2025 21:16:40 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>>> Alan @AlanBateman, do you suggest we continue with this text or would any update be necessary?
>> 
>> I think it's helpful here to give some indication in this API note as what the timeout might be. It doesn't really matter if it says 60s or 75s, the point is that establishing a TCP connection is subject to a timeout imposed by the operating system. It helps for cases where someone calls connect with a timeout of say 300_000 (5 minutes) and is surprised to get ConnectException "Operation timed out" after a minute or so. This is exactly what prompted JDK-7116990, someone called connect with a timeout that is larger than the OS configured timeout.
>
> Looking at this on the 3 main OS platforms (Windows, OL and macOS) and running a simple test to trigger a connect timeout then finding are
> 
> macOS the connect timeout is 75 seconds as this is derived from 4.3 BSD
> 
> If OL linux has a syn retries set to 6 and an RTO == 1 sec then it?s connect timeout is 130 seconds approx 
> That?s initial syn timeout of 1 seconds and then 6 retries totalling 127 seconds
> 
> Windows by default connect timeout is 21 seconds
> RTT == 3 seconds and two connect retries
> Initial syn timeout 3 seconds + 2 retries at 6 and 12 seconds == 21 seconds

FWIW an possible alternative wording

Establishing a TCP/IP connection is subject to a connect timeout, determined by configuration settings
of the operating system, for example the number of connect retries together with an implementation?s back off strategy. Thus, TCP/IP Connect timeout values can vary across operating system, for example 75 seconds on macOS, with a  default value of 21 seconds on Windows system. As such, the operating system TCP/IP Connect timeout may expire before that specified to the connect method. If the operating system Connect timeout expires 
before the {@code timeout} specified to this method then an {@code IOException} is thrown. The {@code timeout} 
specified to this method is typically a timeout value that is shorter than the operating system timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2142282586

From jpai at openjdk.org  Thu Jun 12 10:49:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Jun 2025 10:49:29 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v6]
In-Reply-To: <J1OrAsNJIO1PJWxukGb9e5-EOb2SLWNsEUW30LrMmnI=.1bcb72ba-876f-466f-a5b3-29d98f0f472c@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
 <Na0Q2WJ3wNomMB-n_0ZhTmZQB26T-XNqKsry1WisoXI=.22f9a300-3563-42bb-b9c8-b60cfae766c7@github.com>
 <J1OrAsNJIO1PJWxukGb9e5-EOb2SLWNsEUW30LrMmnI=.1bcb72ba-876f-466f-a5b3-29d98f0f472c@github.com>
Message-ID: <NZ5rkl-0EpHva20qsgjtkTbR4MzHH4KPoC9ItZxkYZM=.22aa4f22-9cf0-45c6-8f88-7eb82d678154@github.com>

On Thu, 12 Jun 2025 10:05:14 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Would that suffice?

Thank you, yes that's good enough. It's good to go ahead with the integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2966111409

From michaelm at openjdk.org  Thu Jun 12 11:49:30 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 12 Jun 2025 11:49:30 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
 <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
 <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>
Message-ID: <95UooRAtPUXrkajl68GbTmduwcpjUwGROnw-4tJGj34=.11365ec5-fbdf-4cbd-80fb-3b75d3d7f0fd@github.com>

On Wed, 11 Jun 2025 11:13:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch As per my understanding, the current changes do reflect the correct behaviour, as when the request comes in it first goes through the authenticator. If the authentication fails we need to consider this failure in no of retries. (as the client should not try to get the credentials again) 
>> @Michael-Mc-Mahon if you could please provide some additional context on this and if my interpretation is correct.
>
> There is a difference between the number of attempts and the number of retries. One attempt means no retry; two attempts mean one retry. Maybe the confusion partly comes from this sentence:
> 
>> jdk.httpclient.auth.retrylimit (default: 3)
>> The number of attempts the Basic authentication filter will attempt to retry a failed authentication.
> 
> 1. what is a failed authentication? Is it when you receive 401/407, or is it when you receive 401/407 *after* having provided credential?
> 2. There are two many "attempts" in the sentence above. One of them should be removed.

> Ok - so now we're getting somewhere. This lets me think that the change in the AuthenticationFilter is not right. The specification says:
> 
> > jdk.httpclient.auth.retrylimit (default: 3)
> > The number of attempts the Basic authentication filter will attempt to retry a failed authentication.
> 
> When I read this, I expect that if the limit is 0, no retries, then the Authenticator will be called once, and if the authentication fails with these credentials, then the request will fail. If the limit is 1, then we will retry once, which means the Authenticator should be called twice, and so on.
> 
> So maybe we should always assert that totalRequestCount == `Math.max(RETRY_LIMIT, 0) + 1`?

Yeah, I think I agree with 1st para above. But, there is potential for confusion. The number of request retries is not the same as the number of authentication retries. The first authentication request happens during the first request retry (the 2nd request). The first authentication retry happens during the second request retry (the 3rd request).

The property name seems to be clearly referring to the number of auth retries (ie the number of times the authenticator is retried) and the number of calls to the authenticator will be that +1.

So, maybe, it's not a bug?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2142511014

From djelinski at openjdk.org  Thu Jun 12 12:46:29 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 12 Jun 2025 12:46:29 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>
 <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com>
Message-ID: <pt7sk9C5zmTJ-OtTTNgW2sVMu_yhEZpjjF_nUM1dNG0=.ae0a2ae9-5ef7-4875-b3de-df7ea87b8c04@github.com>

On Wed, 11 Jun 2025 19:00:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.base/share/native/libnet/net_util.c line 77:
>> 
>>> 75:     CHECK_NULL_RETURN(s, JNI_VERSION_1_2);
>>> 76:     preferIPv4Stack = (*env)->CallStaticBooleanMethod(env, iCls, mid, s);
>>> 77:     JNU_CHECK_EXCEPTION_RETURN(env, JNI_VERSION_1_2);
>> 
>> The exception check is technically not necessary because no other JNI methods are called before the function exits, but it wasn't always the case.
>
> If this check is not needed, then why are we adding it?

just so we don't forget to add it when we modify the enclosing function. The call to `CallStaticBooleanMethod` is located pretty far from the end of the function, and can be easy to miss.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2142645794

From michaelm at openjdk.org  Thu Jun 12 12:48:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 12 Jun 2025 12:48:31 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v5]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <URIa21DEmt-CjHGKszp_eJoIc9sU-9SiK77ijSAEY78=.c2004325-9f99-4a73-9728-9c0f4bb68787@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  test update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/e44ccf94..9a495d7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=03-04

  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From michaelm at openjdk.org  Thu Jun 12 12:48:33 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 12 Jun 2025 12:48:33 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v5]
In-Reply-To: <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>
Message-ID: <7cff17FHQy-R3WCTMNJmtcqJzCBOOPpdAkPMSEoABus=.47d3ebd5-ba0b-4262-b137-e1290f26fd83@github.com>

On Thu, 5 Jun 2025 05:32:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test update
>
> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 63:
> 
>> 61:     }
>> 62: 
>> 63:     static Test[] tests = new Test[] {
> 
> *Tip:* JUnit `@ParameterizedTest @CsvSource` can save us some boilerplate here.

I've updated the implementation to allow for testing with fixed cookie creation times and expiry check times. And then added some tests of this. If we're okay with it, I'd like to work on the CSR at this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2142646125

From dfuchs at openjdk.org  Thu Jun 12 12:51:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 12:51:31 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v4]
In-Reply-To: <A32SGkGUfcriB-IeUhX4cCVqnjAMnlvZ0CqvADOIBOA=.269a5069-8e01-409f-a081-3e457a53890d@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <A32SGkGUfcriB-IeUhX4cCVqnjAMnlvZ0CqvADOIBOA=.269a5069-8e01-409f-a081-3e457a53890d@github.com>
Message-ID: <4W66C5myvvw5Gsfu4qmRTHYI3GlQYsKf7Cj57P9jTRY=.92167db1-8ea1-452f-953d-aa17c461bcb0@github.com>

On Wed, 11 Jun 2025 13:31:50 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test and impl update

@Michael-Mc-Mahon 
I still want to have a look at the (new) implementation changes but I agree with the principle, so it should not stop you starting the CSR process.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25636#issuecomment-2966583246

From michaelm at openjdk.org  Thu Jun 12 13:00:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 12 Jun 2025 13:00:31 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v4]
In-Reply-To: <4W66C5myvvw5Gsfu4qmRTHYI3GlQYsKf7Cj57P9jTRY=.92167db1-8ea1-452f-953d-aa17c461bcb0@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <A32SGkGUfcriB-IeUhX4cCVqnjAMnlvZ0CqvADOIBOA=.269a5069-8e01-409f-a081-3e457a53890d@github.com>
 <4W66C5myvvw5Gsfu4qmRTHYI3GlQYsKf7Cj57P9jTRY=.92167db1-8ea1-452f-953d-aa17c461bcb0@github.com>
Message-ID: <Von3hErj0jP88YxAF0k4Ta6SMoRoOhnteizoROLhXp4=.fe5c2f81-a7e3-4c89-968a-18a42542255a@github.com>

On Thu, 12 Jun 2025 12:48:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> @Michael-Mc-Mahon I still want to have a look at the (new) implementation changes but I agree with the principle, so it should not stop you starting the CSR process.

No rush. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25636#issuecomment-2966614230

From dclarke at openjdk.org  Thu Jun 12 14:23:31 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Thu, 12 Jun 2025 14:23:31 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <95UooRAtPUXrkajl68GbTmduwcpjUwGROnw-4tJGj34=.11365ec5-fbdf-4cbd-80fb-3b75d3d7f0fd@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
 <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
 <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>
 <95UooRAtPUXrkajl68GbTmduwcpjUwGROnw-4tJGj34=.11365ec5-fbdf-4cbd-80fb-3b75d3d7f0fd@github.com>
Message-ID: <Axu1AdbwV5s6WTxqjOXQtoIS5FSwwc7WJyHLdPC3JAM=.22ec2afb-18ad-4018-9f21-f7b2dbbe5f35@github.com>

On Thu, 12 Jun 2025 11:45:46 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> There is a difference between the number of attempts and the number of retries. One attempt means no retry; two attempts mean one retry. Maybe the confusion partly comes from this sentence:
>> 
>>> jdk.httpclient.auth.retrylimit (default: 3)
>>> The number of attempts the Basic authentication filter will attempt to retry a failed authentication.
>> 
>> 1. what is a failed authentication? Is it when you receive 401/407, or is it when you receive 401/407 *after* having provided credential?
>> 2. There are two many "attempts" in the sentence above. One of them should be removed.
>
>> Ok - so now we're getting somewhere. This lets me think that the change in the AuthenticationFilter is not right. The specification says:
>> 
>> > jdk.httpclient.auth.retrylimit (default: 3)
>> > The number of attempts the Basic authentication filter will attempt to retry a failed authentication.
>> 
>> When I read this, I expect that if the limit is 0, no retries, then the Authenticator will be called once, and if the authentication fails with these credentials, then the request will fail. If the limit is 1, then we will retry once, which means the Authenticator should be called twice, and so on.
>> 
>> So maybe we should always assert that totalRequestCount == `Math.max(RETRY_LIMIT, 0) + 1`?
> 
> Yeah, I think I agree with 1st para above. But, there is potential for confusion. The number of request retries is not the same as the number of authentication retries. The first authentication request happens during the first request retry (the 2nd request). The first authentication retry happens during the second request retry (the 3rd request).
> 
> The property name seems to be clearly referring to the number of auth retries (ie the number of times the authenticator is retried) and the number of calls to the authenticator will be that +1.
> 
> So, maybe, it's not a bug?

After this discussion I think this isn't a bug, though the wording on the property may need clarification

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2142903528

From dfuchs at openjdk.org  Thu Jun 12 14:45:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 14:45:33 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v6]
In-Reply-To: <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
Message-ID: <DuHG7-APObF0a4HaDu2O_vHq4LiqFJ-uoM2r69bYads=.58573d25-3881-4abf-96d2-a4daaa70ab87@github.com>

On Thu, 12 Jun 2025 09:21:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify `FilePublisherTest`

Marked as reviewed by dfuchs (Reviewer).

The person who wrote the test was probably concerned that `fs.getPath("non-existent.txt");` could throw if passed a non-existing path. Looking at the API documentation that doesn't seem a valid concern. The only exception documented is `InvalidPathException` - so we should be good

-------------

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2921525123
PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2967127552

From dfuchs at openjdk.org  Thu Jun 12 14:51:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 14:51:29 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <Axu1AdbwV5s6WTxqjOXQtoIS5FSwwc7WJyHLdPC3JAM=.22ec2afb-18ad-4018-9f21-f7b2dbbe5f35@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
 <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
 <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>
 <95UooRAtPUXrkajl68GbTmduwcpjUwGROnw-4tJGj34=.11365ec5-fbdf-4cbd-80fb-3b75d3d7f0fd@github.com>
 <Axu1AdbwV5s6WTxqjOXQtoIS5FSwwc7WJyHLdPC3JAM=.22ec2afb-18ad-4018-9f21-f7b2dbbe5f35@github.com>
Message-ID: <VN8V3uoVPeZSl0dkIQSbFJPjxA_j2zu97GsiS4ydce0=.64fc9241-ab07-433c-b069-cbc73b659e6a@github.com>

On Thu, 12 Jun 2025 14:20:24 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>>> Ok - so now we're getting somewhere. This lets me think that the change in the AuthenticationFilter is not right. The specification says:
>>> 
>>> > jdk.httpclient.auth.retrylimit (default: 3)
>>> > The number of attempts the Basic authentication filter will attempt to retry a failed authentication.
>>> 
>>> When I read this, I expect that if the limit is 0, no retries, then the Authenticator will be called once, and if the authentication fails with these credentials, then the request will fail. If the limit is 1, then we will retry once, which means the Authenticator should be called twice, and so on.
>>> 
>>> So maybe we should always assert that totalRequestCount == `Math.max(RETRY_LIMIT, 0) + 1`?
>> 
>> Yeah, I think I agree with 1st para above. But, there is potential for confusion. The number of request retries is not the same as the number of authentication retries. The first authentication request happens during the first request retry (the 2nd request). The first authentication retry happens during the second request retry (the 3rd request).
>> 
>> The property name seems to be clearly referring to the number of auth retries (ie the number of times the authenticator is retried) and the number of calls to the authenticator will be that +1.
>> 
>> So, maybe, it's not a bug?
>
> After this discussion I think this isn't a bug, though the wording on the property may need clarification

Agreed. And it's very good to have a test now to verify the expected behavior. So I would change the test to test the behaviour we want. Then double check that it fails with the current proposed changes, and pass if we revert those changes. Then I would clarify the documentation of the system property, in order to remove the confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2142975052

From duke at openjdk.org  Thu Jun 12 14:59:30 2025
From: duke at openjdk.org (p-nima)
Date: Thu, 12 Jun 2025 14:59:30 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <VN8V3uoVPeZSl0dkIQSbFJPjxA_j2zu97GsiS4ydce0=.64fc9241-ab07-433c-b069-cbc73b659e6a@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
 <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
 <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>
 <95UooRAtPUXrkajl68GbTmduwcpjUwGROnw-4tJGj34=.11365ec5-fbdf-4cbd-80fb-3b75d3d7f0fd@github.com>
 <Axu1AdbwV5s6WTxqjOXQtoIS5FSwwc7WJyHLdPC3JAM=.22ec2afb-18ad-4018-9f21-f7b2dbbe5f35@github.com>
 <VN8V3uoVPeZSl0dkIQSbFJPjxA_j2zu97GsiS4ydce0=.64fc9241-ab07-433c-b069-cbc73b659e6a@github.com>
Message-ID: <yYF_9QUw6w5KfqiKq1rbHl1w7vkE-E4viIjK21jUQEI=.b1b8d66f-d892-4014-a5da-bbeadf5de56e@github.com>

On Thu, 12 Jun 2025 14:48:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> After this discussion I think this isn't a bug, though the wording on the property may need clarification
>
> Agreed. And it's very good to have a test now to verify the expected behavior. So I would change the test to test the behaviour we want. Then double check that it fails with the current proposed changes, and pass if we revert those changes. Then I would clarify the documentation of the system property, in order to remove the confusion.

Thanks all for your inputs, I will revert the changes to the update the test accordingly and update the documentation to clarify the confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2142992359

From duke at openjdk.org  Thu Jun 12 15:33:50 2025
From: duke at openjdk.org (p-nima)
Date: Thu, 12 Jun 2025 15:33:50 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v5]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

p-nima has updated the pull request incrementally with one additional commit since the last revision:

  apply review feedback and update java docs to clarify authentication retry behaviour

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/7a9eb0b2..9e8f29ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=03-04

  Stats: 8 lines in 3 files changed: 1 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Thu Jun 12 15:37:31 2025
From: duke at openjdk.org (p-nima)
Date: Thu, 12 Jun 2025 15:37:31 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v4]
In-Reply-To: <yYF_9QUw6w5KfqiKq1rbHl1w7vkE-E4viIjK21jUQEI=.b1b8d66f-d892-4014-a5da-bbeadf5de56e@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <07VxmSoS-Ig8Q-WgZfDW89I1Y350QzmC9Fa7ifuWsOE=.b8f72155-8afc-4498-a912-bca764f24e90@github.com>
 <sP8nTg9T0E5PdxCt3oaSq8oRuUvmqNwrZ4R0pBkLAow=.744fecd5-6dd8-440a-955f-dc0a2874bc7e@github.com>
 <kLy55UxgwiyIaumR9fjmtw7HhfaF8VFdn8IJDzXAeYg=.55522530-751a-49df-bfca-8a5f98293e54@github.com>
 <Q8boL7x-JLgzULxzhaQXTy617GbzO1acoSRiSr1dYKU=.a3e789e3-816e-4246-837a-80cb650c9382@github.com>
 <DC33X64BXrjV8eKaAKxWKZd0NgbUs8oqr7IzauUf_Z0=.97f82009-3242-4131-8a21-42db01973a73@github.com>
 <95UooRAtPUXrkajl68GbTmduwcpjUwGROnw-4tJGj34=.11365ec5-fbdf-4cbd-80fb-3b75d3d7f0fd@github.com>
 <Axu1AdbwV5s6WTxqjOXQtoIS5FSwwc7WJyHLdPC3JAM=.22ec2afb-18ad-4018-9f21-f7b2dbbe5f35@github.com>
 <VN8V3uoVPeZSl0dkIQSbFJPjxA_j2zu97GsiS4ydce0=.64fc9241-ab07-433c-b069-cbc73b659e6a@github.com>
 <yYF_9QUw6w5KfqiKq1rbHl1w7vkE-E4viIjK21jUQEI=.b1b8d66f-d892-4014-a5da-bbeadf5de56e@github.com>
Message-ID: <DzKwdp2E47n-JvyoGBUuExYQm-8-KdPbGHbgdmLL310=.21df559e-5fa4-4155-bfc9-5e0aa9c240c8@github.com>

On Thu, 12 Jun 2025 14:56:28 GMT, p-nima <duke at openjdk.org> wrote:

>> Agreed. And it's very good to have a test now to verify the expected behavior. So I would change the test to test the behaviour we want. Then double check that it fails with the current proposed changes, and pass if we revert those changes. Then I would clarify the documentation of the system property, in order to remove the confusion.
>
> Thanks all for your inputs, I will update the AuthenticationFilter and test accordingly and update the documentation to clarify the confusion.

The changes have been made in 9e8f29ee3ab03f26bbd39b70a6d829ffee2aaa11 - and java docs has been updated accordingly to reflect the behaviour.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2143079910

From dfuchs at openjdk.org  Thu Jun 12 16:09:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 16:09:06 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently
Message-ID: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>

Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.

The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.

-------------

Commit messages:
 - 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently

Changes: https://git.openjdk.org/jdk/pull/25783/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25783&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359364
  Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25783/head:pull/25783

PR: https://git.openjdk.org/jdk/pull/25783

From dfuchs at openjdk.org  Thu Jun 12 16:12:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 16:12:34 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v5]
In-Reply-To: <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
Message-ID: <ilUvc2TxJajwDotjJjxbfjvJamrVb1S_xbKq762Ua4w=.6d5f9adc-b6ed-410c-91b2-c858cb2ccb00@github.com>

On Thu, 12 Jun 2025 15:33:50 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review feedback and update java docs to clarify authentication retry behaviour

The test changes look good to me. I will let @Michael-Mc-Mahon comment on the proposed doc changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2921829032

From michaelm at openjdk.org  Thu Jun 12 16:58:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 12 Jun 2025 16:58:31 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v5]
In-Reply-To: <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
Message-ID: <yW-PUwvEkU1T1NqDqc3T604R0oMkZr2sK7hNDOlqXmo=.474c7044-7672-46f8-9197-86ac85bc8288@github.com>

On Thu, 12 Jun 2025 15:33:50 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review feedback and update java docs to clarify authentication retry behaviour

The change to module-info.java looks good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25490#issuecomment-2967578395

From vyazici at openjdk.org  Thu Jun 12 17:13:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 17:13:37 GMT
Subject: Integrated: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <r8Kgi9JEUSmbvtBlS0wHlFFPGGueK4zcW0hUmPVABaA=.84cad131-dff2-4b6f-b95f-754d6365d2f0@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

This pull request has now been integrated.

Changeset: 610a18e7
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/610a18e7b3bc9680031a2ba608b89ee6fdec795c
Stats:     74 lines in 3 files changed: 30 ins; 35 del; 9 mod

8358688: HttpClient: Simplify file streaming in RequestPublishers.FilePublisher

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/25662

From vyazici at openjdk.org  Thu Jun 12 17:13:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 17:13:36 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v6]
In-Reply-To: <DuHG7-APObF0a4HaDu2O_vHq4LiqFJ-uoM2r69bYads=.58573d25-3881-4abf-96d2-a4daaa70ab87@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <-XsfEj9EZYFYdIWz5ZBd2xMbkoQdYx6SMHuvVZuwzko=.2fa02b8a-74e6-4f1d-a74b-7791e5c4ed28@github.com>
 <DuHG7-APObF0a4HaDu2O_vHq4LiqFJ-uoM2r69bYads=.58573d25-3881-4abf-96d2-a4daaa70ab87@github.com>
Message-ID: <G5I7QhPjWSpXM9RgbJx96TsDsINV4lf2gI-rke-KZC8=.286ec191-3328-4687-a206-b23460369e41@github.com>

On Thu, 12 Jun 2025 14:42:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify `FilePublisherTest`
>
> The person who wrote the test was probably concerned that `fs.getPath("non-existent.txt");` could throw if passed a non-existing path. Looking at the API documentation that doesn't seem a valid concern. The only exception documented is `InvalidPathException` - so we should be good

@dfuch @jaikiran Thank you so much for reviews, much appreciated. :bowing_man:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2967615342

From dfuchs at openjdk.org  Thu Jun 12 17:16:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 17:16:36 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v5]
In-Reply-To: <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
Message-ID: <NVrw5g021UhzddFm4rmdwW7k1Lip6YNeEW0vneDKBFI=.f48ec5a9-cdda-49fd-b14e-ab47e95bd157@github.com>

On Thu, 12 Jun 2025 15:33:50 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review feedback and update java docs to clarify authentication retry behaviour

Marked as reviewed by dfuchs (Reviewer).

Changes requested by dfuchs (Reviewer).

test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

This is the wrong Copyright for a test file. Tests shouldn't have the Classpath exception. Please copy the copyright from a nearby test.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2922013950
PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2922019491
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2143255094

From dfuchs at openjdk.org  Thu Jun 12 17:30:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 17:30:29 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v5]
In-Reply-To: <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
Message-ID: <L3LYtDZxqv_pb0phlDwwXhXBeU84-Dz0_mtJf__9xac=.6ad26f9b-9782-4528-99f5-52a7cf9efdf3@github.com>

On Thu, 12 Jun 2025 15:33:50 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   apply review feedback and update java docs to clarify authentication retry behaviour

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.

This change should be reverted too now since we dind't change anything in this file...

-------------

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2922054640
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2143276204

From duke at openjdk.org  Thu Jun 12 17:52:51 2025
From: duke at openjdk.org (p-nima)
Date: Thu, 12 Jun 2025 17:52:51 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v6]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <0uzQkTnuxmgQKz8k1SE--gm8lMe4iBD5Y4NVF2xIvMI=.42888f65-58a6-4b5d-9784-8d3061d4efbc@github.com>

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

p-nima has updated the pull request incrementally with one additional commit since the last revision:

  update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/9e8f29ee..8803830b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=04-05

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Thu Jun 12 17:52:52 2025
From: duke at openjdk.org (p-nima)
Date: Thu, 12 Jun 2025 17:52:52 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v5]
In-Reply-To: <L3LYtDZxqv_pb0phlDwwXhXBeU84-Dz0_mtJf__9xac=.6ad26f9b-9782-4528-99f5-52a7cf9efdf3@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <YVHlbh3M1wwKU-Jvh6Mim_GWVVfBnzC7VxLFASwWZIc=.07fdb3dd-f8c2-4bbb-8610-12d3d9b61d64@github.com>
 <L3LYtDZxqv_pb0phlDwwXhXBeU84-Dz0_mtJf__9xac=.6ad26f9b-9782-4528-99f5-52a7cf9efdf3@github.com>
Message-ID: <4PXRZQVipHCro1Lutx2bEZ9FhgRnoM6-BbRkiqV3YUc=.806ddc7a-7ecd-4c52-8646-8862c2072e9f@github.com>

On Thu, 12 Jun 2025 17:27:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   apply review feedback and update java docs to clarify authentication retry behaviour
>
> src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2015, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> This change should be reverted too now since we dind't change anything in this file...

This has been updated in 8803830b39f03ef60e2e96a33773bf0fcd0e70e7

> test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java line 9:
> 
>> 7:  * published by the Free Software Foundation.  Oracle designates this
>> 8:  * particular file as subject to the "Classpath" exception as provided
>> 9:  * by Oracle in the LICENSE file that accompanied this code.
> 
> This is the wrong Copyright for a test file. Tests shouldn't have the Classpath exception. Please copy the copyright from a nearby test.

The copyright has been updated in 8803830b39f03ef60e2e96a33773bf0fcd0e70e7

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2143323964
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2143323687

From dfuchs at openjdk.org  Thu Jun 12 18:12:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 18:12:31 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v6]
In-Reply-To: <0uzQkTnuxmgQKz8k1SE--gm8lMe4iBD5Y4NVF2xIvMI=.42888f65-58a6-4b5d-9784-8d3061d4efbc@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <0uzQkTnuxmgQKz8k1SE--gm8lMe4iBD5Y4NVF2xIvMI=.42888f65-58a6-4b5d-9784-8d3061d4efbc@github.com>
Message-ID: <TbTCgp7HADEs0sNFI1F9fPVG2689S305CbDvhZQOfCo=.4ecda40c-9e59-4f86-ad9a-6f32bef9e2bf@github.com>

On Thu, 12 Jun 2025 17:52:51 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2922185123

From vyazici at openjdk.org  Thu Jun 12 18:23:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 18:23:28 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v5]
In-Reply-To: <URIa21DEmt-CjHGKszp_eJoIc9sU-9SiK77ijSAEY78=.c2004325-9f99-4a73-9728-9c0f4bb68787@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <URIa21DEmt-CjHGKszp_eJoIc9sU-9SiK77ijSAEY78=.c2004325-9f99-4a73-9728-9c0f4bb68787@github.com>
Message-ID: <esbaen5v8_DVDUxG6NRDpKVA0qeRV4dNVRMi4_r_85o=.a22db670-9c93-433f-a201-a7efe86ff8d8@github.com>

On Thu, 12 Jun 2025 12:48:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update

src/java.base/share/classes/java/net/HttpCookie.java line 892:

> 890:             assignAttribute(cookie, name, value);
> 891:         }
> 892:         assignMaxAgeAttribute(cookie, expiresValue, maxAgeValue);

@Michael-Mc-Mahon, instead of making an exception for `max-age` and `expires`, and removing them from `assignors`, can't we convert the type of `assignors` from `Map` to `List` and add `max-age` & `expires` entries at the end?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2143371218

From dfuchs at openjdk.org  Thu Jun 12 18:52:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 18:52:12 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently [v2]
In-Reply-To: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
Message-ID: <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>

> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
> 
> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Copyright update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25783/files
  - new: https://git.openjdk.org/jdk/pull/25783/files/2bb86456..30b6b0d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25783&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25783&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25783.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25783/head:pull/25783

PR: https://git.openjdk.org/jdk/pull/25783

From vyazici at openjdk.org  Thu Jun 12 18:52:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 18:52:12 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently [v2]
In-Reply-To: <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
 <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
Message-ID: <oPVwNyyHt6BAVJsF9uKxLNVymr8gIVd-yJ-2vI0wfiU=.c617d9da-7d06-49de-bcac-23ea123d18fc@github.com>

On Thu, 12 Jun 2025 18:49:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
>> 
>> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Copyright year needs to be updated.

-------------

Changes requested by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2922254792

From dfuchs at openjdk.org  Thu Jun 12 18:52:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 18:52:12 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently
In-Reply-To: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
Message-ID: <3x14juZEmwVxrij7f3NmuFRnFrvx7uf0Ng_Oj8f4GUM=.ac3bb61e-b8c1-476e-a516-59eab8594e29@github.com>

On Thu, 12 Jun 2025 16:02:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
> 
> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.

Done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25783#issuecomment-2967843407

From dfuchs at openjdk.org  Thu Jun 12 18:53:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Jun 2025 18:53:18 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <bttVrklfkEVMhRXGDs3ombxBWKJXkX3PFG9dg1qJyJo=.99d3a625-d679-43d7-9f2b-25ce105f521c@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:

 - merge latest changes from master branch
 - http3: update H3InsertionsLimitTest to start after receival of client settings
 - merge latest changes from master branch
 - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
 - quic: simplify idle timeout management
 - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
 - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=07
  Stats: 103752 lines in 472 files changed: 100891 ins; 1345 del; 1516 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From vyazici at openjdk.org  Thu Jun 12 18:56:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 12 Jun 2025 18:56:28 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently [v2]
In-Reply-To: <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
 <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
Message-ID: <C4aY7ZE4s1ewRR6fmjHSg8ju53_BjDKS8nzUII96tdM=.d70f3b38-6486-4b7d-aebd-e81be9c658c0@github.com>

On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
>> 
>> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2922279545

From syan at openjdk.org  Fri Jun 13 02:18:30 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Jun 2025 02:18:30 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently [v2]
In-Reply-To: <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
 <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
Message-ID: <lOPk8NKuMKO415bkA_-C9mzfJiiM-_TOie3E-df2_yQ=.6355ae1b-5126-4bc9-b558-851a62a6ffb8@github.com>

On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
>> 
>> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2923234349

From vyazici at openjdk.org  Fri Jun 13 06:57:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 06:57:29 GMT
Subject: RFR: 8359402: TesCloseDescriptors.java should throw
 SkippedException when there is no lsof/sctp
In-Reply-To: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
References: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
Message-ID: <XguKH8OUMXY_9DcuMCQyHpsNbTXBPMqQlnzZbhVwkLU=.5906a4fb-ebf7-4b55-b6e7-2fa4c8b90a61@github.com>

On Fri, 13 Jun 2025 06:36:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw jtreg.SkippedException when there is no lsof command or there is no SCTP in test machine.
> Before this PR, this test report Execution successful when there is no SCTP.
> 
> 
> --------------------------------------------------
> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
> TEST RESULT: Passed. Execution successful
> --------------------------------------------------
> 
> 
> After this PR, it will report `jtreg.SkippedException` when there is no SCTP
> 
> 
> --------------------------------------------------
> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
> TEST RESULT: Passed. Skipped: jtreg.SkippedException: SCTP protocol is not supported
> --------------------------------------------------
> 
> 
> Change has been verified locally, test-fix only, no risk.

Marked as reviewed by vyazici (Committer).

test/jdk/com/sun/nio/sctp/SctpChannel/CloseDescriptors.java line 30:

> 28:  * @requires (os.family == "linux")
> 29:  * @library /test/lib
> 30:  * @build jtreg.SkippedException

I've totally missed that `jtreg.SkippedException` should indeed be added to `@build`. Now I can land a PR touching thousands of test files using `SE`. ? (No, I won't. ?)

-------------

PR Review: https://git.openjdk.org/jdk/pull/25790#pullrequestreview-2923605868
PR Review Comment: https://git.openjdk.org/jdk/pull/25790#discussion_r2144328418

From jpai at openjdk.org  Fri Jun 13 07:12:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Jun 2025 07:12:17 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
Message-ID: <TgjIYra_EZCORDwtxT7aSC0udGPsXfCNCzCjWWGQRSo=.ad3342ba-54fa-4abf-b1de-b941e2ea6b67@github.com>

> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
> 
> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
> 
> If this requires a CSR, I'll open one once we settle on the proposed text.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  improve text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25690/files
  - new: https://git.openjdk.org/jdk/pull/25690/files/d6978f0d..124e0970

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=01-02

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25690/head:pull/25690

PR: https://git.openjdk.org/jdk/pull/25690

From jpai at openjdk.org  Fri Jun 13 07:12:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Jun 2025 07:12:17 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
Message-ID: <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>

On Thu, 12 Jun 2025 10:19:21 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Looking at this on the 3 main OS platforms (Windows, OL and macOS) and running a simple test to trigger a connect timeout then finding are
>> 
>> macOS the connect timeout is 75 seconds as this is derived from 4.3 BSD
>> 
>> If OL linux has a syn retries set to 6 and an RTO == 1 sec then it?s connect timeout is 130 seconds approx 
>> That?s initial syn timeout of 1 seconds and then 6 retries totalling 127 seconds
>> 
>> Windows by default connect timeout is 21 seconds
>> RTT == 3 seconds and two connect retries
>> Initial syn timeout 3 seconds + 2 retries at 6 and 12 seconds == 21 seconds
>
> FWIW an possible alternative wording
> 
> Establishing a TCP/IP connection is subject to a connect timeout, determined by configuration settings
> of the operating system, for example the number of connect retries together with a TCP/IP implementation?s back off strategy. Thus, TCP/IP Connect timeout values can vary across operating system, for example 75 seconds on macOS, with a  default value of 21 seconds on Windows system. As such, the operating system TCP/IP Connect timeout may expire before that specified to the connect method. If the operating system Connect timeout expires 
> before the {@code timeout} specified to this method then an {@code IOException} is thrown. The {@code timeout} 
> specified to this method is typically a timeout value that is shorter than the operating system timeout.

Hello Mark, I discussed this with Alan and based on those discussions I have now reworded that sentence to make it clear that 60 second isn't the only typical timeout and at the same time keep the text concise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2144350812

From vyazici at openjdk.org  Fri Jun 13 07:55:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 07:55:17 GMT
Subject: RFR: 8359223: HttpClient: Remove leftovers from the
 SecurityManager cleanup [v2]
In-Reply-To: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
References: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
Message-ID: <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>

> Removes following files added in [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) and are forgotten to be removed during the `SecurityManager`-removal ([JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228)):
> 
> 
> test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java
> test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java

Volkan Yazici 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 three additional commits since the last revision:

 - Move `FilePublisherTest` one level up
 - Merge remote-tracking branch 'upstream/master' into hcSmFollowUp
 - Remove leftover tests from the SecurityManager cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25747/files
  - new: https://git.openjdk.org/jdk/pull/25747/files/4a911af9..8eb99336

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25747&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25747&range=00-01

  Stats: 10935 lines in 147 files changed: 8513 ins; 1685 del; 737 mod
  Patch: https://git.openjdk.org/jdk/pull/25747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25747/head:pull/25747

PR: https://git.openjdk.org/jdk/pull/25747

From dfuchs at openjdk.org  Fri Jun 13 08:43:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 08:43:29 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <TgjIYra_EZCORDwtxT7aSC0udGPsXfCNCzCjWWGQRSo=.ad3342ba-54fa-4abf-b1de-b941e2ea6b67@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <TgjIYra_EZCORDwtxT7aSC0udGPsXfCNCzCjWWGQRSo=.ad3342ba-54fa-4abf-b1de-b941e2ea6b67@github.com>
Message-ID: <5sCNkHfRUmnD6njvNoLwv7CrO0tOMnb4EZMmZJxJTSQ=.99eae917-7cf9-402e-a30a-041802b8d2b3@github.com>

On Fri, 13 Jun 2025 07:12:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve text

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2923879325

From duke at openjdk.org  Fri Jun 13 08:56:33 2025
From: duke at openjdk.org (duke)
Date: Fri, 13 Jun 2025 08:56:33 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v6]
In-Reply-To: <0uzQkTnuxmgQKz8k1SE--gm8lMe4iBD5Y4NVF2xIvMI=.42888f65-58a6-4b5d-9784-8d3061d4efbc@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <0uzQkTnuxmgQKz8k1SE--gm8lMe4iBD5Y4NVF2xIvMI=.42888f65-58a6-4b5d-9784-8d3061d4efbc@github.com>
Message-ID: <tZe9KxIPzuMvaP15bo790yg4hmQHJDBeQNpwTUpg1U4=.9d65e051-a030-4037-ab2f-5329c65c421e@github.com>

On Thu, 12 Jun 2025 17:52:51 GMT, p-nima <duke at openjdk.org> wrote:

>> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
>> 
>> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
>> 
>> The test is green with tiers 1, 2, 3 and the test is stable.
>
> p-nima has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

@p-nima 
Your change (at version 8803830b39f03ef60e2e96a33773bf0fcd0e70e7) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25490#issuecomment-2969602241

From msheppar at openjdk.org  Fri Jun 13 09:19:29 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 13 Jun 2025 09:19:29 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
Message-ID: <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFwQZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>

On Fri, 13 Jun 2025 07:08:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> FWIW an possible alternative wording
>> 
>> Establishing a TCP/IP connection is subject to a connect timeout, determined by configuration settings
>> of the operating system, for example the number of connect retries together with a TCP/IP implementation?s back off strategy. Thus, TCP/IP Connect timeout values can vary across operating system, for example 75 seconds on macOS, with a  default value of 21 seconds on Windows system. As such, the operating system TCP/IP Connect timeout may expire before that specified to the connect method. If the operating system Connect timeout expires 
>> before the {@code timeout} specified to this method then an {@code IOException} is thrown. The {@code timeout} 
>> specified to this method is typically a timeout value that is shorter than the operating system timeout.
>
> Hello Mark, I discussed this with Alan and based on those discussions I have now reworded that sentence to make it clear that 60 second isn't the only typical timeout and at the same time keep the text concise.

Hi JP,
I don't understand why you are persisting with 60 seconds, when the original reporter shows its a default of 21 seconds on Windows, which I have also confirmed and that windows requires TcpMaxConnectRetransmissions to adjusted to enable a higher connect timeout. 21 seconds is a very much not typically 60 seconds

I have given feedback as a developer of the type of detail and wording which I would find useful. The "typically" statement is inaccurate and misleading

Also first sentence need minor refinement changing connection timeout to connect timeout 

connection timeout is when the connection is established
Thus should read:

Establishing a TCP/IP connection is subject to connect timeout settings in the operating system.

I think it is important to have some accurate details in this wording, as such documentation is taken a de facto standard and will persist for aeons

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2144570845

From duke at openjdk.org  Fri Jun 13 10:36:03 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 13 Jun 2025 10:36:03 GMT
Subject: Integrated: 8340182: Java HttpClient does not follow default retry
 limit of 3 retries
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <qtgMpdFfpwKh62WuKC5uEtB5u4kQ7aBYtoA_4dlZEV0=.b440f171-313a-47ce-9891-7ee25f6d2460@github.com>

On Wed, 28 May 2025 11:26:17 GMT, p-nima <duke at openjdk.org> wrote:

> The AuthenticationFilter did not respect the default retry limit of 3 retries in case of invalid credentials supplied.
> 
> This PR helps to resolve the bug and tests it with default and updated retry limit set via `jdk.httpclient.auth.retrylimit=1`.
> 
> The test is green with tiers 1, 2, 3 and the test is stable.

This pull request has now been integrated.

Changeset: ead4529c
Author:    Prateek Nima <prateek.nima at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ead4529c9219009fc4224e52e9ac4af5055e7137
Stats:     136 lines in 2 files changed: 135 ins; 0 del; 1 mod

8340182: Java HttpClient does not follow default retry limit of 3 retries

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25490

From alanb at openjdk.org  Fri Jun 13 13:14:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 13:14:34 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently [v2]
In-Reply-To: <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
 <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
Message-ID: <H_qnHqqx6nD0jc7ZfspFYa5AqqgTKD0VYZ-hYqPwTWE=.7ace08ab-af8d-4513-867c-801aa94b13ac@github.com>

On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
>> 
>> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2924763153

From jpai at openjdk.org  Fri Jun 13 13:18:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Jun 2025 13:18:38 GMT
Subject: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently [v2]
In-Reply-To: <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
 <x26ZGgj8W-1Qg0XYWr_bDcbXV-FprfBvclX5KiZXt_I=.976a47ef-5a83-4914-bb3c-f26681464884@github.com>
Message-ID: <PrwFoaveOfHi3PeUzQslIQjnYg5ERCbQoHKniQ1oAGE=.58e7566a-e077-436e-9eac-fd3f02b09ce4@github.com>

On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
>> 
>> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright update

This looks fine to me. Although there's a test `@run` which is not `othervm`, setting this default ProxySelector (and not resetting it back) should be fine since `jdk.net.url.delayParsing` by default is `false` and we don't set the ProxySelector in those cases.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2924775768

From dfuchs at openjdk.org  Fri Jun 13 13:18:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 13:18:38 GMT
Subject: Integrated: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently
In-Reply-To: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
References: <oJ5l65sjKcDyBB2o16aL0OgO-wgdf_BYdLoibelPlk0=.24ef5ade-a673-4452-97fd-ef2f675b9ca1@github.com>
Message-ID: <OpnXcnIflwOAbMq1XLVs7RxLxWQJVsUp8HoZSq7dExE=.64ee2174-d9d0-439b-ab23-c86418995d26@github.com>

On Thu, 12 Jun 2025 16:02:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Like [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may fail if a proxy is selected.
> 
> The test sets system properties and runs in otrhervm. The fix is to set up a default ProxySelector that will always return NO_PROXY.

This pull request has now been integrated.

Changeset: 57cabc6d
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57cabc6d741c14a8029aec324ba96e8ced4afcbd
Stats:     18 lines in 1 file changed: 17 ins; 0 del; 1 mod

8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently

Reviewed-by: vyazici, syan, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25783

From jpai at openjdk.org  Fri Jun 13 13:52:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 13 Jun 2025 13:52:36 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFwQZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
Message-ID: <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>

On Fri, 13 Jun 2025 09:16:39 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Also first sentence need minor refinement changing connection timeout to connect timeout
>
> connection timeout is when the connection is established

I haven't previously seen connection timeout term being used to mean a timeout (for the connection?) after the connection has been established. I'll however change that text to say "connect timeout" shortly.

> I don't understand why you are persisting with 60 seconds, when the original reporter shows its a default of 21 seconds on Windows, which I have also confirmed and that windows requires. 21 seconds is a very much not typically 60 seconds

The timeout values noted in that text are mere examples to convey the detail that application developers need to be aware that the `timeout` they pass to the `connect()` method may not influence connection establishment failure due to timeout. They aren't exhaustive. I had considered including 21 in that text too. Alan's suggestion was to mention "60 or 75 seconds".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145148121

From msheppar at openjdk.org  Fri Jun 13 14:17:32 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 13 Jun 2025 14:17:32 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
 <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
Message-ID: <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>

On Fri, 13 Jun 2025 13:49:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>The timeout values noted in that text are mere examples to convey the detail that application developers need to >be aware that the timeout they pass to the connect() method may not influence connection establishment failure >due to timeout. They aren't exhaustive. I had considered including 21 in that text too. Alan's suggestion was to >mention "60 or 75 seconds".

Right, the objective is to convey to a developer that when specifying a timeout to the connect method, that this timeout may be superseded by an OS's TCP/IP configuration's Connect timeout settings.

This is all that needs to be said. There is no need to state any typical values, but if you do then those values need to be factually correct, and for the currently supported platforms 60 seconds is not typical, it's 21, 75, and 128 seconds

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145194457

From alanb at openjdk.org  Fri Jun 13 14:38:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 14:38:41 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
 <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
 <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>
Message-ID: <7rB-5xN5tSAebxzwF1F7areeLlvpDwxDH-3ngVRJDck=.58f8b5d5-c544-43e2-ad16-6dc4c2314bd0@github.com>

On Fri, 13 Jun 2025 14:14:25 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> This is all that needs to be said. There is no need to state any typical values, but if you do then those values need to be factually correct, and for the currently supported platforms 60 seconds is not typical, it's 21, 75, and 128 seconds

The proposed wording in the current draft looks okay. It explains to the reader that establishing a TCP/IP connection is subject to an operating system timeout. It gives a sense of what that timeout might be, it's not hours or days, it's tens of seconds. I don't think we should attempt to list specific timeouts for specific operating system versions and configurations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145237517

From abarashev at openjdk.org  Fri Jun 13 14:45:00 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 13 Jun 2025 14:45:00 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v5]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <esnUNkBj9LPwYc4Y0oMz--CYw-oLMC4UimL2aKGr50Y=.a99616de-a1a1-4e74-8a2a-bee24e231bb0@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
> 
> **SUNX509 KeyManager performance before change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev 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 19 additional commits since the last revision:

 - Support certificate checks in SunX509 key manager
 - Address some review comments
 - Merge branch 'master' into JDK-8353113
 - Make the test run on TLSv1.3
 - Make sure the exception happens during KeyManager's algorithm check
 - Add PeerConstraintsCheck unit test
 - Add unit test
 - Code refactoring
 - Fix open unit tests
 - Adding a system property to skip the constraints checking. Remove SunX509c.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/5479addb...448442e9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/451e1efd..448442e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=03-04

  Stats: 228571 lines in 4300 files changed: 142799 ins; 58830 del; 26942 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From abarashev at openjdk.org  Fri Jun 13 14:48:31 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 13 Jun 2025 14:48:31 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
 <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>
Message-ID: <HiCi28cajcDKD8Ru8gjke2Q3-4rfc6hCNQ2EPlP52gQ=.3e188934-30df-4cea-90d0-32f62ba55696@github.com>

On Fri, 6 Jun 2025 21:11:16 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 401:
>> 
>>> 399:                 continue;
>>> 400:             }
>>> 401: 
>> 
>> I think we should also call `CertType.check` here, like in `X509KeyManagerImpl`. Since this change is now only selecting certificates with algorithms that are not disabled, I think it also makes sense to select certificates that have the proper extensions, etc and will not cause subsequent certificate chain validation failures.
>> 
>> This means we would have to change the name of the property so that it isn't only about disabling constraints checking. Perhaps: `jdk.tls.keymanager.disableCertSelectionChecking`.
>
> Yes, makes sense.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2145256449

From michaelm at openjdk.org  Fri Jun 13 14:52:29 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 13 Jun 2025 14:52:29 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v5]
In-Reply-To: <esbaen5v8_DVDUxG6NRDpKVA0qeRV4dNVRMi4_r_85o=.a22db670-9c93-433f-a201-a7efe86ff8d8@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <URIa21DEmt-CjHGKszp_eJoIc9sU-9SiK77ijSAEY78=.c2004325-9f99-4a73-9728-9c0f4bb68787@github.com>
 <esbaen5v8_DVDUxG6NRDpKVA0qeRV4dNVRMi4_r_85o=.a22db670-9c93-433f-a201-a7efe86ff8d8@github.com>
Message-ID: <YoSD3nFNjqLUCTidowJRkdGitSu7oU3utv0bwPNJni8=.5af7e986-b54c-442d-8e09-181678c42b76@github.com>

On Thu, 12 Jun 2025 18:20:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> @Michael-Mc-Mahon, instead of making an exception for `max-age` and `expires`, and removing them from `assignors`, can't we convert the type of `assignors` from `Map` to `List` and add `max-age` & `expires` entries at the end?

Just converting from Map to List wouldn't be enough. The problem is that both attribute types need to be handled together. You could change the attribute name recognition to some kind of pattern match to recognise either of them. Then you need to know which of them was set and what their values were.

Maybe, I could at least use the assignor pattern to recognise the two attributes and limit the special code to just actioning the values. I'll take a look at that now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2145264788

From dfuchs at openjdk.org  Fri Jun 13 15:09:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 15:09:04 GMT
Subject: [jdk25] RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails
 intermittently
Message-ID: <y94PRS-dIdmFzmpemzMTjylX_vLLbDBPfTiEDF9lVrI=.42a9eb7c-6a14-4d07-8564-a1df1c3aecdb@github.com>

Hi,

I would like to backport this test-only stabilization fix to the JDK 25.
This will remove some noise from the CI when running on macOS.

This is a clean backport.

-------------

Commit messages:
 - Backport 57cabc6d741c14a8029aec324ba96e8ced4afcbd

Changes: https://git.openjdk.org/jdk/pull/25804/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359364
  Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25804/head:pull/25804

PR: https://git.openjdk.org/jdk/pull/25804

From alanb at openjdk.org  Fri Jun 13 15:14:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Jun 2025 15:14:37 GMT
Subject: [jdk25] RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test
 fails intermittently
In-Reply-To: <y94PRS-dIdmFzmpemzMTjylX_vLLbDBPfTiEDF9lVrI=.42a9eb7c-6a14-4d07-8564-a1df1c3aecdb@github.com>
References: <y94PRS-dIdmFzmpemzMTjylX_vLLbDBPfTiEDF9lVrI=.42a9eb7c-6a14-4d07-8564-a1df1c3aecdb@github.com>
Message-ID: <NcGvtcMIi9QTgc8BYQxcSzon-GazRhiDBEM8sBKbQGQ=.70fbcaf9-ed07-4b35-83a4-452a970f20dc@github.com>

On Fri, 13 Jun 2025 15:01:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this test-only stabilization fix to the JDK 25.
> This will remove some noise from the CI when running on macOS.
> 
> This is a clean backport.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25804#pullrequestreview-2925184804

From michaelm at openjdk.org  Fri Jun 13 15:20:51 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 13 Jun 2025 15:20:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v6]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <UWbbbsVRfpG4xumMW92xoDHTSXNVnjH_G4g-phm3zHs=.29f24474-5863-4854-bb0d-9f5026eb70c4@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  impl update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/9a495d7f..b2211311

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=04-05

  Stats: 39 lines in 1 file changed: 19 ins; 15 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From msheppar at openjdk.org  Fri Jun 13 15:23:28 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 13 Jun 2025 15:23:28 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <7rB-5xN5tSAebxzwF1F7areeLlvpDwxDH-3ngVRJDck=.58f8b5d5-c544-43e2-ad16-6dc4c2314bd0@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
 <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
 <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>
 <7rB-5xN5tSAebxzwF1F7areeLlvpDwxDH-3ngVRJDck=.58f8b5d5-c544-43e2-ad16-6dc4c2314bd0@github.com>
Message-ID: <eS6Nx2kjFDTrbHnQML60i3B-KBKvmR3MEe6Asvd3ZUg=.745c2c13-f1ae-4f04-a05a-f6e4b16dd51d@github.com>

On Fri, 13 Jun 2025 14:36:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> "The timeout values noted in that text are mere examples to convey the detail that application developers need to be aware that the timeout they pass to the connect() method may not influence connection establishment failure due to timeout. They aren't exhaustive. I had considered including 21 in that text too. Alan's suggestion was to mention "60 or 75 seconds". "
>> 
>> Right, the objective is to convey to a developer that when specifying a timeout to the connect method, that this timeout may be superseded by an OS's TCP/IP configuration's Connect timeout settings.
>> 
>> This is all that needs to be said. There is no need to state any typical values, but if you do then those values need to be factually correct, and for the currently supported platforms 60 seconds is not typical, it's 21, 75, and 128 seconds
>> 
>> But if a developer takes guidance from the "typically 60 seconds" statement  on a Windows environment and set a timeout of 50 seconds, they will get
>> IOException is a java.net.ConnectException
>> java.net.ConnectException: Operation timed out
>> 
>> as reported in the original bug and as such, defeats the purpose of the apiNote
>
>> This is all that needs to be said. There is no need to state any typical values, but if you do then those values need to be factually correct, and for the currently supported platforms 60 seconds is not typical, it's 21, 75, and 128 seconds
> 
> The proposed wording in the current draft looks okay. It explains to the reader that establishing a TCP/IP connection is subject to an operating system timeout. It gives a sense of what that timeout might be, it's not hours or days, it's tens of seconds. I don't think we should attempt to list specific timeouts for specific operating system versions and configurations.

why are you insisting on specifying 60 seconds? It does not exist on any supported OS platform. There is no need to specify any value in the apiNote, all it does is add misinformation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145324159

From dfuchs at openjdk.org  Fri Jun 13 16:12:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 16:12:32 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <eS6Nx2kjFDTrbHnQML60i3B-KBKvmR3MEe6Asvd3ZUg=.745c2c13-f1ae-4f04-a05a-f6e4b16dd51d@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
 <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
 <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>
 <7rB-5xN5tSAebxzwF1F7areeLlvpDwxDH-3ngVRJDck=.58f8b5d5-c544-43e2-ad16-6dc4c2314bd0@github.com>
 <eS6Nx2kjFDTrbHnQML60i3B-KBKvmR3MEe6Asvd3ZUg=.745c2c13-f1ae-4f04-a05a-f6e4b16dd51d@github.com>
Message-ID: <i-_ZZrX9UrXaw3Kijk-mvRYyQyuAba_G3eVrJWum6lY=.2a12dec2-7d2e-4da8-90d2-2760f8f95e88@github.com>

On Fri, 13 Jun 2025 15:20:47 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>>> This is all that needs to be said. There is no need to state any typical values, but if you do then those values need to be factually correct, and for the currently supported platforms 60 seconds is not typical, it's 21, 75, and 128 seconds
>> 
>> The proposed wording in the current draft looks okay. It explains to the reader that establishing a TCP/IP connection is subject to an operating system timeout. It gives a sense of what that timeout might be, it's not hours or days, it's tens of seconds. I don't think we should attempt to list specific timeouts for specific operating system versions and configurations.
>
> why are you insisting on specifying 60 seconds? It does not exist on any supported OS platform. There is no need to specify any value in the apiNote, all it does is add misinformation

Maybe we could say:


The typical operating system timeout ranges within tens of seconds to minutes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145436929

From msheppar at openjdk.org  Fri Jun 13 16:20:31 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 13 Jun 2025 16:20:31 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v3]
In-Reply-To: <i-_ZZrX9UrXaw3Kijk-mvRYyQyuAba_G3eVrJWum6lY=.2a12dec2-7d2e-4da8-90d2-2760f8f95e88@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
 <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
 <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>
 <7rB-5xN5tSAebxzwF1F7areeLlvpDwxDH-3ngVRJDck=.58f8b5d5-c544-43e2-ad16-6dc4c2314bd0@github.com>
 <eS6Nx2kjFDTrbHnQML60i3B-KBKvmR3MEe6Asvd3ZUg=.745c2c13-f1ae-4f04-a05a-f6e4b16dd51d@github.com>
 <i-_ZZrX9UrXaw3Kijk-mvRYyQyuAba_G3eVrJWum6lY=.2a12dec2-7d2e-4da8-90d2-2760f8f95e88@github.com>
Message-ID: <u72q3dryMVlGQi8H4ppErSFgDw3_DKPk80W4nVpQZiM=.50d8774d-f1ae-49a4-a7a6-009453fc3db2@github.com>

On Fri, 13 Jun 2025 16:08:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> why are you insisting on specifying 60 seconds? It does not exist on any supported OS platform. There is no need to specify any value in the apiNote, all it does is add misinformation
>
> Maybe we could say:
> 
> 
> The typical operating system timeout ranges within tens of seconds to minutes.

? very good suggestion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145459046

From dfuchs at openjdk.org  Fri Jun 13 16:57:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Jun 2025 16:57:31 GMT
Subject: [jdk25] Integrated: 8359364: java/net/URL/EarlyOrDelayedParsing test
 fails intermittently
In-Reply-To: <y94PRS-dIdmFzmpemzMTjylX_vLLbDBPfTiEDF9lVrI=.42a9eb7c-6a14-4d07-8564-a1df1c3aecdb@github.com>
References: <y94PRS-dIdmFzmpemzMTjylX_vLLbDBPfTiEDF9lVrI=.42a9eb7c-6a14-4d07-8564-a1df1c3aecdb@github.com>
Message-ID: <2TTE40IDZATFfsJDAM0uuaHan2jf6iAO-dk6mdL3_WA=.d339101e-4506-40fc-b709-16fe6e6be9c2@github.com>

On Fri, 13 Jun 2025 15:01:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this test-only stabilization fix to the JDK 25.
> This will remove some noise from the CI when running on macOS.
> 
> This is a clean backport.

This pull request has now been integrated.

Changeset: 41117308
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41117308450a09df2de3ba608612b1ec67988761
Stats:     18 lines in 1 file changed: 17 ins; 0 del; 1 mod

8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently

Reviewed-by: alanb
Backport-of: 57cabc6d741c14a8029aec324ba96e8ced4afcbd

-------------

PR: https://git.openjdk.org/jdk/pull/25804

From philip.race at oracle.com  Fri Jun 13 22:11:36 2025
From: philip.race at oracle.com (Philip Race)
Date: Fri, 13 Jun 2025 15:11:36 -0700
Subject: java.net.URLConnection.getContent()
Message-ID: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>

java.net.URLConnection has
public Object getContent();

It uses the desktop module to find handlers for image and audio data

Briefly, the desktop module
 ??? "provides java.net.ContentHandlerFactory with
 ??????? sun.awt.www.content.MultimediaContentHandlers;"

That knows about several audio and image mime types.

And URLConnection passes a mimetype string to the ContentHandlerFactory

If it is one of the mimetypes known to the desktop provider 
URLConnection gets returned one of
URLImageSource
java.awt.Image
java.applet.AudioClip

But the return type of getContent() is just java.lang.Object and nothing 
is specified.

How does anything use this API ?

The reason this comes up is that when removing the Applet API, this 
needs to transition to something
other than AudioClip - but who would notice if it got back null instead 
? Or just a byte[] of the raw data ?
Or something else ?

Is this API actually used ? Or useful ?

-phil

From alan.bateman at oracle.com  Sat Jun 14 07:21:28 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Jun 2025 08:21:28 +0100
Subject: java.net.URLConnection.getContent()
In-Reply-To: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>
References: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>
Message-ID: <4b902adf-f050-49dd-8402-f2115ffa8533@oracle.com>

On 13/06/2025 23:11, Philip Race wrote:
> java.net.URLConnection has
> public Object getContent();
>
> It uses the desktop module to find handlers for image and audio data
>
> Briefly, the desktop module
> ??? "provides java.net.ContentHandlerFactory with
> ??????? sun.awt.www.content.MultimediaContentHandlers;"
>
> That knows about several audio and image mime types.
>
> And URLConnection passes a mimetype string to the ContentHandlerFactory
>
> If it is one of the mimetypes known to the desktop provider 
> URLConnection gets returned one of
> URLImageSource
> java.awt.Image
> java.applet.AudioClip
>
> But the return type of getContent() is just java.lang.Object and 
> nothing is specified.
>
> How does anything use this API ?
>
> The reason this comes up is that when removing the Applet API, this 
> needs to transition to something
> other than AudioClip - but who would notice if it got back null 
> instead ? Or just a byte[] of the raw data ?
> Or something else ?
>
> Is this API actually used ? Or useful ?

This is a JDK 1.0 era API. The intent seems to be to test the return 
with instanceof to test for types that the caller can deal with. The 
1-arg overload allows the caller to provider an array of the types that 
it can deal with. Ironically, the addition of pattern matching for 
instanceof and other work on patterns makes it easier to use.

I did a quick search to see if there is a mapping/table anywhere on MIME 
type to Java class but don't see it.

In any case, with the removal of java.applet then it can't return an 
AudioClip, and existing code that expects an AudioClip won't compile or 
run. Looking at JavaSoundAudioClip then it doesn't look like there are 
other audio types implemented. I can't case to a SoundClip or other 
sound types, right? So I think dropping it should be okay, meaning null 
will be returned.

-Alan



From jpai at openjdk.org  Sun Jun 15 04:29:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 15 Jun 2025 04:29:40 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <-19lLxuydf8B_cCj9F7p0g_iFTx5tGagkJxdihC02WE=.1ebbbe5e-e7cf-48c1-81bd-e402d2ab0f84@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8359594

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25744#issuecomment-2973486415

From jpai at openjdk.org  Sun Jun 15 04:41:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 15 Jun 2025 04:41:22 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v4]
In-Reply-To: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
Message-ID: <3L3ETIAc2JlLYbdRdvvDg01M5yv6VSKLmDVamwYtuBU=.1f7b1bf4-fffd-4f5d-b999-853c1a7325de@github.com>

> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
> 
> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
> 
> If this requires a CSR, I'll open one once we settle on the proposed text.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Mark's suggestion - use "connect timeout" instead of "connection timeout"
 - Daniel's suggestion for the text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25690/files
  - new: https://git.openjdk.org/jdk/pull/25690/files/124e0970..381919bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25690/head:pull/25690

PR: https://git.openjdk.org/jdk/pull/25690

From jpai at openjdk.org  Sun Jun 15 04:41:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 15 Jun 2025 04:41:22 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v4]
In-Reply-To: <u72q3dryMVlGQi8H4ppErSFgDw3_DKPk80W4nVpQZiM=.50d8774d-f1ae-49a4-a7a6-009453fc3db2@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <8wWrOyIHdzAtsXCR1g9CgpKljPbczZNQNT9M9BqUW8A=.3a679a9a-f2bb-4af6-8cf0-2c7e1a28f8f5@github.com>
 <zKxKr_f6As7ZR0ZSXziAhNyLOwl3uwru1E_qm8lW4-U=.873c9a8a-993a-45a8-ac57-5eff8466c438@github.com>
 <x1wGtJIzSf_zncKOI5vd0FG5EIaQFiXNBmp3HcXXrBc=.69f47d70-abe7-444c-8fce-6b1f369bd8be@github.com>
 <35xMK7DnRbEjnJ_3WWdBTCeRPSE6kWOeuQo27R9JBxo=.ac64d479-e0f4-4457-ab1e-f029db2a1017@github.com>
 <MZ4lKQQH5bwjWrAfZArhrM9RYdm0CpBOpTX6q2FoGFs=.e1378668-5ada-489e-810c-c7fc9f98c987@github.com>
 <stDfjD1GfqivY4qVK3urHwBOiqGNNvgqCAB9YJv6zXw=.69677d3f-e3c6-4b01-98e7-682d595c0df4@github.com>
 <Tl2yDUug2qbG_3maGxAb7J356BnwZ-OzPNr-61lJgBM=.446ab2e6-0993-43d1-8fa4-6c4163dee1ca@github.com>
 <wYoLGM1sOuGrwJXrswJxwahG5TtLFWZtPy-CND-AQfc=.48b00892-b21f-4fad-939b-1acfcc99c1ac@github.com>
 <M6Tgu42jH6QsoJBLwEmxP-beA5CG6-v2MLhMOai1ciI=.cf1601cd-814a-402e-9b01-8186a5d26e31@github.com>
 <gyumAwbWKNqnDQktuwEGMwgPp23czTiJgFw
 QZSoWjGw=.085b6aea-e47f-46ee-8d97-6395cbcdfed8@github.com>
 <6S6S5twQAvKm95HYAwL2E4pZbQwPCbn8rAZe5N5PaJQ=.094497c6-2071-4597-bd84-2c6222c815da@github.com>
 <nQPaYGZRM821OgBrxQYg0ynTu2t_Re6uQsZI3C66R6U=.4e880825-1b44-4e40-9bc1-f8c11eaa5378@github.com>
 <7rB-5xN5tSAebxzwF1F7areeLlvpDwxDH-3ngVRJDck=.58f8b5d5-c544-43e2-ad16-6dc4c2314bd0@github.com>
 <eS6Nx2kjFDTrbHnQML60i3B-KBKvmR3MEe6Asvd3ZUg=.745c2c13-f1ae-4f04-a05a-f6e4b16dd51d@github.com>
 <i-_ZZrX9UrXaw3Kijk-mvRYyQyuAba_G3eVrJWum6lY=.2a12dec2-7d2e-4da8-90d2-2760f8f95e88@github.com>
 <u72q3dryMVlGQi8H4ppErSFgDw3_DKPk80W4nVpQZiM=.50d8774d-f1ae-49a4-a7a6-009453fc3db2@github.com>
Message-ID: <0lr0KtVJfCQUN2urEhkKznDKAA-I7rJsuHC5hLxY-yE=.8c44d998-f36f-4959-99f6-18703e5671c6@github.com>

On Fri, 13 Jun 2025 16:17:31 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Maybe we could say:
>> 
>> 
>> The typical operating system timeout ranges within tens of seconds to minutes.
>
> ? very good suggestion

>  I'll however change that text to say "connect timeout" shortly.

Done.



> Maybe we could say:
> 
> 
> The typical operating system timeout ranges within tens of seconds to minutes.
> 

I see that Mark is OK with this text, so I've updated the PR to use this text. Alan, does this updated text look OK?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2147424653

From philip.race at oracle.com  Sun Jun 15 16:33:11 2025
From: philip.race at oracle.com (Philip Race)
Date: Sun, 15 Jun 2025 09:33:11 -0700
Subject: java.net.URLConnection.getContent()
In-Reply-To: <4b902adf-f050-49dd-8402-f2115ffa8533@oracle.com>
References: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>
 <4b902adf-f050-49dd-8402-f2115ffa8533@oracle.com>
Message-ID: <9d8276b3-5a9a-4016-bec8-f0b904bcd74d@oracle.com>

Perhaps these APIs should be deprecated (for removal) ?

For 30 years, AudioClip has been the only public type that this API 
returned for audio data.
Clearly that won't be possible after it is removed.

SoundClip is the replacement for public uses of AudioClip so it is the 
obvious replacement.
And I can without too much work return a SoundClip, and that offers the 
same migration path
as for direct API uses of AudioClip, so may be it is the best short term 
thing, whilst a longer term
deprecation is worked out ?

-phil.

On 6/14/25 12:21 AM, Alan Bateman wrote:
> On 13/06/2025 23:11, Philip Race wrote:
>> java.net.URLConnection has
>> public Object getContent();
>>
>> It uses the desktop module to find handlers for image and audio data
>>
>> Briefly, the desktop module
>> ??? "provides java.net.ContentHandlerFactory with
>> ??????? sun.awt.www.content.MultimediaContentHandlers;"
>>
>> That knows about several audio and image mime types.
>>
>> And URLConnection passes a mimetype string to the ContentHandlerFactory
>>
>> If it is one of the mimetypes known to the desktop provider 
>> URLConnection gets returned one of
>> URLImageSource
>> java.awt.Image
>> java.applet.AudioClip
>>
>> But the return type of getContent() is just java.lang.Object and 
>> nothing is specified.
>>
>> How does anything use this API ?
>>
>> The reason this comes up is that when removing the Applet API, this 
>> needs to transition to something
>> other than AudioClip - but who would notice if it got back null 
>> instead ? Or just a byte[] of the raw data ?
>> Or something else ?
>>
>> Is this API actually used ? Or useful ?
>
> This is a JDK 1.0 era API. The intent seems to be to test the return 
> with instanceof to test for types that the caller can deal with. The 
> 1-arg overload allows the caller to provider an array of the types 
> that it can deal with. Ironically, the addition of pattern matching 
> for instanceof and other work on patterns makes it easier to use.
>
> I did a quick search to see if there is a mapping/table anywhere on 
> MIME type to Java class but don't see it.
>
> In any case, with the removal of java.applet then it can't return an 
> AudioClip, and existing code that expects an AudioClip won't compile 
> or run. Looking at JavaSoundAudioClip then it doesn't look like there 
> are other audio types implemented. I can't case to a SoundClip or 
> other sound types, right? So I think dropping it should be okay, 
> meaning null will be returned.
>
> -Alan
>
>


From alan.bateman at oracle.com  Sun Jun 15 18:26:09 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Jun 2025 19:26:09 +0100
Subject: java.net.URLConnection.getContent()
In-Reply-To: <9d8276b3-5a9a-4016-bec8-f0b904bcd74d@oracle.com>
References: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>
 <4b902adf-f050-49dd-8402-f2115ffa8533@oracle.com>
 <9d8276b3-5a9a-4016-bec8-f0b904bcd74d@oracle.com>
Message-ID: <a7989e6c-21ac-410b-aa8f-738be4518564@oracle.com>

On 15/06/2025 17:33, Philip Race wrote:
> Perhaps these APIs should be deprecated (for removal) ?

Maybe but would require a lot of analysis to understand impact as there 
are several ways to configure content handlers and there are stream 
handlers that exist outside of the JDK that might interact with this. 
It's also very possible that there are usages that just assume an 
InputStream.

>
> For 30 years, AudioClip has been the only public type that this API 
> returned for audio data.
> Clearly that won't be possible after it is removed.
>
> SoundClip is the replacement for public uses of AudioClip so it is the 
> obvious replacement.
> And I can without too much work return a SoundClip, and that offers 
> the same migration path
> as for direct API uses of AudioClip, so may be it is the best short 
> term thing, whilst a longer term
> deprecation is worked out ?

A migration from AudioClip to SoundClip would require all usages to 
change too. I think for now that it should be okay to just the mapping 
from MultimediaContentHandlers so that it returns null.

-Alan

From jpai at openjdk.org  Mon Jun 16 07:00:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 07:00:31 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than 200
 on Windows 8+
Message-ID: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>

Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.

As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.

The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.

A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.

-------------

Commit messages:
 - fix typo in code comment in test
 - 8330940: Impossible to create a socket backlog greater than 200 on Windows 8+

Changes: https://git.openjdk.org/jdk/pull/25819/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25819&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330940
  Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25819.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25819/head:pull/25819

PR: https://git.openjdk.org/jdk/pull/25819

From jpai at openjdk.org  Mon Jun 16 07:28:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 07:28:18 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race
Message-ID: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>

Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.

In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.

The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.

I've run this change around a 1000 times and haven't seen it fail.

P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

-------------

Commit messages:
 - 8359477: com/sun/net/httpserver/Test12.java appears to have a temp file race
 - 8359477: general cleanup of the test

Changes: https://git.openjdk.org/jdk/pull/25820/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25820&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359477
  Stats: 122 lines in 1 file changed: 35 ins; 60 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25820/head:pull/25820

PR: https://git.openjdk.org/jdk/pull/25820

From jpai at openjdk.org  Mon Jun 16 07:32:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 07:32:19 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v2]
In-Reply-To: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
Message-ID: <r1Jt_0UGHy-1ed_uRlLWDZdTKLsmZMGRahI256fL9Zw=.d2b9ad3d-214c-477f-b8fa-2ea62902301d@github.com>

> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
> 
> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
> 
> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
> 
> I've run this change around a 1000 times and haven't seen it fail.
> 
> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add a log message in the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25820/files
  - new: https://git.openjdk.org/jdk/pull/25820/files/a0f8fc80..a84102d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25820&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25820&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25820/head:pull/25820

PR: https://git.openjdk.org/jdk/pull/25820

From alanb at openjdk.org  Mon Jun 16 07:46:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jun 2025 07:46:28 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+
In-Reply-To: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
Message-ID: <MsHrhUedu-FddqJUdIfN_eQjXH8YxAKtDScX8-60VLs=.fafad288-a08d-4ed0-97fb-f66fca1d5db3@github.com>

On Mon, 16 Jun 2025 06:54:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
> 
> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
> 
> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
> 
> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.

src/java.base/windows/native/libnio/ch/Net.c line 225:

> 223:      * SOMAXCONN_HINT will adjust the value N to be within the range (200, 65535).
> 224:      */
> 225:     if (backlog >= 200) {

Should this is > 200 rather than >= 200?

This is a Windows specific file so the comment can be trimmed down to a one sentence to say that SOMAXCONN_HINT is used when requested backlog is larger than SOMAXCONN.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149261450

From alanb at openjdk.org  Mon Jun 16 07:50:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jun 2025 07:50:32 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+
In-Reply-To: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
Message-ID: <wmvD5PIBqyFY17M6l9TZaB8a2lzSLvLYmBciPxV0Wcc=.dfdbcf47-7871-477e-8de3-c802c5b09eb1@github.com>

On Mon, 16 Jun 2025 06:54:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
> 
> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
> 
> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
> 
> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.

test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 43:

> 41:  * @run junit LargeBacklogTest
> 42:  */
> 43: class LargeBacklogTest {

How reliable is this test? If it is reliable then we can add tests for SocketChannelChannel::socket and AsynchronousServerSocket too.

test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 72:

> 70:     private static void testBackloggedConnects(final int backlog, final int serverPort) {
> 71:         int numSuccessfulConnects = 0;
> 72:         System.out.println("attempting " + backlog + " connections to port " + serverPort);

I don't know if this is a left over trace message or not. If intended then you might have to change it to use System.err so that it inlines with the test (at least I think JUnit uses System.err, TestNG uses System.out).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149266221
PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149267956

From jpai at openjdk.org  Mon Jun 16 08:04:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 08:04:19 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
Message-ID: <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>

> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
> 
> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
> 
> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
> 
> I've run this change around a 1000 times and haven't seen it fail.
> 
> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  minor change to test's log message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25820/files
  - new: https://git.openjdk.org/jdk/pull/25820/files/a84102d9..42b86dee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25820&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25820&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25820/head:pull/25820

PR: https://git.openjdk.org/jdk/pull/25820

From vyazici at openjdk.org  Mon Jun 16 08:58:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 08:58:34 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
Message-ID: <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>

On Mon, 16 Jun 2025 08:04:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses an intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This fixes https://bugs.openjdk.org/browse/JDK-8359477.
>> 
>> In the linked JBS issue I've added a comment which explains what causes this intermittent failure. The issue is a bug/race within the test. There are 2 commits in this PR and only of them is necessary for addressing this issue. The other one is a general cleanup of the test. I am willing to revert the general cleanup commit from this test if others feel that it shouldn't be done in this PR.
>> 
>> The actual fix is this commit https://github.com/openjdk/jdk/commit/a0f8fc806e1682ef909cb7b4a449be855072fe48 which stops deleting the input files upon test completion. That should be OK because the jtreg test infrastructure will clean them up from the scratch directory after the completion of the test run (if the test succeeds). There are other ways to address this race condition and continue to delete these files (for example, co-ordinating between the test and the test specific `FileServerHandler`), but to me it didn't seem worthwhile doing that.
>> 
>> I've run this change around a 1000 times and haven't seen it fail.
>> 
>> P.S: The `test/jdk/com/sun/net/httpserver/Test1.java` does the same things as this test, but does it sequentially. I'm pretty sure that we should be able to trigger this intermittent test failure in that test too if I reorder the `test()` calls in that test to have a fixed length test be the last one to execute (i.e. `test (true, ...)` instead of the current `test(false, ...)`).
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change to test's log message

Marked as reviewed by vyazici (Committer).

test/jdk/com/sun/net/httpserver/Test12.java line 113:

> 111:                 executor.shutdown ();
> 112:             Files.delete(smallFilePath);
> 113:             Files.delete(largeFilePath);

Instead of removing the file cleanup, IMHO, _good practice_, can't we use `shutdown() + awaitTermination()` or `shutdownNow()` for the executor?

-------------

PR Review: https://git.openjdk.org/jdk/pull/25820#pullrequestreview-2931204355
PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149408509

From jpai at openjdk.org  Mon Jun 16 09:24:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 09:24:30 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
Message-ID: <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>

On Mon, 16 Jun 2025 08:56:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor change to test's log message
>
> test/jdk/com/sun/net/httpserver/Test12.java line 113:
> 
>> 111:                 executor.shutdown ();
>> 112:             Files.delete(smallFilePath);
>> 113:             Files.delete(largeFilePath);
> 
> Instead of removing the file cleanup, IMHO, _good practice_, can't we use `shutdown() + awaitTermination()` or `shutdownNow()` for the executor?

Hello Volkan, the issue here's isn't about not waiting for the tasks to complete. They in fact do complete. The actual issue is that the tasks have no way to know if the server side has actually done a `FileInputStream.close()` for the fixed length case, because the `InputStream` handed out to those tasks doesn't wait to receive a EOF from the server side for the fixed length case. Instead since the InputStream knows how many bytes to expect, once it receives those many bytes, it immediately returns. The server side (in FileServerHandler) would have transmitted those bytes and would be in the process of closing the FileInputStream, but the client side task would already be completed. So adding a `awaitTermination()` on the executor will not help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149460968

From jpai at openjdk.org  Mon Jun 16 09:32:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 09:32:31 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
Message-ID: <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>

On Mon, 16 Jun 2025 09:22:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/Test12.java line 113:
>> 
>>> 111:                 executor.shutdown ();
>>> 112:             Files.delete(smallFilePath);
>>> 113:             Files.delete(largeFilePath);
>> 
>> Instead of removing the file cleanup, IMHO, _good practice_, can't we use `shutdown() + awaitTermination()` or `shutdownNow()` for the executor?
>
> Hello Volkan, the issue here's isn't about not waiting for the tasks to complete. They in fact do complete. The actual issue is that the tasks have no way to know if the server side has actually done a `FileInputStream.close()` for the fixed length case, because the `InputStream` handed out to those tasks doesn't wait to receive a EOF from the server side for the fixed length case. Instead since the InputStream knows how many bytes to expect, once it receives those many bytes, it immediately returns. The server side (in FileServerHandler) would have transmitted those bytes and would be in the process of closing the FileInputStream, but the client side task would already be completed. So adding a `awaitTermination()` on the executor will not help.

> Instead of removing the file cleanup, IMHO, good practice

They do get cleaned up - jtreg cleans up the scratch directories (unless asked not to do so) when the test completes. The general pattern we use in JDK tests is to let jtreg clean them up for us so that if the test has failed (for whatever reason), then due to the use of `-retain:fail,error`, these input files are retained by jtreg so that they can help debug any unexpected test failures. 
In this case, the input files themselves very likely won't play a role in any unexpected failures. So if we still prefer to delete these explicitly in the test, then I can fix this in a different way -  that will require a bit more code for handshake between the test's `FileServerHandler` and the test itself to ensure that the test knows when it is OK to delete these files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149483105

From jpai at openjdk.org  Mon Jun 16 09:44:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 09:44:13 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
Message-ID: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>

> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
> 
> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
> 
> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
> 
> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.

Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:

 - include a test for AsynchronousServerSocketChannel
 - System.err instead of System.out
 - trim down code comment
 -  > 200 instead of >= 200

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25819/files
  - new: https://git.openjdk.org/jdk/pull/25819/files/b5fb869a..eb77b5e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25819&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25819&range=00-01

  Stats: 25 lines in 2 files changed: 14 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25819.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25819/head:pull/25819

PR: https://git.openjdk.org/jdk/pull/25819

From jpai at openjdk.org  Mon Jun 16 09:44:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 09:44:13 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <MsHrhUedu-FddqJUdIfN_eQjXH8YxAKtDScX8-60VLs=.fafad288-a08d-4ed0-97fb-f66fca1d5db3@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <MsHrhUedu-FddqJUdIfN_eQjXH8YxAKtDScX8-60VLs=.fafad288-a08d-4ed0-97fb-f66fca1d5db3@github.com>
Message-ID: <azKeJtjUFxdYFpxYMR_jnpO-poo8AZ35WBfFoS0UDmE=.a4596218-3143-426b-a093-a2ff93cd10af@github.com>

On Mon, 16 Jun 2025 07:43:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - include a test for AsynchronousServerSocketChannel
>>  - System.err instead of System.out
>>  - trim down code comment
>>  -  > 200 instead of >= 200
>
> src/java.base/windows/native/libnio/ch/Net.c line 225:
> 
>> 223:      * SOMAXCONN_HINT will adjust the value N to be within the range (200, 65535).
>> 224:      */
>> 225:     if (backlog >= 200) {
> 
> Should this is > 200 rather than >= 200?
> 
> This is a Windows specific file so the comment can be trimmed down to a one sentence to say that SOMAXCONN_HINT is used when requested backlog is larger than SOMAXCONN.

Hello Alan,

> Should this is > 200 rather than >= 200?

I don't recollect why I used >= 200 when I started experimenting with these changes a few weeks back. I think it was just an oversight. I now went back and checked on a Windows setup and > 200 works fine. I've now updated the PR with this change.

> This is a Windows specific file so the comment can be trimmed down to a one sentence to say that SOMAXCONN_HINT is used when requested backlog is larger than SOMAXCONN.

Done, the comment is trimmed down too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149510540

From michaelm at openjdk.org  Mon Jun 16 09:52:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 16 Jun 2025 09:52:31 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <SOSYLH-3t2xPsqx03dA9DKLmLZNZNgjAmhKGfDr5uxg=.28c41219-583d-40b3-95f3-35fe33a03cb5@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Are you sure that Windows does cap the value currently to SOMAXCONN, if the parameter is > 200?

I'm not seeing a statement to that effect in the docs, but maybe it is the observed behavior?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-2975862156

From vyazici at openjdk.org  Mon Jun 16 09:52:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 09:52:33 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
 <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
Message-ID: <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>

On Mon, 16 Jun 2025 09:29:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Volkan, the issue here's isn't about not waiting for the tasks to complete. They in fact do complete. The actual issue is that the tasks have no way to know if the server side has actually done a `FileInputStream.close()` for the fixed length case, because the `InputStream` handed out to those tasks doesn't wait to receive a EOF from the server side for the fixed length case. Instead since the InputStream knows how many bytes to expect, once it receives those many bytes, it immediately returns. The server side (in FileServerHandler) would have transmitted those bytes and would be in the process of closing the FileInputStream, but the client side task would already be completed. So adding a `awaitTermination()` on the executor will not help.
>
>> Instead of removing the file cleanup, IMHO, good practice
> 
> They do get cleaned up - jtreg cleans up the scratch directories (unless asked not to do so) when the test completes. The general pattern we use in JDK tests is to let jtreg clean them up for us so that if the test has failed (for whatever reason), then due to the use of `-retain:fail,error`, these input files are retained by jtreg so that they can help debug any unexpected test failures. 
> In this case, the input files themselves very likely won't play a role in any unexpected failures. So if we still prefer to delete these explicitly in the test, then I can fix this in a different way -  that will require a bit more code for handshake between the test's `FileServerHandler` and the test itself to ensure that the test knows when it is OK to delete these files.

> the issue here's isn't about not waiting for the tasks to complete. They in fact do complete. The actual issue is that the tasks have no way to know if the server side has actually done a `FileInputStream.close()` for the fixed length case

@jaikiran, `executor` is configured for the servers via `s1.setExecutor (executor)` and `s2.setExecutor (executor)` lines above. I was under the impression that shutting down the executor (i.e., interrupting the server handlers) would result in server releasing all acquired resources, including issuing a `FIS::close`. Was I mistaken?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149527378

From jpai at openjdk.org  Mon Jun 16 09:52:33 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 09:52:33 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <wmvD5PIBqyFY17M6l9TZaB8a2lzSLvLYmBciPxV0Wcc=.dfdbcf47-7871-477e-8de3-c802c5b09eb1@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <wmvD5PIBqyFY17M6l9TZaB8a2lzSLvLYmBciPxV0Wcc=.dfdbcf47-7871-477e-8de3-c802c5b09eb1@github.com>
Message-ID: <DDGZKgAqdT9Th-qiVTcNPbh6JNob-poRlweE-PGPz5M=.d14b65c5-65c6-4a2c-90ce-4bd04fb6be9f@github.com>

On Mon, 16 Jun 2025 07:46:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - include a test for AsynchronousServerSocketChannel
>>  - System.err instead of System.out
>>  - trim down code comment
>>  -  > 200 instead of >= 200
>
> test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 43:
> 
>> 41:  * @run junit LargeBacklogTest
>> 42:  */
>> 43: class LargeBacklogTest {
> 
> How reliable is this test? If it is reliable then we can add tests for SocketChannelChannel::socket and AsynchronousServerSocket too.

I have run this test over a 1000 times in our CI and it hasn't failed even once. The test methods themselves complete in a few milli seconds:


SUCCESSFUL LargeBacklogTest::testServerSocket 'testServerSocket()' [180ms]
SUCCESSFUL LargeBacklogTest::testServerSocketChannel 'testServerSocketChannel()' [92ms]
SUCCESSFUL LargeBacklogTest::testAsynchronousServerSocketChannel 'testAsynchronousServerSocketChannel()' [88ms]

so the speed is good too. Plus, the test has been written in a manner where it allows a some leeway when asserting for the backlogged connection count for the cases where some unexpected process on the host might attempt a connection to this server. Given this, I think the test is reliable.

> If it is reliable then we can add tests for SocketChannelChannel::socket and AsynchronousServerSocket too.

I've update the PR to add one for `AsynchronousServerSocket`. It already had test for `ServerSocket` and `ServerSocketChannel`. As for `SocketChannelChannel::socket`, that appears to be a typo. Is there any other channel type you wanted to be tested too?

> test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 72:
> 
>> 70:     private static void testBackloggedConnects(final int backlog, final int serverPort) {
>> 71:         int numSuccessfulConnects = 0;
>> 72:         System.out.println("attempting " + backlog + " connections to port " + serverPort);
> 
> I don't know if this is a left over trace message or not. If intended then you might have to change it to use System.err so that it inlines with the test (at least I think JUnit uses System.err, TestNG uses System.out).

I hadn't paid attention to this detail, but yes you are right the junit logs - `STARTED ...`, `SUCCESSFUL ....`, `FAILED ...` appear on System.err. So yes, having these rest of the logs appear there would be a good thing. I have updated the PR to replace System.out with System.err.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149522443
PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149526743

From jpai at openjdk.org  Mon Jun 16 09:56:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 09:56:28 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <tZAI7iwjYd2ap6YNvWMHP5UoK51zC3pXsfv6om7X8xo=.b4866ec6-2e52-4e9e-a25d-b649fa6ad872@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Hello Michael,

> Are you sure that Windows does cap the value currently to SOMAXCONN, if the parameter is > 200?

Yes, I verified that part. In fact this current test reproduces that behaviour (by failing), if you undo the source code change in this PR. Anything above 200 backlogged connections results in the next attempt getting a connect failure exception. For example, running this test against JDK 24 on Windows results in:


...
connection 200 established Socket[addr=localhost/127.0.0.1,port=yyyy,localport=xxxx]
connection attempt 201 failed: java.net.ConnectException: Connection refused: connect
LargeBacklogTest$BackloggedServer at 3e7acc7e completed
stopping server ServerSocket[addr=localhost/127.0.0.1,localport=xxxx]
200 connections successfully established
Exception in thread "main" java.lang.AssertionError: expected at least 237 successful connections for a backlog of 242, but only 200 were successful
        at LargeBacklogTest.main(LargeBacklogTest.java:75)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-2975879184

From jpai at openjdk.org  Mon Jun 16 10:01:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 10:01:41 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
 <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
 <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>
Message-ID: <oQrwLDazrITNiLWjuJQcUmbKv2HhaYZHkVcFad44SAY=.15ece94e-f9d4-4c6f-ae27-2b8b3e655df9@github.com>

On Mon, 16 Jun 2025 09:49:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>  I was under the impression that shutting down the executor (i.e., interrupting the server handlers) would result in server releasing all acquired resources, including issuing a FIS::close.

It's not the `HttpServer` implementation which opens and closes these file descriptors. Instead it's the (application specific) request handlers - in this case it is the test specific `FileServerHandler` which knows which file to open and server and then close when done. It's done here https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/net/httpserver/FileServerHandler.java#L121. The `HttpServer` will not know of any resources that these application specific handlers would have opened.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149549035

From vyazici at openjdk.org  Mon Jun 16 10:22:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 10:22:30 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <oQrwLDazrITNiLWjuJQcUmbKv2HhaYZHkVcFad44SAY=.15ece94e-f9d4-4c6f-ae27-2b8b3e655df9@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
 <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
 <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>
 <oQrwLDazrITNiLWjuJQcUmbKv2HhaYZHkVcFad44SAY=.15ece94e-f9d4-4c6f-ae27-2b8b3e655df9@github.com>
Message-ID: <wIFH1wy7ME9syE6VHzHb-Ky-1YhSxCMgyliz86yOkps=.67885a54-78be-461a-afde-caf8a330c0a8@github.com>

On Mon, 16 Jun 2025 09:59:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> the issue here's isn't about not waiting for the tasks to complete. They in fact do complete. The actual issue is that the tasks have no way to know if the server side has actually done a `FileInputStream.close()` for the fixed length case
>> 
>> @jaikiran, `executor` is configured for the servers via `s1.setExecutor (executor)` and `s2.setExecutor (executor)` lines above. I was under the impression that shutting down the executor (i.e., interrupting the server handlers) would result in server releasing all acquired resources, including issuing a `FIS::close`. Was I mistaken?
>
>>  I was under the impression that shutting down the executor (i.e., interrupting the server handlers) would result in server releasing all acquired resources, including issuing a FIS::close.
> 
> It's not the `HttpServer` implementation which opens and closes these file descriptors. Instead it's the (application specific) request handlers - in this case it is the test specific `FileServerHandler` which knows which file to open and serve and then close when done. It's done here https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/net/httpserver/FileServerHandler.java#L121. The `HttpServer` will not know of any resources that these application specific handlers would have opened.

Thanks, now I see. Those resource usages in `FileServerHandler` should ideally be wrapped in try-with-resources, but that is out of the scope of this work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149593103

From jpai at openjdk.org  Mon Jun 16 10:26:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 10:26:31 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <wIFH1wy7ME9syE6VHzHb-Ky-1YhSxCMgyliz86yOkps=.67885a54-78be-461a-afde-caf8a330c0a8@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
 <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
 <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>
 <oQrwLDazrITNiLWjuJQcUmbKv2HhaYZHkVcFad44SAY=.15ece94e-f9d4-4c6f-ae27-2b8b3e655df9@github.com>
 <wIFH1wy7ME9syE6VHzHb-Ky-1YhSxCMgyliz86yOkps=.67885a54-78be-461a-afde-caf8a330c0a8@github.com>
Message-ID: <TevV1blZdPeGU0kPh-BwfUXbgb6i2_ecaONeuPr-vo8=.b54ef100-26fe-4d4d-9a9f-a73c54b74e85@github.com>

On Mon, 16 Jun 2025 10:19:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Those resource usages in FileServerHandler should ideally be wrapped in try-with-resources, but that is out of the scope of this work.

Agreed and I've put it in my TODO list. That won't fix this current issue though (I think you understand that, but just stating here for the sake of completeness).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149600398

From Shruthi.Shruthi1 at ibm.com  Mon Jun 16 05:53:46 2025
From: Shruthi.Shruthi1 at ibm.com (Shruthi .)
Date: Mon, 16 Jun 2025 05:53:46 +0000
Subject: Suggestion needed to port the fix to JDK17 and JDK11S
In-Reply-To: <0fc08923-09de-47d2-8b95-e4132df8a857@oracle.com>
References: <SJ0PR15MB4663E34342AC2F9AC8A876AACCFC2@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB46631AD45E4B42C4A39F008DCCC22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ef07a775-f954-4051-a0e9-59100c7715c3@oracle.com>
 <SJ0PR15MB46638A0DE787D32EFABAA8E1CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <ec39b10b-5271-41cf-aa7f-d3f915ee0a18@oracle.com>
 <SJ0PR15MB4663123A5C03544060DC27E9CCD52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <8861a349-6446-4326-b168-e9594aeef70b@oracle.com>
 <SJ0PR15MB4663C04ADCBC69EFEF78C71CCCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <d79fdfb8-e717-4c73-8c0c-3fae0fadce01@oracle.com>
 <SJ0PR15MB4663218DFB930F6B6EF9F211CCD22@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <a8254bdf-a678-4ceb-94d7-77253372101e@oracle.com>
 <SJ0PR15MB4663B9DE26624483CA466C4CCCB52@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB466351A414A67F29EC88EC19CC98A@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <SJ0PR15MB4663D5C27435718507DBA5C0CC60A@SJ0PR15MB4663.namprd15.prod.outlook.com>
 <0fc08923-09de-47d2-8b95-e4132df8a857@oracle.com>
Message-ID: <SJ0PR15MB46634E6B90E15ADB8381C1C0CC70A@SJ0PR15MB4663.namprd15.prod.outlook.com>

Hi Alan,

I ran the tests under java/nio and java/net against the JDK 17 build with the preClose re-order change to check for any regressions, and all tests passed successfully.

Three patches need to be ported to implement this fix in JDK 17 and to keep the source code aligned with the OpenJDK headstream.
* 8294399: (ch) Refactor some methods out of sun.nio.ch.UnixFileDispatcherImpl (https://github.com/openjdk/jdk/pull/10434)
* 8351458: (ch) Move preClose to UnixDispatcher (https://github.com/openjdk/jdk/pull/23956)
* 8317801: java/net/Socket/asyncClose/Race.java fails intermittently (aix) (https://bugs.openjdk.org/secure/attachment/113740/pending_signals.patch)

I have raised a backport PR in JDK17 for 8294399: (ch) Refactor some methods out of sun.nio.ch.UnixFileDispatcherImpl
https://github.com/openjdk/jdk17u-dev/pull/3631 - I have tagged you here. Can you please review

I have raised the OpenJDK headstream PR for 8317801: java/net/Socket/asyncClose/Race.java fails intermittently (aix)
https://github.com/openjdk/jdk/pull/25817 - I have tagged you here. Can you please review

Will proceed with the rest of the patches accordingly.

Thanks
Shruthi
________________________________
From: Alan Bateman <alan.bateman at oracle.com>
Sent: Sunday, June 8, 2025 10:52 PM
To: Shruthi . <Shruthi.Shruthi1 at ibm.com>; net-dev at openjdk.org <net-dev at openjdk.org>
Cc: Syed Moinudeen <smoinud1 at in.ibm.com>; SREENIVAS MAKINEEDI <sreeni at us.ibm.com>
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S

On 31/05/2025 20:?12, Shruthi . wrote: Hi Alan, I wanted to follow up on the update I shared earlier I?ve successfully backported the preClose re-order changes to JDK 17 and ran the Race.?java test case 500 times. It passed consistently without

On 31/05/2025 20:12, Shruthi . wrote:
Hi Alan,

I wanted to follow up on the update I shared earlier
I?ve successfully backported the preClose re-order changes to JDK 17 and ran the Race.java test case 500 times. It passed consistently without any failures. For validation, I also ran the test without the patch, and it failed on the first iteration. I ran the tests under java/nio to see if there is any regression and all the testcases are passing.
Currently, we are running the tests under java/net.

  *
Do you recommend running any additional test groups?
  *
Also, can we proceed with porting the preClose re-order fix to headstream?

Please let me know your thoughts.

Good to hear that the preClose changes helped. I think the next step is to create a PR for JDK main line.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250616/11ec9050/attachment-0001.htm>

From dfuchs at openjdk.org  Mon Jun 16 11:19:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Jun 2025 11:19:30 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <0J9FpqcZ0P2JZYQc1iCDL4EpTZez1vPJQObQOQaiIQE=.674a6bdd-5512-427f-8d3b-8fdebfea36ea@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 96:

> 94:                 // do not attempt any more connections
> 95:                 break;
> 96:             }

hmm... interesting: so we don't need to leave the socket open to increase the backlog. I guess the server side has to accept the socket and read the FIN, so the backlog won't be decremented until the socket is accepted (even if it's already closed on the client side).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2149696163

From dfuchs at openjdk.org  Mon Jun 16 11:31:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Jun 2025 11:31:32 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <TevV1blZdPeGU0kPh-BwfUXbgb6i2_ecaONeuPr-vo8=.b54ef100-26fe-4d4d-9a9f-a73c54b74e85@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
 <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
 <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>
 <oQrwLDazrITNiLWjuJQcUmbKv2HhaYZHkVcFad44SAY=.15ece94e-f9d4-4c6f-ae27-2b8b3e655df9@github.com>
 <wIFH1wy7ME9syE6VHzHb-Ky-1YhSxCMgyliz86yOkps=.67885a54-78be-461a-afde-caf8a330c0a8@github.com>
 <TevV1blZdPeGU0kPh-BwfUXbgb6i2_ecaONeuPr-vo8=.b54ef100-26fe-4d4d-9a9f-a73c54b74e85@github.com>
Message-ID: <rv_k-xAEv4iPiM3dmjVxMTaLGeJuhIoYz6rfm5icuug=.7c20e7fe-35bb-4a9c-ba89-736f86a1f2b8@github.com>

On Mon, 16 Jun 2025 10:23:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Thanks, now I see. Those resource usages in `FileServerHandler` should ideally be wrapped in try-with-resources, but that is out of the scope of this work.
>
>> Those resource usages in FileServerHandler should ideally be wrapped in try-with-resources, but that is out of the scope of this work.
> 
> Agreed and I've put it in my TODO list. That won't fix this current issue though (I think you understand that, but just stating here for the sake of completeness).

I believe that Volkan has a point - provided that FileServerHandler always eventually closes the file.

Each new request will be submitted to the executor by the HttpServer, therefore waiting for the executor to finish should ensure that FileServerHandler::handle has finished, and therefore that the the file has been closed.

Provided there's no rogue connection to the server...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149713777

From jpai at openjdk.org  Mon Jun 16 11:36:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 11:36:34 GMT
Subject: RFR: 8359477: com/sun/net/httpserver/Test12.java appears to have a
 temp file race [v3]
In-Reply-To: <rv_k-xAEv4iPiM3dmjVxMTaLGeJuhIoYz6rfm5icuug=.7c20e7fe-35bb-4a9c-ba89-736f86a1f2b8@github.com>
References: <TFWnJNJ65TIVGWzEp916x4MjwnM5dyCtriVNSv7XTro=.a9d18082-0ff6-4759-9e7d-f8ba5dae0ee5@github.com>
 <oIlwsCbYh-Hc__vg81dJsoFVvrEWT3LKYeeyk2Blw0Y=.0937b37f-2fa1-440c-92d2-cb02b6840553@github.com>
 <9agKzye4KhJwbb8t112mIgn9MQ-MbtMmB59WFPLeDaM=.d8e75572-0fb6-448e-b2d7-facfc7537751@github.com>
 <8tF2OJhGdDeL_0AF1Gr692zDpEas_itXc1MT_76O_EU=.6ef41626-dc0a-4973-80b6-7a02f38230f7@github.com>
 <OwaQnyDFkHnmHri5Ag5dM8F1wpTMI1zMcAJ1foMnQB8=.304aa382-ec4f-4d3a-ac68-a238a2721f69@github.com>
 <h3PTSn6glcRq4ItzHwZIBtCaE1LyO_SLu1Rh_A0H0AA=.033b007c-0be7-46bd-8909-f4f9a8792a62@github.com>
 <oQrwLDazrITNiLWjuJQcUmbKv2HhaYZHkVcFad44SAY=.15ece94e-f9d4-4c6f-ae27-2b8b3e655df9@github.com>
 <wIFH1wy7ME9syE6VHzHb-Ky-1YhSxCMgyliz86yOkps=.67885a54-78be-461a-afde-caf8a330c0a8@github.com>
 <TevV1blZdPeGU0kPh-BwfUXbgb6i2_ecaONeuPr-vo8=.b54ef100-26fe-4d4d-9a9f-a73c54b74e85@github.com>
 <rv_k-xAEv4iPiM3dmjVxMTaLGeJuhIoYz6rfm5icuug=.7c20e7fe-35bb-4a9c-ba89-736f86a1f2b8@github.com>
Message-ID: <DtC8QIjz8p2PIxFkQbXJ3dLkUZ0ZnifxLSJfAppj2gQ=.395751ec-d92a-409d-99c4-fbdc1d3f6020@github.com>

On Mon, 16 Jun 2025 11:27:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Each new request will be submitted to the executor by the HttpServer, therefore waiting for the executor to finish should ensure that FileServerHandler::handle has finished, and therefore that the the file has been closed.

That's a good point (both your and Volkan's). I missed this detail when Volkan mentioned it because I focused on the part which noted the server would close the file. I will experiment with this (or a different variant that I had in mind) since it looks like the preference is to let this delete calls stay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25820#discussion_r2149723378

From dfuchs at openjdk.org  Mon Jun 16 11:41:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Jun 2025 11:41:30 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v4]
In-Reply-To: <3L3ETIAc2JlLYbdRdvvDg01M5yv6VSKLmDVamwYtuBU=.1f7b1bf4-fffd-4f5d-b999-853c1a7325de@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <3L3ETIAc2JlLYbdRdvvDg01M5yv6VSKLmDVamwYtuBU=.1f7b1bf4-fffd-4f5d-b999-853c1a7325de@github.com>
Message-ID: <ZVXZdg2-5AtDj1qphftmynUKpBJENs0vHXTy3vzdJgM=.f7c388c5-cb66-4c5a-90ea-4c41e2430a91@github.com>

On Sun, 15 Jun 2025 04:41:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark's suggestion - use "connect timeout" instead of "connection timeout"
>  - Daniel's suggestion for the text

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2931736198

From michaelm at openjdk.org  Mon Jun 16 12:33:28 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 16 Jun 2025 12:33:28 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <2ivFB92u3k3eaQuSthSvIL1GEnaO1R4rMVPEvEOj3SQ=.bb15f523-505a-42fa-ba92-f8814916a687@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Just wondering also, what is the reason for the different backlog values in the different tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-2976477599

From dfuchs at openjdk.org  Mon Jun 16 12:49:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 16 Jun 2025 12:49:31 GMT
Subject: RFR: 8359223: HttpClient: Remove leftovers from the
 SecurityManager cleanup [v2]
In-Reply-To: <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>
References: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
 <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>
Message-ID: <LnEcdid5kGQ3v8AhwzVsNdVjeSymCUN9o3RnmOZL05U=.c57d1616-3a89-49cb-97bd-616ec56f4d81@github.com>

On Fri, 13 Jun 2025 07:55:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Removes following files added in [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) and are forgotten to be removed during the `SecurityManager`-removal ([JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228)):
>> 
>> 
>> test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java
>> test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java
>> 
>> 
>> Subsequently moved `test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java`, the only file remained in that folder, one level up.
>
> Volkan Yazici 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 three additional commits since the last revision:
> 
>  - Move `FilePublisherTest` one level up
>  - Merge remote-tracking branch 'upstream/master' into hcSmFollowUp
>  - Remove leftover tests from the SecurityManager cleanup

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25747#pullrequestreview-2932000969

From jpai at openjdk.org  Mon Jun 16 13:04:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 13:04:27 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <2ivFB92u3k3eaQuSthSvIL1GEnaO1R4rMVPEvEOj3SQ=.bb15f523-505a-42fa-ba92-f8814916a687@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <2ivFB92u3k3eaQuSthSvIL1GEnaO1R4rMVPEvEOj3SQ=.bb15f523-505a-42fa-ba92-f8814916a687@github.com>
Message-ID: <f-TT94DjtFDrkMV5fnNf6uYj5odmCNlhYcMai87lHNY=.b61c3b6c-84d0-461a-a7f4-3a77adb19f6e@github.com>

On Mon, 16 Jun 2025 12:31:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Just wondering also, what is the reason for the different backlog values in the different tests?

No specific reason, I just wanted to have the test use some arbitrary values above 200 - not too high and not too low. I can change it to use one specific value above 200, if that's preferable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-2976571003

From michaelm at openjdk.org  Mon Jun 16 13:48:27 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 16 Jun 2025 13:48:27 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <f-TT94DjtFDrkMV5fnNf6uYj5odmCNlhYcMai87lHNY=.b61c3b6c-84d0-461a-a7f4-3a77adb19f6e@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <2ivFB92u3k3eaQuSthSvIL1GEnaO1R4rMVPEvEOj3SQ=.bb15f523-505a-42fa-ba92-f8814916a687@github.com>
 <f-TT94DjtFDrkMV5fnNf6uYj5odmCNlhYcMai87lHNY=.b61c3b6c-84d0-461a-a7f4-3a77adb19f6e@github.com>
Message-ID: <ZNvPnNoMx2an7TREsHE2-pUUImvY7ENQRTzYYJs11oc=.308f20a2-64e5-4115-82c2-fb564557550f@github.com>

On Mon, 16 Jun 2025 13:01:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > Just wondering also, what is the reason for the different backlog values in the different tests?
> 
> No specific reason, I just wanted to have the test use some arbitrary values above 200 - not too high and not too low. I can change it to use one specific value above 200, if that's preferable.

No, that's fine as it is. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-2976728909

From duke at openjdk.org  Mon Jun 16 14:10:29 2025
From: duke at openjdk.org (p-nima)
Date: Mon, 16 Jun 2025 14:10:29 GMT
Subject: RFR: 8359223: HttpClient: Remove leftovers from the
 SecurityManager cleanup [v2]
In-Reply-To: <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>
References: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
 <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>
Message-ID: <wVLGyu99JK3REwkKagJ3LxONT7cEY8m34LVvTdPr39Q=.765b172e-4662-4f4d-8cf2-427625ead959@github.com>

On Fri, 13 Jun 2025 07:55:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Removes following files added in [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) and are forgotten to be removed during the `SecurityManager`-removal ([JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228)):
>> 
>> 
>> test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java
>> test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java
>> 
>> 
>> Subsequently moved `test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java`, the only file remained in that folder, one level up.
>
> Volkan Yazici 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 three additional commits since the last revision:
> 
>  - Move `FilePublisherTest` one level up
>  - Merge remote-tracking branch 'upstream/master' into hcSmFollowUp
>  - Remove leftover tests from the SecurityManager cleanup

Please correct me if I am wrong, as per my understanding it is essential to test a custom provider (in this case SecureZipFSProvider), as the path would be dependent on the provider, and is not related to the security manager - [docs](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L280)

-------------

Changes requested by p-nima at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/25747#pullrequestreview-2932294202

From alanb at openjdk.org  Mon Jun 16 14:50:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Jun 2025 14:50:34 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <yrOqvrky2tyHVs0mFOv14Ru-VDJWMR1v3qx0cVhvZzc=.64d1fdba-e1b2-431b-b852-211aa20dae0c@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

src/java.base/windows/native/libnio/ch/Net.c line 223:

> 221:     if (backlog > 200) {
> 222:         backlog = SOMAXCONN_HINT(backlog);
> 223:     }

This looks okay now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2150201135

From jpai at openjdk.org  Mon Jun 16 16:31:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 16 Jun 2025 16:31:29 GMT
Subject: RFR: 8359402: TesCloseDescriptors.java should throw
 SkippedException when there is no lsof/sctp
In-Reply-To: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
References: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
Message-ID: <pd9U7HGaqn-vHXLgdXy9OfqkU29cq_0PNcuuOObhv_w=.d5ef404b-75b1-4853-82e1-704a8ef9c73b@github.com>

On Fri, 13 Jun 2025 06:36:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw jtreg.SkippedException when there is no lsof command or there is no SCTP in test machine.
> Before this PR, this test report Execution successful when there is no SCTP.
> 
> 
> --------------------------------------------------
> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
> TEST RESULT: Passed. Execution successful
> --------------------------------------------------
> 
> 
> After this PR, it will report `jtreg.SkippedException` when there is no SCTP
> 
> 
> --------------------------------------------------
> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
> TEST RESULT: Passed. Skipped: jtreg.SkippedException: SCTP protocol is not supported
> --------------------------------------------------
> 
> 
> Change has been verified locally, test-fix only, no risk.

This test-only change looks reasonable to me. I've fixed a typo in the JBS issue title, so you will have to fix this PR title too.
Before integrating it would be good to verify that this test continues to be executed on a setup where SCTP is present and lsof is present. I'll run this in our CI tomorrow to verify this works as expected.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25790#pullrequestreview-2932786671

From vyazici at openjdk.org  Mon Jun 16 18:19:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 18:19:29 GMT
Subject: RFR: 8359223: HttpClient: Remove leftovers from the
 SecurityManager cleanup [v2]
In-Reply-To: <wVLGyu99JK3REwkKagJ3LxONT7cEY8m34LVvTdPr39Q=.765b172e-4662-4f4d-8cf2-427625ead959@github.com>
References: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
 <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>
 <wVLGyu99JK3REwkKagJ3LxONT7cEY8m34LVvTdPr39Q=.765b172e-4662-4f4d-8cf2-427625ead959@github.com>
Message-ID: <s8zaqujK_Z7VyHjlcIHICJJBr0qaYAHrXx16LoP6zg4=.020abc40-344c-4257-99c0-0e3dbcc240f7@github.com>

On Mon, 16 Jun 2025 14:07:57 GMT, p-nima <duke at openjdk.org> wrote:

> as the path would be dependent on the provider

Correct, a `Path` implementation depends on the `FileSystem` implementation. Except _"the default file system"_, obtained by invoking [`FileSystems::getDefault`](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/FileSystems.html#getDefault()), `Path::toFile` method of the associated `Path` implementation is _expected_ to throw `UnsupportedOperationException` ? see [the `Path::toFile` specification for details](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()). 

> it is essential to test a custom provider (in this case SecureZipFSProvider)

`HttpRequest.BodyPublishers#ofFile(Path)` was not working when the `Path` provided is associated with a file system that does not support `Path::toFile`, i.e., throwing `UnsupportedOperationException` on `Path::toFile`. [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) addresses this issue. The fix also contains tests covering all following file systems:

1. The default file system (`Path::toFile` actually works, but gets tested to verify)
2. `ZipFileSystem` (`Path::toFile` is not supported)
3. `SecureZipFS` (a `ZipFileSystem` wrapper regulating access via `SecurityManager`)

`SecurityManager` was removed in [JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228), yet `SecureZipFS` was stripped from `SecurityManager`-related calls. In this PR, we're doing what should have been done instead: deleting it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25747#issuecomment-2977585177

From vyazici at openjdk.org  Mon Jun 16 18:23:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 18:23:33 GMT
Subject: RFR: 8359223: HttpClient: Remove leftovers from the
 SecurityManager cleanup [v2]
In-Reply-To: <LnEcdid5kGQ3v8AhwzVsNdVjeSymCUN9o3RnmOZL05U=.c57d1616-3a89-49cb-97bd-616ec56f4d81@github.com>
References: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
 <dclqMSjFABA7_mCIXXEWMYiFUjffnJ3juzhmBrHRWkM=.4054d573-bf35-4a87-89c1-64249ce0a668@github.com>
 <LnEcdid5kGQ3v8AhwzVsNdVjeSymCUN9o3RnmOZL05U=.c57d1616-3a89-49cb-97bd-616ec56f4d81@github.com>
Message-ID: <MCN29o3724H2LizRt71HvdJYDohElCjPFfs3tWslwEE=.8b852dd6-7e99-48b5-bb93-92da08f99f94@github.com>

On Mon, 16 Jun 2025 12:47:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici 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 three additional commits since the last revision:
>> 
>>  - Move `FilePublisherTest` one level up
>>  - Merge remote-tracking branch 'upstream/master' into hcSmFollowUp
>>  - Remove leftover tests from the SecurityManager cleanup
>
> Marked as reviewed by dfuchs (Reviewer).

@dfuch, thanks so much for reviewing the changes, much appreciated. :bowing_man:

Successful CI run results are attached to the ticket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25747#issuecomment-2977593973

From vyazici at openjdk.org  Mon Jun 16 18:23:33 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 16 Jun 2025 18:23:33 GMT
Subject: Integrated: 8359223: HttpClient: Remove leftovers from the
 SecurityManager cleanup
In-Reply-To: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
References: <9pNK1bsbx7Xw8B5G8FbxQI6k4tX5Idk8-iIgIu_NqlI=.3b9a3f17-4aee-4a4a-a70e-67604ab2a26f@github.com>
Message-ID: <0ol371gpaeSH3iAI4NSPx59TuLIoA3SDbn8QlMvuqSU=.f23c0197-0648-47c9-90db-9914cf35901b@github.com>

On Wed, 11 Jun 2025 11:05:13 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Removes following files added in [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) and are forgotten to be removed during the `SecurityManager`-removal ([JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228)):
> 
> 
> test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java
> test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java
> 
> 
> Subsequently moved `test/jdk/java/net/httpclient/FilePublisher/FilePublisherTest.java`, the only file remained in that folder, one level up.

This pull request has now been integrated.

Changeset: e55ddabf
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e55ddabffa90e28d22f546b387007fe4e434c3e0
Stats:     701 lines in 3 files changed: 0 ins; 701 del; 0 mod

8359223: HttpClient: Remove leftovers from the SecurityManager cleanup

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25747

From philip.race at oracle.com  Mon Jun 16 18:48:49 2025
From: philip.race at oracle.com (Philip Race)
Date: Mon, 16 Jun 2025 11:48:49 -0700
Subject: java.net.URLConnection.getContent()
In-Reply-To: <a7989e6c-21ac-410b-aa8f-738be4518564@oracle.com>
References: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>
 <4b902adf-f050-49dd-8402-f2115ffa8533@oracle.com>
 <9d8276b3-5a9a-4016-bec8-f0b904bcd74d@oracle.com>
 <a7989e6c-21ac-410b-aa8f-738be4518564@oracle.com>
Message-ID: <c64ea4b0-ccda-49b9-acb1-66a925f9c997@oracle.com>


 >A migration from AudioClip to SoundClip would require all usages to 
change too.
 >I think for now that it should be okay to just the mapping from 
MultimediaContentHandlers so that it returns null.

For clarity, this handler/provider returning null does not mean that 
null is what is returned to the application.
I haven't completely traced it, but it looks like the java.net 
implementation will fall back to returning the
content as a stream of bytes.

 From what I have found so far, MultimediaContentHandlers returning any 
of null, an internal class,
a new external class would be OK for the audio cases.
This is because we don't have any internal JDK code, or JCK tests that 
reply on this.
Well .. we do have two regression tests, but because they used 
(expected) AudioClip they've
been migrated to use SoundClip as part of the Applet API removal.

However if I did the same for any of the image types, we'd have failures 
of all the above cases.
The java.beans implementation uses it .

For the audio cases, if I return SoundClip it is possible for 
application code to migrate,
just as I did for the two regression tests. But if I return null, they 
have a bigger migration issue.

Perhaps? even if these APIs still have a use for applications which 
install their own handlers and
so have knowledge about it.

For applications that expect an ImageProducer, or an AudioClip, they 
must have worked out
what to expect by inspection - and this is going back to JDK 1.0 / 1.1 days

The docs have always (since 1.0) said
'The|instanceOf|operation should be used to determine the specific kind 
of object returned.'

Perhaps we can consider deprecating [*] (and later removing) the 
MultimediaContentHandlers ?
After all if you have a jlinked image w/o the desktop module, you'll not 
be able to us them anyway.

[* I've no idea how you publicly deprecate an internal SPI provider.]


-phil.

On 6/15/25 11:26 AM, Alan Bateman wrote:
> On 15/06/2025 17:33, Philip Race wrote:
>> Perhaps these APIs should be deprecated (for removal) ?
>
> Maybe but would require a lot of analysis to understand impact as 
> there are several ways to configure content handlers and there are 
> stream handlers that exist outside of the JDK that might interact with 
> this. It's also very possible that there are usages that just assume 
> an InputStream.
>
>>
>> For 30 years, AudioClip has been the only public type that this API 
>> returned for audio data.
>> Clearly that won't be possible after it is removed.
>>
>> SoundClip is the replacement for public uses of AudioClip so it is 
>> the obvious replacement.
>> And I can without too much work return a SoundClip, and that offers 
>> the same migration path
>> as for direct API uses of AudioClip, so may be it is the best short 
>> term thing, whilst a longer term
>> deprecation is worked out ?
>
> A migration from AudioClip to SoundClip would require all usages to 
> change too. I think for now that it should be okay to just the mapping 
> from MultimediaContentHandlers so that it returns null.
>
> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250616/f94b40fc/attachment-0001.htm>

From syan at openjdk.org  Tue Jun 17 02:36:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 02:36:29 GMT
Subject: RFR: 8359402: Test CloseDescriptors.java should throw
 SkippedException when there is no lsof/sctp
In-Reply-To: <pd9U7HGaqn-vHXLgdXy9OfqkU29cq_0PNcuuOObhv_w=.d5ef404b-75b1-4853-82e1-704a8ef9c73b@github.com>
References: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
 <pd9U7HGaqn-vHXLgdXy9OfqkU29cq_0PNcuuOObhv_w=.d5ef404b-75b1-4853-82e1-704a8ef9c73b@github.com>
Message-ID: <WLKSJxvZN04GmpSxH0jJre9cgp3FVGTPg8kav9XzqQY=.57017118-8fdc-4153-abc0-7891f826c4c6@github.com>

On Mon, 16 Jun 2025 16:29:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi all,
>> 
>> Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw jtreg.SkippedException when there is no lsof command or there is no SCTP in test machine.
>> Before this PR, this test report Execution successful when there is no SCTP.
>> 
>> 
>> --------------------------------------------------
>> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
>> TEST RESULT: Passed. Execution successful
>> --------------------------------------------------
>> 
>> 
>> After this PR, it will report `jtreg.SkippedException` when there is no SCTP
>> 
>> 
>> --------------------------------------------------
>> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
>> TEST RESULT: Passed. Skipped: jtreg.SkippedException: SCTP protocol is not supported
>> --------------------------------------------------
>> 
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> This test-only change looks reasonable to me. I've fixed a typo in the JBS issue title, so you will have to fix this PR title too.
> Before integrating it would be good to verify that this test continues to be executed on a setup where SCTP is present and lsof is present. I'll run this in our CI tomorrow to verify this works as expected.

Thanks @jaikiran 

I have executed this test on a setup where SCTP is present and lsof is present, but it will report failures which has been recorded by https://bugs.openjdk.org/browse/JDK-8298466. I think the test failure is unrelated to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25790#issuecomment-2978731896

From jpai at openjdk.org  Tue Jun 17 04:12:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 04:12:28 GMT
Subject: RFR: 8359402: Test CloseDescriptors.java should throw
 SkippedException when there is no lsof/sctp
In-Reply-To: <WLKSJxvZN04GmpSxH0jJre9cgp3FVGTPg8kav9XzqQY=.57017118-8fdc-4153-abc0-7891f826c4c6@github.com>
References: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
 <pd9U7HGaqn-vHXLgdXy9OfqkU29cq_0PNcuuOObhv_w=.d5ef404b-75b1-4853-82e1-704a8ef9c73b@github.com>
 <WLKSJxvZN04GmpSxH0jJre9cgp3FVGTPg8kav9XzqQY=.57017118-8fdc-4153-abc0-7891f826c4c6@github.com>
Message-ID: <aBQYrjIPFQOmA2lOnT0dZwyb1NwTj2muEzMBtGHe6eo=.7dee8c95-6345-4d64-82fa-7c72b77766b6@github.com>

On Tue, 17 Jun 2025 02:33:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> This test-only change looks reasonable to me. I've fixed a typo in the JBS issue title, so you will have to fix this PR title too.
>> Before integrating it would be good to verify that this test continues to be executed on a setup where SCTP is present and lsof is present. I'll run this in our CI tomorrow to verify this works as expected.
>
> Thanks @jaikiran 
> 
> I have executed this test on a setup where SCTP is present and lsof is present, but it will report failures which has been recorded by https://bugs.openjdk.org/browse/JDK-8298466. I think the test failure is unrelated to this PR.

Hello @sendaoYan, thank you for verifying. I have checked in our CI too and this test continues to get executed where SCTP is supported and lsof is present. That's a good thing. You can go ahead with the integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25790#issuecomment-2978863181

From syan at openjdk.org  Tue Jun 17 05:41:33 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 05:41:33 GMT
Subject: RFR: 8359402: Test CloseDescriptors.java should throw
 SkippedException when there is no lsof/sctp
In-Reply-To: <aBQYrjIPFQOmA2lOnT0dZwyb1NwTj2muEzMBtGHe6eo=.7dee8c95-6345-4d64-82fa-7c72b77766b6@github.com>
References: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
 <pd9U7HGaqn-vHXLgdXy9OfqkU29cq_0PNcuuOObhv_w=.d5ef404b-75b1-4853-82e1-704a8ef9c73b@github.com>
 <WLKSJxvZN04GmpSxH0jJre9cgp3FVGTPg8kav9XzqQY=.57017118-8fdc-4153-abc0-7891f826c4c6@github.com>
 <aBQYrjIPFQOmA2lOnT0dZwyb1NwTj2muEzMBtGHe6eo=.7dee8c95-6345-4d64-82fa-7c72b77766b6@github.com>
Message-ID: <JxLWWylBzudBCYQZp1cCd-Ri5ujtXc-Tbi-u7hgaO84=.15d0f8f7-dff8-4276-90f9-4aaae520e141@github.com>

On Tue, 17 Jun 2025 04:09:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Thanks @jaikiran 
>> 
>> I have executed this test on a setup where SCTP is present and lsof is present, but it will report failures which has been recorded by https://bugs.openjdk.org/browse/JDK-8298466. I think the test failure is unrelated to this PR.
>
> Hello @sendaoYan, thank you for verifying. I have checked in our CI too and this test continues to get executed where SCTP is supported and lsof is present. That's a good thing. You can go ahead with the integration.

Thanks for the verify and reviews @jaikiran 
Thanks for the review @vy

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25790#issuecomment-2979008246

From syan at openjdk.org  Tue Jun 17 05:41:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 05:41:34 GMT
Subject: Integrated: 8359402: Test CloseDescriptors.java should throw
 SkippedException when there is no lsof/sctp
In-Reply-To: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
References: <F9DG6HnxKZxPMn6NpRlix-lBvbWZmfE-9jIBD_kggi4=.38c60e50-63a9-4975-a30c-0ce25976de96@github.com>
Message-ID: <Ii-BW1rIjpIo3bYbwLV3eN3BSEQvBv8SCMluMmFvKzk=.7733940b-0137-4e7e-adc5-d01874f06835@github.com>

On Fri, 13 Jun 2025 06:36:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw jtreg.SkippedException when there is no lsof command or there is no SCTP in test machine.
> Before this PR, this test report Execution successful when there is no SCTP.
> 
> 
> --------------------------------------------------
> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
> TEST RESULT: Passed. Execution successful
> --------------------------------------------------
> 
> 
> After this PR, it will report `jtreg.SkippedException` when there is no SCTP
> 
> 
> --------------------------------------------------
> TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java
> TEST RESULT: Passed. Skipped: jtreg.SkippedException: SCTP protocol is not supported
> --------------------------------------------------
> 
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: a16d2355
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a16d23557b101504ed2ff95cf1a3c5ba11afe33d
Stats:     9 lines in 1 file changed: 2 ins; 4 del; 3 mod

8359402: Test CloseDescriptors.java should throw SkippedException when there is no lsof/sctp

Reviewed-by: vyazici, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/25790

From alan.bateman at oracle.com  Tue Jun 17 06:34:43 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Jun 2025 07:34:43 +0100
Subject: java.net.URLConnection.getContent()
In-Reply-To: <c64ea4b0-ccda-49b9-acb1-66a925f9c997@oracle.com>
References: <09551ad6-5825-4e5b-a2a4-3a64ef26880f@oracle.com>
 <4b902adf-f050-49dd-8402-f2115ffa8533@oracle.com>
 <9d8276b3-5a9a-4016-bec8-f0b904bcd74d@oracle.com>
 <a7989e6c-21ac-410b-aa8f-738be4518564@oracle.com>
 <c64ea4b0-ccda-49b9-acb1-66a925f9c997@oracle.com>
Message-ID: <2e6b6f33-7e46-42a1-b32a-c846dc6e5f83@oracle.com>

On 16/06/2025 19:48, Philip Race wrote:
>
> >A migration from AudioClip to SoundClip would require all usages to 
> change too.
> >I think for now that it should be okay to just the mapping from 
> MultimediaContentHandlers so that it returns null.
>
> For clarity, this handler/provider returning null does not mean that 
> null is what is returned to the application.
> I haven't completely traced it, but it looks like the java.net 
> implementation will fall back to returning the
> content as a stream of bytes.

Right, a ContentHandler can return null but the 
URLConnection::getContent API always returns something when content can 
be fetch from the URL. URLConnection.UnknownContentHandler is the lender 
of last resort.


>
> For the audio cases, if I return SoundClip it is possible for 
> application code to migrate,
> just as I did for the two regression tests. But if I return null, they 
> have a bigger migration issue.

I agree that returning a SoundClip gives a migration path, it's more 
defensible than not mapping.



>
> Perhaps? even if these APIs still have a use for applications which 
> install their own handlers and
> so have knowledge about it.
>
> For applications that expect an ImageProducer, or an AudioClip, they 
> must have worked out
> what to expect by inspection - and this is going back to JDK 1.0 / 1.1 
> days
>
> The docs have always (since 1.0) said
> 'The|instanceOf|operation should be used to determine the specific 
> kind of object returned.'
>
> Perhaps we can consider deprecating [*] (and later removing) the 
> MultimediaContentHandlers ?
> After all if you have a jlinked image w/o the desktop module, you'll 
> not be able to us them anyway.

In the jlink case, you'd have to include java.desktop if the 
application, or a library, has a static depending on java.awt.image.* 
types. So yes, you would get different behavior depending on whether the 
java.desktop module is in the run-time image but only if the application 
isn't using instanceof.

No objection if we try to work towards dropping these mappings, just not 
clear how much testing there is with EA builds to shake out any common 
usages that we can't think of.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250617/7d8d63cf/attachment.htm>

From jpai at openjdk.org  Tue Jun 17 07:05:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 07:05:07 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190
Message-ID: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>

Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.

When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.

Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.

The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.

I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.

The

-------------

Commit messages:
 - 8359709: java.net.HttpURLConnection sends unexpected "Host" request header in some cases after JDK-8344190
 - 8359709: introduce a test

Changes: https://git.openjdk.org/jdk/pull/25844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359709
  Stats: 145 lines in 2 files changed: 143 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25844/head:pull/25844

PR: https://git.openjdk.org/jdk/pull/25844

From alanb at openjdk.org  Tue Jun 17 07:27:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jun 2025 07:27:34 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v4]
In-Reply-To: <3L3ETIAc2JlLYbdRdvvDg01M5yv6VSKLmDVamwYtuBU=.1f7b1bf4-fffd-4f5d-b999-853c1a7325de@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <3L3ETIAc2JlLYbdRdvvDg01M5yv6VSKLmDVamwYtuBU=.1f7b1bf4-fffd-4f5d-b999-853c1a7325de@github.com>
Message-ID: <Xk1NX75_4aPS0dFXYNEoSsvlfTSPKBYuRTAGQ6MxBbQ=.3c041d31-ac36-4b74-ad83-cc4f2cda1dca@github.com>

On Sun, 15 Jun 2025 04:41:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark's suggestion - use "connect timeout" instead of "connection timeout"
>  - Daniel's suggestion for the text

src/java.base/share/classes/java/net/Socket.java line 629:

> 627:      * {@code timeout} specified to this method then an {@code IOException} is thrown.
> 628:      * The {@code timeout} specified to this method is typically a timeout value that is
> 629:      * shorter than the operating system timeout.

The previous version was a bit clearer but this version is okay too. You might want to consider "is in the range of tens of seconds to ..." rather than "ranges within tens of seconds to ..".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2151522882

From vyazici at openjdk.org  Tue Jun 17 07:38:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 17 Jun 2025 07:38:27 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190
In-Reply-To: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
Message-ID: <8o_WIP6-j9lOz9jZbqJDNOzWJsyBS1e8KO0LYE3JidI=.5f66a945-fef9-484b-ad59-02cf7b2bb907@github.com>

On Tue, 17 Jun 2025 06:55:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
> 
> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
> 
> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
> 
> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.

Marked as reviewed by vyazici (Committer).

test/jdk/java/net/HttpURLConnection/HostHeaderTest.java line 68:

> 66:         final InetSocketAddress addr = new InetSocketAddress(InetAddress.getLoopbackAddress(), 0);
> 67:         server = HttpServer.create(addr, 0);
> 68:         server.createContext("/", new Handler());

I think it might be a good idea to salt the handler path a bit (e.g., with the class name) to avoid unexpected connections from tests running in parallel.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25844#pullrequestreview-2934464465
PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2151532528

From jpai at openjdk.org  Tue Jun 17 08:31:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 08:31:30 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190
In-Reply-To: <8o_WIP6-j9lOz9jZbqJDNOzWJsyBS1e8KO0LYE3JidI=.5f66a945-fef9-484b-ad59-02cf7b2bb907@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <8o_WIP6-j9lOz9jZbqJDNOzWJsyBS1e8KO0LYE3JidI=.5f66a945-fef9-484b-ad59-02cf7b2bb907@github.com>
Message-ID: <vX4PFeGn-sTXlCkDm1YoXweqZ4cLH36y6oeo1MAm9vA=.eff57760-200d-40fc-ad8a-67796e905100@github.com>

On Tue, 17 Jun 2025 07:29:23 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> test/jdk/java/net/HttpURLConnection/HostHeaderTest.java line 68:
> 
>> 66:         final InetSocketAddress addr = new InetSocketAddress(InetAddress.getLoopbackAddress(), 0);
>> 67:         server = HttpServer.create(addr, 0);
>> 68:         server.createContext("/", new Handler());
> 
> I think it might be a good idea to salt the handler path a bit (e.g., with the class name) to avoid unexpected connections from tests running in parallel.

Hello Volkan, the server handler in this test is implemented to allow more than one request during its lifetime. So any unexpected requests from other processes would still allow this test to be unaffected by those requests. Did I misunderstand your suggestion for registering the handler to a test specific context?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2151656856

From jpai at openjdk.org  Tue Jun 17 08:34:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 08:34:37 GMT
Subject: RFR: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte) [v3]
In-Reply-To: <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
 <c-WFuFIED56QxSBaFv-HXYgn5LsJy5nQ7u-bWzT-WVA=.b7b03730-1b72-4ab5-aa6d-d224849cc0bd@github.com>
Message-ID: <bKI16GBTLWSmEeVpRZmMCTsTd6h8BYz7OZIb12pxbU0=.f8d43d68-1175-4729-9c7d-3d6ec5acb9b9@github.com>

On Wed, 11 Jun 2025 12:07:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
>> 
>> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
>> 
>> 
>> public void setTTL(byte ttl) throws IOException
>> public byte getTTL() throws IOException
>> 
>> 
>> and this other one on `MulticastSocket`:
>> 
>> 
>> public void send(DatagramPacket p, byte ttl) throws IOException 
>> 
>> 
>> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
>> 
>> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
>> 
>> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's review - continue to test MulticastSocket in SendCheck

The CSR has been approved and tier1, tier2 and tier3 tests continue to pass with this change. Thank you Alan and Daniel for the reviews. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25744#issuecomment-2979441579

From jpai at openjdk.org  Tue Jun 17 08:34:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 08:34:38 GMT
Subject: Integrated: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
In-Reply-To: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
References: <ztZvBIWUu90vBMDLVMsxFRkWsVNkqDd95djkmiFVdXw=.082787d5-a275-4979-a9de-6c840543f93f@github.com>
Message-ID: <p8QJ2kVMdejDjcgLe8X_VDqxNndqKOYwpv4n31d3w3c=.7c32e7e5-f4c5-4ea5-aa62-dab333420605@github.com>

On Wed, 11 Jun 2025 10:05:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove the deprecated-for-removal methods from `MulticastSocket` and `DatagramSocketImpl`? 
> 
> The following methods on `java.net.MulticastSocket` and `java.net.DatagramSocketImpl`:
> 
> 
> public void setTTL(byte ttl) throws IOException
> public byte getTTL() throws IOException
> 
> 
> and this other one on `MulticastSocket`:
> 
> 
> public void send(DatagramPacket p, byte ttl) throws IOException 
> 
> 
> have been deprecated for removal since Java 23, through https://bugs.openjdk.org/browse/JDK-8332181. Even before that they have been deprecated since Java 1.2 and Java 1.4.
> 
> The commit in this PR removes them completely. This PR also removes some tests that were specifically testing the `setTTL()/getTTL()/send(DatagramPacket, byte)` methods. A few other tests have been adjusted to use the alternate `getTimeToLive()/setTimeToLive()` methods where appropriate.
> 
> Existing tests in tier1, tier2 and tier3 continue to pass with these changes.

This pull request has now been integrated.

Changeset: f7cd3fad
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7cd3fad2400cd3a07d8a3a44d86d5dc4d23913e
Stats:     445 lines in 19 files changed: 0 ins; 420 del; 25 mod

8332623: Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket, byte)

Reviewed-by: dfuchs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25744

From jpai at openjdk.org  Tue Jun 17 08:40:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 08:40:10 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v5]
In-Reply-To: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
Message-ID: <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>

> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
> 
> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
> 
> If this requires a CSR, I'll open one once we settle on the proposed text.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25690/files
  - new: https://git.openjdk.org/jdk/pull/25690/files/381919bd..d78f08f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25690.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25690/head:pull/25690

PR: https://git.openjdk.org/jdk/pull/25690

From jpai at openjdk.org  Tue Jun 17 08:40:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 08:40:10 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v2]
In-Reply-To: <-JZRG2bNPZc17ewJehHJMuDnWxgVC1sbsxVz8AafNG0=.31d12218-6d28-404e-bcd7-ab995bdc3f19@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <H2ChOKqw3nLvycyoRYl95NOkmBTIStTnn19fENqZ3Ek=.495985f6-fe74-47cd-bc5c-82408a38c8b0@github.com>
 <rg-LLrsB8WaBWJUCepNPsolk7mFFpOclG29o_9oY-e4=.2fe483fb-f480-4867-a345-53413201c5c4@github.com>
 <-JZRG2bNPZc17ewJehHJMuDnWxgVC1sbsxVz8AafNG0=.31d12218-6d28-404e-bcd7-ab995bdc3f19@github.com>
Message-ID: <_8og3JUzk0ViW7bNx5nWfIIYw1UeTWe0LfMWtjzQ-ic=.6059d45f-3843-47ae-a73f-9bf33ababd7e@github.com>

On Wed, 11 Jun 2025 18:31:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The CSR is now ready for review https://bugs.openjdk.org/browse/JDK-8359249
> 
> It's okay to have a CSR but no usually needed for API notes.

Noted. For this one, I'll go ahead and finalize the already filed CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25690#issuecomment-2979458419

From jpai at openjdk.org  Tue Jun 17 08:40:11 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 08:40:11 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v4]
In-Reply-To: <Xk1NX75_4aPS0dFXYNEoSsvlfTSPKBYuRTAGQ6MxBbQ=.3c041d31-ac36-4b74-ad83-cc4f2cda1dca@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <3L3ETIAc2JlLYbdRdvvDg01M5yv6VSKLmDVamwYtuBU=.1f7b1bf4-fffd-4f5d-b999-853c1a7325de@github.com>
 <Xk1NX75_4aPS0dFXYNEoSsvlfTSPKBYuRTAGQ6MxBbQ=.3c041d31-ac36-4b74-ad83-cc4f2cda1dca@github.com>
Message-ID: <MtScWxTMJNCfgiHhK5P4z-H5UYd_sPY-iipwonCsP8A=.0c1f71fc-4b39-4858-b5c1-ae63539cba6c@github.com>

On Tue, 17 Jun 2025 07:24:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Mark's suggestion - use "connect timeout" instead of "connection timeout"
>>  - Daniel's suggestion for the text
>
> src/java.base/share/classes/java/net/Socket.java line 629:
> 
>> 627:      * {@code timeout} specified to this method then an {@code IOException} is thrown.
>> 628:      * The {@code timeout} specified to this method is typically a timeout value that is
>> 629:      * shorter than the operating system timeout.
> 
> The previous version was a bit clearer but this version is okay too. You might want to consider "is in the range of tens of seconds to ..." rather than "ranges within tens of seconds to ..".

Done, I've updated the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2151672649

From vyazici at openjdk.org  Tue Jun 17 08:54:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 17 Jun 2025 08:54:29 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190
In-Reply-To: <vX4PFeGn-sTXlCkDm1YoXweqZ4cLH36y6oeo1MAm9vA=.eff57760-200d-40fc-ad8a-67796e905100@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <8o_WIP6-j9lOz9jZbqJDNOzWJsyBS1e8KO0LYE3JidI=.5f66a945-fef9-484b-ad59-02cf7b2bb907@github.com>
 <vX4PFeGn-sTXlCkDm1YoXweqZ4cLH36y6oeo1MAm9vA=.eff57760-200d-40fc-ad8a-67796e905100@github.com>
Message-ID: <J4kfMxPx4hejBEytuGpcxGO7CQ6xXDgvsp6F6XbCkQ4=.33324e07-09ee-4ac2-9a12-146b24600616@github.com>

On Tue, 17 Jun 2025 08:28:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So any unexpected requests from other processes would still allow this test to be unaffected by those requests.

Yes, _this test_ will not be affected, but the other test _might_. Consider a test running in parallel, unexpectedly connecting to `HostHeaderTest`'s server, and it is

1. either not expecting a response at all
2. or not expecting the response returned from the `HostHeaderTest`'s handler

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2151706477

From michaelm at openjdk.org  Tue Jun 17 09:25:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 17 Jun 2025 09:25:31 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <tFVdldQf07atD5KlOYQ4TPiX6Dsa7QzOrww_L8O0-II=.f524f6bf-8e85-4e04-9d1a-c6e2415dfc64@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Looks fine to me

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25819#pullrequestreview-2934871277

From jpai at openjdk.org  Tue Jun 17 09:28:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 09:28:29 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <0J9FpqcZ0P2JZYQc1iCDL4EpTZez1vPJQObQOQaiIQE=.674a6bdd-5512-427f-8d3b-8fdebfea36ea@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <0J9FpqcZ0P2JZYQc1iCDL4EpTZez1vPJQObQOQaiIQE=.674a6bdd-5512-427f-8d3b-8fdebfea36ea@github.com>
Message-ID: <LLrH_1nc3-5wLLQk1VAUoKJAK11YCT4bST0iE1HISao=.4b47ae2a-d4a0-476a-a10c-baa4c7014d42@github.com>

On Mon, 16 Jun 2025 11:16:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - include a test for AsynchronousServerSocketChannel
>>  - System.err instead of System.out
>>  - trim down code comment
>>  -  > 200 instead of >= 200
>
> test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 96:
> 
>> 94:                 // do not attempt any more connections
>> 95:                 break;
>> 96:             }
> 
> hmm... interesting: so we don't need to leave the socket open to increase the backlog. I guess the server side has to accept the socket and read the FIN, so the backlog won't be decremented until the socket is accepted (even if it's already closed on the client side).

That's a good question. The current behaviour (on Windows and *nix) is that, closing the Socket which initiated the connection doesn't affect the number of connections that were put into a pending queue (backlog) on the server side. I will need to read up a bit to see if that is specified or if it is merely an implementation detail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2151785668

From alanb at openjdk.org  Tue Jun 17 10:39:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Jun 2025 10:39:28 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v5]
In-Reply-To: <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>
Message-ID: <aaWKye3y3a-os5NdDj3Gipe-As-jmoATiDt7AqMwQMk=.5924e32f-204e-48c4-93af-fde07ed73a0a@github.com>

On Tue, 17 Jun 2025 08:40:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2935117330

From dfuchs at openjdk.org  Tue Jun 17 13:36:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Jun 2025 13:36:28 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190
In-Reply-To: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
Message-ID: <zPCZKn_YLp2EsFFscdMffeYISbr2Nx9M8-8HxGA-sKo=.622985b5-be05-4186-9279-dbfa1c783241@github.com>

On Tue, 17 Jun 2025 06:55:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
> 
> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
> 
> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
> 
> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.

src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 624:

> 622:                 host += ":" + String.valueOf(port);
> 623:             }
> 624:             if (requests.findValue("Host") == null) {

Should we use `setIfNotSet` here like for "Accept" below?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2152281066

From jpai at openjdk.org  Tue Jun 17 13:53:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 13:53:15 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v2]
In-Reply-To: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
Message-ID: <R7vNG0-2BfYD9ivsvAogLiuO-UiYlxMN4i74Gs-1j0I=.53ceb246-af24-4d8f-9d13-0484f17c9a75@github.com>

> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
> 
> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
> 
> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
> 
> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Volkan's suggestion - use test specific context root for the handler
 - Daniel's suggestion - use setIfNotSet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25844/files
  - new: https://git.openjdk.org/jdk/pull/25844/files/6dc36858..666f29b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25844&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25844&range=00-01

  Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25844/head:pull/25844

PR: https://git.openjdk.org/jdk/pull/25844

From jpai at openjdk.org  Tue Jun 17 13:53:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 13:53:15 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v2]
In-Reply-To: <zPCZKn_YLp2EsFFscdMffeYISbr2Nx9M8-8HxGA-sKo=.622985b5-be05-4186-9279-dbfa1c783241@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <zPCZKn_YLp2EsFFscdMffeYISbr2Nx9M8-8HxGA-sKo=.622985b5-be05-4186-9279-dbfa1c783241@github.com>
Message-ID: <5suQDfByfJmm7cfNDOAu_pE4-fGlgufhbz8PwSuptLo=.867ea008-c76e-4626-971e-f893ffc1595c@github.com>

On Tue, 17 Jun 2025 13:28:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Volkan's suggestion - use test specific context root for the handler
>>  - Daniel's suggestion - use setIfNotSet
>
> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java line 624:
> 
>> 622:                 host += ":" + String.valueOf(port);
>> 623:             }
>> 624:             if (requests.findValue("Host") == null) {
> 
> Should we use `setIfNotSet` here like for "Accept" below?

That seems reasonable. I had a look at the implementation in `setIfNotSet()` and it matches this current semantic. So I've updated the PR to use `setIfNotSet()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2152328489

From jpai at openjdk.org  Tue Jun 17 13:53:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 17 Jun 2025 13:53:16 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v2]
In-Reply-To: <J4kfMxPx4hejBEytuGpcxGO7CQ6xXDgvsp6F6XbCkQ4=.33324e07-09ee-4ac2-9a12-146b24600616@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <8o_WIP6-j9lOz9jZbqJDNOzWJsyBS1e8KO0LYE3JidI=.5f66a945-fef9-484b-ad59-02cf7b2bb907@github.com>
 <vX4PFeGn-sTXlCkDm1YoXweqZ4cLH36y6oeo1MAm9vA=.eff57760-200d-40fc-ad8a-67796e905100@github.com>
 <J4kfMxPx4hejBEytuGpcxGO7CQ6xXDgvsp6F6XbCkQ4=.33324e07-09ee-4ac2-9a12-146b24600616@github.com>
Message-ID: <xer8QeV8UkT7cgeleTD9QhBAzV7IpZM58DfU87YNA1Q=.522a4d81-e025-4e23-9437-592164277050@github.com>

On Tue, 17 Jun 2025 08:51:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Hello Volkan, the server handler in this test is implemented to allow more than one request during its lifetime. So any unexpected requests from other processes would still allow this test to be unaffected by those requests. Did I misunderstand your suggestion for registering the handler to a test specific context?
>
>> So any unexpected requests from other processes would still allow this test to be unaffected by those requests.
> 
> Yes, _this test_ will not be affected, but the other test _might_. Consider a test running in parallel, unexpectedly connecting to `HostHeaderTest`'s server, and it is
> 
> 1. either not expecting a response at all
> 2. or not expecting the response returned from the `HostHeaderTest`'s handler

I've updated the PR to register the handler at a test specific context root. Having said that, I wasn't aware we were doing this in our tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2152333063

From dfuchs at openjdk.org  Tue Jun 17 14:09:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Jun 2025 14:09:33 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v5]
In-Reply-To: <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>
Message-ID: <chv3xQGfY1Cijw-hbolypolAh2iyaQImTckdSt6Ufso=.9080e215-bed1-4e3d-84ae-09cf334a4584@github.com>

On Tue, 17 Jun 2025 08:40:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2935833308

From dfuchs at openjdk.org  Tue Jun 17 14:14:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Jun 2025 14:14:29 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v2]
In-Reply-To: <xer8QeV8UkT7cgeleTD9QhBAzV7IpZM58DfU87YNA1Q=.522a4d81-e025-4e23-9437-592164277050@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <8o_WIP6-j9lOz9jZbqJDNOzWJsyBS1e8KO0LYE3JidI=.5f66a945-fef9-484b-ad59-02cf7b2bb907@github.com>
 <vX4PFeGn-sTXlCkDm1YoXweqZ4cLH36y6oeo1MAm9vA=.eff57760-200d-40fc-ad8a-67796e905100@github.com>
 <J4kfMxPx4hejBEytuGpcxGO7CQ6xXDgvsp6F6XbCkQ4=.33324e07-09ee-4ac2-9a12-146b24600616@github.com>
 <xer8QeV8UkT7cgeleTD9QhBAzV7IpZM58DfU87YNA1Q=.522a4d81-e025-4e23-9437-592164277050@github.com>
Message-ID: <jYAmp9TL4IBxEncficIR6UJZkMjMfiQTbiHJzO1nvw8=.600a9aa7-9f3a-412e-ad8a-b2e0b1f70099@github.com>

On Tue, 17 Jun 2025 13:49:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> So any unexpected requests from other processes would still allow this test to be unaffected by those requests.
>> 
>> Yes, _this test_ will not be affected, but the other test _might_. Consider a test running in parallel, unexpectedly connecting to `HostHeaderTest`'s server, and it is
>> 
>> 1. either not expecting a response at all
>> 2. or not expecting the response returned from the `HostHeaderTest`'s handler
>
> I've updated the PR to register the handler at a test specific context root. Having said that, I wasn't aware we were doing this in our tests.

We had some tests failing randmonly in the past because they got additional connections from other processes running on the same host (some time other tests). So now we tend to add a bit of salt in the path - it makes it easier to figure out that the strange things you see in the logs were not caused by a legit client. Also if you see 404 being returned and you know that your custom handler never returns 404 then it's easier to figure out that you somehow connected to some other server.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2152386282

From dfuchs at openjdk.org  Tue Jun 17 14:19:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 17 Jun 2025 14:19:33 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v2]
In-Reply-To: <R7vNG0-2BfYD9ivsvAogLiuO-UiYlxMN4i74Gs-1j0I=.53ceb246-af24-4d8f-9d13-0484f17c9a75@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <R7vNG0-2BfYD9ivsvAogLiuO-UiYlxMN4i74Gs-1j0I=.53ceb246-af24-4d8f-9d13-0484f17c9a75@github.com>
Message-ID: <BGYVNPpdM-U_VbG0caRQE-upWclBl4bl7d-KuI2X93I=.0cf9f823-5c4a-4a4e-bdcc-1f23608243d9@github.com>

On Tue, 17 Jun 2025 13:53:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Volkan's suggestion - use test specific context root for the handler
>  - Daniel's suggestion - use setIfNotSet

test/jdk/java/net/HttpURLConnection/HostHeaderTest.java line 60:

> 58: class HostHeaderTest {
> 59: 
> 60:     private static final String SERVER_CTX_ROOT = "/8359709";

Suggestion:

    private static final String SERVER_CTX_ROOT = "/8359709/";

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2152391670

From vyazici at openjdk.org  Tue Jun 17 18:46:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 17 Jun 2025 18:46:28 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v5]
In-Reply-To: <YoSD3nFNjqLUCTidowJRkdGitSu7oU3utv0bwPNJni8=.5af7e986-b54c-442d-8e09-181678c42b76@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <URIa21DEmt-CjHGKszp_eJoIc9sU-9SiK77ijSAEY78=.c2004325-9f99-4a73-9728-9c0f4bb68787@github.com>
 <esbaen5v8_DVDUxG6NRDpKVA0qeRV4dNVRMi4_r_85o=.a22db670-9c93-433f-a201-a7efe86ff8d8@github.com>
 <YoSD3nFNjqLUCTidowJRkdGitSu7oU3utv0bwPNJni8=.5af7e986-b54c-442d-8e09-181678c42b76@github.com>
Message-ID: <UlxsNxtBXp8ih0RsCzPj0ETQDi5lRmKg-rj-rWJB-IY=.e0c4fb04-0cd9-4656-a77f-b3b7a1315bc0@github.com>

On Fri, 13 Jun 2025 14:49:24 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/HttpCookie.java line 892:
>> 
>>> 890:             assignAttribute(cookie, name, value);
>>> 891:         }
>>> 892:         assignMaxAgeAttribute(cookie, expiresValue, maxAgeValue);
>> 
>> @Michael-Mc-Mahon, instead of making an exception for `max-age` and `expires`, and removing them from `assignors`, can't we convert the type of `assignors` from `Map` to `List` and add `max-age` & `expires` entries at the end?
>
>> @Michael-Mc-Mahon, instead of making an exception for `max-age` and `expires`, and removing them from `assignors`, can't we convert the type of `assignors` from `Map` to `List` and add `max-age` & `expires` entries at the end?
> 
> Just converting from Map to List wouldn't be enough. The problem is that both attribute types need to be handled together. You could change the attribute name recognition to some kind of pattern match to recognise either of them. Then you need to know which of them was set and what their values were.
> 
> Maybe, I could at least use the assignor pattern to recognise the two attributes and limit the special code to just actioning the values. I'll take a look at that now.

I think the last commit (b22113118) just worsened things ? now the logic is spread across `assignMaxAgeAttribute`, `assignors`, and instance variables, whereas earlier it was only in `assignMaxAgeAttribute`. :face_with_diagonal_mouth: I suggest simply reverting it, that is, switching the state back to 9a495d7f9a5e.

I agree that introducing a smarter data structure and iteration scheme to `assignors` would simplify things, though that is probably out of the scope of this work.

Apologies for the inconvenience and thanks so much for your patient cooperation. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2152942047

From jpai at openjdk.org  Wed Jun 18 01:51:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 01:51:36 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
Message-ID: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>

> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
> 
> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
> 
> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
> 
> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Daniel's suggestion - use trailing slash for path registered for the handler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25844/files
  - new: https://git.openjdk.org/jdk/pull/25844/files/666f29b5..419e86be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25844&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25844&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25844/head:pull/25844

PR: https://git.openjdk.org/jdk/pull/25844

From jpai at openjdk.org  Wed Jun 18 01:51:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 01:51:37 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v2]
In-Reply-To: <BGYVNPpdM-U_VbG0caRQE-upWclBl4bl7d-KuI2X93I=.0cf9f823-5c4a-4a4e-bdcc-1f23608243d9@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <R7vNG0-2BfYD9ivsvAogLiuO-UiYlxMN4i74Gs-1j0I=.53ceb246-af24-4d8f-9d13-0484f17c9a75@github.com>
 <BGYVNPpdM-U_VbG0caRQE-upWclBl4bl7d-KuI2X93I=.0cf9f823-5c4a-4a4e-bdcc-1f23608243d9@github.com>
Message-ID: <pDr1x6pKHq5WybX7G0k9l22rpsJZmFM98AVPVDGYhX4=.81fa5a88-e896-4f85-a01c-b7f6fc5af533@github.com>

On Tue, 17 Jun 2025 14:13:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Volkan's suggestion - use test specific context root for the handler
>>  - Daniel's suggestion - use setIfNotSet
>
> test/jdk/java/net/HttpURLConnection/HostHeaderTest.java line 60:
> 
>> 58: class HostHeaderTest {
>> 59: 
>> 60:     private static final String SERVER_CTX_ROOT = "/8359709";
> 
> Suggestion:
> 
>     private static final String SERVER_CTX_ROOT = "/8359709/";
> 
> 
> Preferably always terminate context roots with /
> 
> https://docs.oracle.com/en/java/javase/24/docs/api/jdk.httpserver/com/sun/net/httpserver/HttpServer.html#createContext(java.lang.String,com.sun.net.httpserver.HttpHandler)
>> API Note:
>>     The path should generally, but is not required to, end with '/'. If the path does not end with '/', eg such as with "/foo" then this would match requests with a path of "/foobar" or "/foo/bar".

Good point. I've now updated the PR with this change. Test continues to pass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25844#discussion_r2153460024

From jpai at openjdk.org  Wed Jun 18 02:09:38 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 02:09:38 GMT
Subject: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if
 IOException because of TCP timeout [v5]
In-Reply-To: <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
 <Xyeb_U6AltH14jPq2n3-pVOjm7QxKP2YIWxewQay9tw=.d75c18d9-e106-40f7-b76a-797b038cabe7@github.com>
Message-ID: <n7ZPnS-1kZ6l2EKbbtidunSZC_WKx_36hlaGXIHAHdk=.f8f0bfa2-6e23-41d7-911a-e11b38f4be42@github.com>

On Tue, 17 Jun 2025 08:40:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
>> 
>> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
>> 
>> If this requires a CSR, I'll open one once we settle on the proposed text.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion

The CSR has been approved. Thank you all for the inputs and reviews. I'll go ahead with the integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25690#issuecomment-2982365926

From jpai at openjdk.org  Wed Jun 18 02:09:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 02:09:39 GMT
Subject: Integrated: 7116990: (spec) Socket.connect(addr, timeout) not clear if
 IOException because of TCP timeout
In-Reply-To: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
References: <qyyV0YUrcrPi1TawpGg-1V2OP8dhNfKXC-9V0RtYX5c=.dc6e0d62-4ce9-42c9-acd4-72727fc0c211@github.com>
Message-ID: <KGXySGqsYNsTaZ4UpJ2rWtQax7cWPr5IVhVX1aCT-Bc=.0e88ef2d-daa0-4399-9b87-fbf64bf3dadb@github.com>

On Mon, 9 Jun 2025 07:39:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this doc-only change which proposes to add a `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` method? This addresses https://bugs.openjdk.org/browse/JDK-7116990.
> 
> As noted in that issue, users can find it surprising that when the `Socket.connect(...)` method is called with a `timeout` value, then if that timeout value happens to be greater than the connect timeout that operating systems typically impose, then a `IOException` gets thrown instead of the `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` which explains this current behaviour.
> 
> If this requires a CSR, I'll open one once we settle on the proposed text.

This pull request has now been integrated.

Changeset: 2f63d3ae
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f63d3aee555762bfaea2a77bf543a32ca43f069
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout

Reviewed-by: alanb, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25690

From dfuchs at openjdk.org  Wed Jun 18 08:15:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Jun 2025 08:15:34 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
Message-ID: <GQh1KZRRzKYUmZOsvm4oNxqjTEMftImi-LCGPe3J_I8=.2e5f972c-8c8b-410f-8d9e-5ac45fbc1bb5@github.com>

On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - use trailing slash for path registered for the handler

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25844#pullrequestreview-2938194305

From djelinski at openjdk.org  Wed Jun 18 08:15:35 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 18 Jun 2025 08:15:35 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
Message-ID: <tnOQbi9LInlrUS7B016XMmXKGd-4VWDTMWOj0NGj4S4=.d97452c4-6593-4a3f-b4d0-2f3eadbaca91@github.com>

On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - use trailing slash for path registered for the handler

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25844#pullrequestreview-2938199904

From jpai at openjdk.org  Wed Jun 18 08:30:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 08:30:31 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
Message-ID: <wNuJfXZqFbFR-OuSZMSPO8tMJaegxNkqg-KjlWy9B2k=.f4893961-56c9-4159-9db0-c6d5db825fa7@github.com>

On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - use trailing slash for path registered for the handler

Thank you all for the reviews. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25844#issuecomment-2983206206

From michaelm at openjdk.org  Wed Jun 18 08:30:32 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 18 Jun 2025 08:30:32 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
Message-ID: <gEJIlQjMiqCDCbGvXyGO3sgBru1ixUq-g5PmYh6bqDc=.bec23a94-593a-4b63-8a11-d50a08d70356@github.com>

On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - use trailing slash for path registered for the handler

I'm trying to understand how this regression happened. I was looking at the code change for https://bugs.openjdk.org/browse/JDK-8344190 at https://openjdk.github.io/cr/?repo=jdk&pr=22232&range=01#sdiff-4-src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java and I can't see how it happened. The change looks pretty innocuous..?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25844#issuecomment-2983210722

From michaelm at openjdk.org  Wed Jun 18 08:33:34 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 18 Jun 2025 08:33:34 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <gEJIlQjMiqCDCbGvXyGO3sgBru1ixUq-g5PmYh6bqDc=.bec23a94-593a-4b63-8a11-d50a08d70356@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
 <gEJIlQjMiqCDCbGvXyGO3sgBru1ixUq-g5PmYh6bqDc=.bec23a94-593a-4b63-8a11-d50a08d70356@github.com>
Message-ID: <rJOHGMjIh0TvkDSpuj6KbY1r8a6UzpkzQVLklOKTQV0=.13607d55-aae4-45fb-9d3b-38a068a24a7f@github.com>

On Wed, 18 Jun 2025 08:27:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I'm trying to understand how this regression happened. I was looking at the code change for https://bugs.openjdk.org/browse/JDK-8344190 at https://openjdk.github.io/cr/?repo=jdk&pr=22232&range=01#sdiff-4-src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java and I can't see how it happened. The change looks pretty innocuous..?

Never mind. I see it's explained clearly in the bug report.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25844#issuecomment-2983221435

From jpai at openjdk.org  Wed Jun 18 08:42:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 08:42:28 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
Message-ID: <XSpbOeCF944akYUeHUMId3wWouf5vmNz9EyVvuKUdNg=.c4e93078-ad1e-49c6-be22-f58f624ba5c7@github.com>

On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - use trailing slash for path registered for the handler

Hello Michael, I see that you already found out what caused the regression, but yes it's the `if` block check which went wrong in our clean up. The `checkSetHost()` method which was being used previously would always return `true` when SecurityManager wasn't set and that meant that we wouldn't enter the `if` block when the `requestHost` was non-null. That check broke after our clean up and is now fixed in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25844#issuecomment-2983249755

From michaelm at openjdk.org  Wed Jun 18 08:55:29 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 18 Jun 2025 08:55:29 GMT
Subject: RFR: 8359709: java.net.HttpURLConnection sends unexpected "Host"
 request header in some cases after JDK-8344190 [v3]
In-Reply-To: <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
 <TLrYBiayfi4dnlaWBEiCic7A9D6Hx4R8bg5ZRg1DHF8=.6d185f32-8366-4446-903e-34207510dc34@github.com>
Message-ID: <Y5JoBvag3Sb5QpCrSuOeMI2eSQ3phF_1v7OyaMjsakM=.e1a34c00-2bf9-4337-99a7-e3a7bdcc1ae9@github.com>

On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
>> 
>> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
>> 
>> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
>> 
>> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
>> 
>> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Daniel's suggestion - use trailing slash for path registered for the handler

Marked as reviewed by michaelm (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25844#pullrequestreview-2938327484

From jpai at openjdk.org  Wed Jun 18 09:07:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 09:07:40 GMT
Subject: Integrated: 8359709: java.net.HttpURLConnection sends unexpected
 "Host" request header in some cases after JDK-8344190
In-Reply-To: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
References: <hKcc_HEFvGfogS0UP1cGr5o6X9v9QlUBdUyi-4AmcMs=.3d9ed147-2f7c-4072-bc48-f6845491b90d@github.com>
Message-ID: <AdAQ3gM7f-Oczh2rXRVjKEnvhzQ_IQzNVL2vtyxaqRA=.dc03c849-99f4-4c90-805d-d2f1caedb637@github.com>

On Tue, 17 Jun 2025 06:55:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which addresses a regression that was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code by removing the references to SecurityManager APIs.
> 
> When a HTTP request is issued through `java.net.HttpURLConnection`, then the request URL is used to determine the `Host` header to set in the request. By default, the application cannot set a `Host` header to a different value. However the JDK allows a system property to be enabled to allow applications to explicitly set a `Host` request header when issuing the request.
> 
> Due to an oversight in the change that was done in https://bugs.openjdk.org/browse/JDK-8344190, the `Host` header that is set by the application, may not get used for that request causing this regression. Turns out we don't have tests in this area to catch this issue.
> 
> The commit in this PR fixes the regression and also introduces a new jtreg test which reproduces the issue and verifies the fix.
> 
> I've also checked the original change which introduced this regression https://github.com/openjdk/jdk/pull/22232 to see if there's anything else that needs attention. I haven't stopped anything else.

This pull request has now been integrated.

Changeset: 57266064
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57266064a7bb995c3c614c19b936687af35e9aa4
Stats:     147 lines in 2 files changed: 143 ins; 0 del; 4 mod

8359709: java.net.HttpURLConnection sends unexpected "Host" request header in some cases after JDK-8344190

Reviewed-by: dfuchs, djelinski, michaelm, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/25844

From jpai at openjdk.org  Wed Jun 18 09:20:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 09:20:51 GMT
Subject: [jdk25] RFR: 8359709: java.net.HttpURLConnection sends unexpected
 "Host" request header in some cases after JDK-8344190
Message-ID: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>

Can I please get a review of this backport to JDK 25 for https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression that was introduced in JDK 24. The mainline fix was integrated a few mintues back through https://github.com/openjdk/jdk/pull/25844.

-------------

Commit messages:
 - Backport 57266064a7bb995c3c614c19b936687af35e9aa4

Changes: https://git.openjdk.org/jdk/pull/25867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25867&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359709
  Stats: 147 lines in 2 files changed: 143 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25867/head:pull/25867

PR: https://git.openjdk.org/jdk/pull/25867

From michaelm at openjdk.org  Wed Jun 18 10:04:10 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 18 Jun 2025 10:04:10 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v5]
In-Reply-To: <UlxsNxtBXp8ih0RsCzPj0ETQDi5lRmKg-rj-rWJB-IY=.e0c4fb04-0cd9-4656-a77f-b3b7a1315bc0@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <URIa21DEmt-CjHGKszp_eJoIc9sU-9SiK77ijSAEY78=.c2004325-9f99-4a73-9728-9c0f4bb68787@github.com>
 <esbaen5v8_DVDUxG6NRDpKVA0qeRV4dNVRMi4_r_85o=.a22db670-9c93-433f-a201-a7efe86ff8d8@github.com>
 <YoSD3nFNjqLUCTidowJRkdGitSu7oU3utv0bwPNJni8=.5af7e986-b54c-442d-8e09-181678c42b76@github.com>
 <UlxsNxtBXp8ih0RsCzPj0ETQDi5lRmKg-rj-rWJB-IY=.e0c4fb04-0cd9-4656-a77f-b3b7a1315bc0@github.com>
Message-ID: <Hc1g-9a7tlJckwvdcSWTfYkbPYgse_LtgQXYcYfPzn8=.af444dc4-8cc1-40d9-8656-7334f17a4f22@github.com>

On Tue, 17 Jun 2025 18:43:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>>> @Michael-Mc-Mahon, instead of making an exception for `max-age` and `expires`, and removing them from `assignors`, can't we convert the type of `assignors` from `Map` to `List` and add `max-age` & `expires` entries at the end?
>> 
>> Just converting from Map to List wouldn't be enough. The problem is that both attribute types need to be handled together. You could change the attribute name recognition to some kind of pattern match to recognise either of them. Then you need to know which of them was set and what their values were.
>> 
>> Maybe, I could at least use the assignor pattern to recognise the two attributes and limit the special code to just actioning the values. I'll take a look at that now.
>
> I think the last commit (b22113118) just worsened things ? now the logic is spread across `assignMaxAgeAttribute`, `assignors`, and instance variables, whereas earlier it was only in `assignMaxAgeAttribute`. :face_with_diagonal_mouth: I suggest simply reverting it, that is, switching the state back to 9a495d7f9a5e.
> 
> I agree that introducing a smarter data structure and iteration scheme to `assignors` would simplify things, though that is probably out of the scope of this work.
> 
> Apologies for the inconvenience and thanks so much for your patient cooperation. ?

> I think the last commit ([b221131](https://github.com/openjdk/jdk/commit/b22113118ce68a5ba710be9072b208e9a36ae533)) just worsened things ? now the logic is spread across `assignMaxAgeAttribute`, `assignors`, and instance variables, whereas earlier it was only in `assignMaxAgeAttribute`. ? I suggest simply reverting it, that is, switching the state back to [9a495d7](https://github.com/openjdk/jdk/commit/9a495d7f9a5e9ae86ce71010950f11ce23ee1c2c).
> 
> I agree that introducing a smarter data structure and iteration scheme to `assignors` would simplify things, though that is probably out of the scope of this work.
> 
> Apologies for the inconvenience and thanks so much for your patient cooperation. ?

Yeah, I agree. I will revert it. The old version was clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2154196899

From michaelm at openjdk.org  Wed Jun 18 10:04:10 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 18 Jun 2025 10:04:10 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v7]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <CWVtkkjYxSNN-h0CKqk7BU5zTr0icPmDY7NI5tUrcjc=.052fbbf4-da64-4daf-b508-81cb425cbba2@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Revert "impl update"
  
  This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/b2211311..75690ec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=05-06

  Stats: 39 lines in 1 file changed: 15 ins; 19 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From michaelm at openjdk.org  Wed Jun 18 10:54:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 18 Jun 2025 10:54:12 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v8]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <RCB3td-vJKpPAAlFwa2AG8VWNGleJKBZttqDGmLLgX4=.d427ee97-30b5-477f-bc65-bfefae38b8b6@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon 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 15 additional commits since the last revision:

 - Merge branch 'master' into cookie-8351983
 - Revert "impl update"
   
   This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
 - impl update
 - test update
 - test and impl update
 - Merge branch 'master' into cookie-8351983
 - copyright
 - impl update
 - whitespace
 - update
 - ... and 5 more: https://git.openjdk.org/jdk/compare/0d0707d8...9ee697da

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/75690ec1..9ee697da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=06-07

  Stats: 20160 lines in 445 files changed: 12258 ins; 5896 del; 2006 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From dfuchs at openjdk.org  Wed Jun 18 10:59:27 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Jun 2025 10:59:27 GMT
Subject: [jdk25] RFR: 8359709: java.net.HttpURLConnection sends unexpected
 "Host" request header in some cases after JDK-8344190
In-Reply-To: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
References: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
Message-ID: <SCm0ATPAhVF5JBCoZEjTRz3-9zw4C5kyURqPjfx-1D4=.9267db4e-2d31-45fe-968d-f340f798ee16@github.com>

On Wed, 18 Jun 2025 09:16:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport to JDK 25 for https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression that was introduced in JDK 24. The mainline fix was integrated a few mintues back through https://github.com/openjdk/jdk/pull/25844.

LGTM. This fixes a regression so should be fine to backport to 25 in RDP 1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25867#issuecomment-2983719882

From dfuchs at openjdk.org  Wed Jun 18 11:40:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Jun 2025 11:40:31 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v8]
In-Reply-To: <RCB3td-vJKpPAAlFwa2AG8VWNGleJKBZttqDGmLLgX4=.d427ee97-30b5-477f-bc65-bfefae38b8b6@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <RCB3td-vJKpPAAlFwa2AG8VWNGleJKBZttqDGmLLgX4=.d427ee97-30b5-477f-bc65-bfefae38b8b6@github.com>
Message-ID: <OKrkYd2XuCMszkZmdH3Czul49qR04KMtSt2gX3JBYiM=.62fe8d90-bc78-4919-ab17-0bcc7a19fbcc@github.com>

On Wed, 18 Jun 2025 10:54:12 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into cookie-8351983
>  - Revert "impl update"
>    
>    This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
>  - impl update
>  - test update
>  - test and impl update
>  - Merge branch 'master' into cookie-8351983
>  - copyright
>  - impl update
>  - whitespace
>  - update
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/9afbf027...9ee697da

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2938857216

From duke at openjdk.org  Wed Jun 18 12:59:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 12:59:04 GMT
Subject: RFR: 8356645: JavaRuntimeURLConnection should only connect to
 non-directory resources
Message-ID: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>

Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.

This change has the following distinct parts:
1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
4. Small constructor logic simplification (module name cannot be null anymore)
5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
6. Adding tests for the non-resource cases.
7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

-------------

Commit messages:
 - Copyright update.
 - Removing dead/unused code, simplifying connection logic and tidying up.

Changes: https://git.openjdk.org/jdk/pull/25871/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356645
  Stats: 134 lines in 2 files changed: 43 ins; 55 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/25871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25871/head:pull/25871

PR: https://git.openjdk.org/jdk/pull/25871

From duke at openjdk.org  Wed Jun 18 13:05:34 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 13:05:34 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>

On Wed, 18 Jun 2025 12:53:56 GMT, David Beaumont <duke at openjdk.org> wrote:

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

Preloading a few explanatory comments.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 49:

> 47: 
> 48:     // ImageReader to access resources in jimage
> 49:     private static final ImageReader reader = ImageReaderFactory.getImageReader();

Examination of code and other users shows that this could never be null. Other users also name it "READER".

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:

> 54: 
> 55:     // the Resource when connected
> 56:     private volatile Resource resource;

The Resource API was never needed here and adds uncalled methods such as `getURL()` which are then implemented with code that could never be invoked.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 64:

> 62:             throw new MalformedURLException(url + " missing path or /");
> 63:         if (path.length() == 1) {
> 64:             this.module = null;

There's no reason for the module==null case, since the only thing caring that this might be null just converts null to the empty string anyway.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 101:

> 99:             }
> 100:             this.resource = node;
> 101:             super.connected = true;

I know I don't *need* to use super here, but it documents the fact that this is not a field of this subclass, without readers having to go check. Mutable protected fields are weird and error prone, so I felt calling it out a bit was worth it. Happy to replace with a comment if people feel that's better though.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 119:

> 117:     public long getContentLengthLong() {
> 118:         try {
> 119:             return getResourceNode().size();

Having getResourceNode() return the (lazily fetched) node avoids the reader needing to know/reason about how "connect()" has the side-effect of making the "resource" field non-null.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25871#pullrequestreview-2939094081
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154527602
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154529805
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154532882
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154538127
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154543346

From alanb at openjdk.org  Wed Jun 18 13:13:30 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 13:13:30 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <SqGJCtnlDUAiD5Y32j0PwRHP35IGZj_NJqLWYipx-jI=.ff8d75b6-8ca9-4d87-8865-984d53005277@github.com>

On Wed, 18 Jun 2025 12:53:56 GMT, David Beaumont <duke at openjdk.org> wrote:

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:

> 54:     // about percent encoding. However, we choose to treat the module name is if
> 55:     // it were a URL authority (since Java package/module names are historically
> 56:     // strongly associated with internet domain names).

"However, we choose to treat the module name is if URL authority" -  I don't think we should be put in the comment as it is confusing to suggest the URL authority component. The URL scheme documented in JEP 220 always put the module and resource name in the URL path component.  It's just historical that it allowed for encoding of the resource name, wasn't given enough thought in JDK 9 when this url stream handler was added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154566253

From duke at openjdk.org  Wed Jun 18 13:24:30 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 13:24:30 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources
In-Reply-To: <SqGJCtnlDUAiD5Y32j0PwRHP35IGZj_NJqLWYipx-jI=.ff8d75b6-8ca9-4d87-8865-984d53005277@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <SqGJCtnlDUAiD5Y32j0PwRHP35IGZj_NJqLWYipx-jI=.ff8d75b6-8ca9-4d87-8865-984d53005277@github.com>
Message-ID: <oL6eZsW-pALWP02IkqNNcIv9FIqUCEQOnDGJCTfv7zQ=.485b252c-145b-4834-9ffa-e2f280afc325@github.com>

On Wed, 18 Jun 2025 13:11:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:
> 
>> 54:     // about percent encoding. However, we choose to treat the module name is if
>> 55:     // it were a URL authority (since Java package/module names are historically
>> 56:     // strongly associated with internet domain names).
> 
> "However, we choose to treat the module name is if URL authority" -  I don't think we should be put in the comment as it is confusing to suggest the URL authority component. The URL scheme documented in JEP 220 always put the module and resource name in the URL path component.  It's just historical that it allowed for encoding of the resource name, wasn't given enough thought in JDK 9 when this url stream handler was added.

Happy to accept rewording here. I do want to pull out that there *is* a conceptual reason for treating module names like domain authorities though, or just make the code treat the whole path the same.
Having unexplained weirdness like this just ends up being a drain on future maintainers otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154596891

From jpai at openjdk.org  Wed Jun 18 13:35:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 18 Jun 2025 13:35:29 GMT
Subject: [jdk25] RFR: 8359709: java.net.HttpURLConnection sends unexpected
 "Host" request header in some cases after JDK-8344190
In-Reply-To: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
References: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
Message-ID: <QB_Kca8-5WbFSmOXvLxH-t3Z2iSbnLlkCdHMcH5w68Q=.fa3b2be4-91a1-482e-9b32-1c0871f86d67@github.com>

On Wed, 18 Jun 2025 09:16:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport to JDK 25 for https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression that was introduced in JDK 24. The mainline fix was integrated a few mintues back through https://github.com/openjdk/jdk/pull/25844.

Thank you Daniel for the review. tier1, tier2 and tier3 of this change against JDK 25 went fine without any failures. I'll need your "Approval" on this PR to integrate it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25867#issuecomment-2984235312

From alanb at openjdk.org  Wed Jun 18 13:41:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 13:41:29 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources
In-Reply-To: <oL6eZsW-pALWP02IkqNNcIv9FIqUCEQOnDGJCTfv7zQ=.485b252c-145b-4834-9ffa-e2f280afc325@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <SqGJCtnlDUAiD5Y32j0PwRHP35IGZj_NJqLWYipx-jI=.ff8d75b6-8ca9-4d87-8865-984d53005277@github.com>
 <oL6eZsW-pALWP02IkqNNcIv9FIqUCEQOnDGJCTfv7zQ=.485b252c-145b-4834-9ffa-e2f280afc325@github.com>
Message-ID: <A6hD_cn-Dwqbsej8eNFks0GvSoEs1xm4sQg7tORkD34=.088d7499-52bd-441d-b6f7-7cfd126a2975@github.com>

On Wed, 18 Jun 2025 13:21:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:
>> 
>>> 54:     // about percent encoding. However, we choose to treat the module name is if
>>> 55:     // it were a URL authority (since Java package/module names are historically
>>> 56:     // strongly associated with internet domain names).
>> 
>> "However, we choose to treat the module name is if URL authority" -  I don't think we should be put in the comment as it is confusing to suggest the URL authority component. The URL scheme documented in JEP 220 always put the module and resource name in the URL path component.  It's just historical that it allowed for encoding of the resource name, wasn't given enough thought in JDK 9 when this url stream handler was added.
>
> Happy to accept rewording here. I do want to pull out that there *is* a conceptual reason for treating module names like domain authorities though, or just make the code treat the whole path the same.
> Having unexplained weirdness like this just ends up being a drain on future maintainers otherwise.

> Happy to accept rewording here. I do want to pull out that there _is_ a conceptual reason for treating module names like domain authorities though, or just make the code treat the whole path the same. Having unexplained weirdness like this just ends up being a drain on future maintainers otherwise.

I don't disagree on the weirdness but I don't want to mislead readers that this has anything to do with the URL authority component (the jrt scheme does not have this component).  However to explain the weirdness requires digging into history, probably the jake repo where the changes for JEP 220 were accumulated before the JEP was integrated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154637860

From duke at openjdk.org  Wed Jun 18 13:57:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 13:57:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources
In-Reply-To: <A6hD_cn-Dwqbsej8eNFks0GvSoEs1xm4sQg7tORkD34=.088d7499-52bd-441d-b6f7-7cfd126a2975@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <SqGJCtnlDUAiD5Y32j0PwRHP35IGZj_NJqLWYipx-jI=.ff8d75b6-8ca9-4d87-8865-984d53005277@github.com>
 <oL6eZsW-pALWP02IkqNNcIv9FIqUCEQOnDGJCTfv7zQ=.485b252c-145b-4834-9ffa-e2f280afc325@github.com>
 <A6hD_cn-Dwqbsej8eNFks0GvSoEs1xm4sQg7tORkD34=.088d7499-52bd-441d-b6f7-7cfd126a2975@github.com>
Message-ID: <S263fT8bTYjvl04LCchqQ57moFBBX1GJc6plB7vRqSI=.68ff0ba0-b5a4-43c4-a61e-67b66f8d8d93@github.com>

On Wed, 18 Jun 2025 13:37:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Happy to accept rewording here. I do want to pull out that there *is* a conceptual reason for treating module names like domain authorities though, or just make the code treat the whole path the same.
>> Having unexplained weirdness like this just ends up being a drain on future maintainers otherwise.
>
>> Happy to accept rewording here. I do want to pull out that there _is_ a conceptual reason for treating module names like domain authorities though, or just make the code treat the whole path the same. Having unexplained weirdness like this just ends up being a drain on future maintainers otherwise.
> 
> I don't disagree on the weirdness but I don't want to mislead readers that this has anything to do with the URL authority component (the jrt scheme does not have this component).  However to explain the weirdness requires digging into history, probably the jake repo where the changes for JEP 220 were accumulated before the JEP was integrated.

The alternative is to permit module names to use percent encoding, since package names (and thus module names) can include non-ASCII characters, and doing so would simplify the code, but it also allows a level of obfuscateability to the URLs which we might not desire (unless we reject any over-encoding of ASCII).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2154678242

From abarashev at openjdk.org  Wed Jun 18 15:54:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 15:54:48 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v6]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <dorxSmvEaQ5Fq0qWV_hC5VLd5UCLO7UvcL2IGGiyA_s=.cefc093a-035c-462c-84a3-f6511b221cd1@github.com>

> When the deafult SunX509KeyManagerImpl is being used we are in violation of TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3
> 
> X509KeyManagerImpl on the other hand includes the algorithms sent by the peer in "signature_algorithms_cert" extension (or in "signature_algorithms" extension when "signature_algorithms_cert" extension isn't present) in the algorithm constraints being checked.
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Add more unit tests. Some code refactoring and adjustments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/448442e9..eaf343ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=04-05

  Stats: 171 lines in 5 files changed: 106 ins; 36 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From dnadeau at etsy.com  Wed Jun 18 16:24:45 2025
From: dnadeau at etsy.com (David Nadeau)
Date: Wed, 18 Jun 2025 09:24:45 -0700
Subject: Potential bug in HttpClientImpl: Thread pool rejection causes
 permanent client failure
Message-ID: <CA+mvrzDa66HwJPUw+qZgH8ubtFVgWWa6CE+6SEQH2+GLqPAo7Q@mail.gmail.com>

When overriding the HttpClient executor with a custom ThreadPoolExecutor
that uses the default RejectedExecutionHandler.AbortPolicy, the Java HTTP
client (java.net.http.HttpClient) becomes permanently unusable if the
delegate executor rejects a task.

This creates a situation where transient thread pool saturation results in
a non-recoverable client failure.

Reproduction of the issue:
1. The task rejection triggers a call to the error handler (onSubmitFailure)
2. This calls selmgr.abort(failure) with the rejection exception
3. SelectorManager.abort() sets this.closed = true permanently
4. All subsequent HTTP operations fail with "IOException: selector manager
closed"

The client does not recover from this state.

I was able to avoid this by using the DiscardPolicy instead of the
AbortPolicy. However, this behavior was quite a surprise to debug. Is this
behavior intentional, or does it make sense for the HttpClient to treat
task rejection as a recoverable error?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250618/162092bf/attachment.htm>

From duke at openjdk.org  Wed Jun 18 16:48:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 16:48:45 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Reworking comment and adjusting TODOs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25871/files
  - new: https://git.openjdk.org/jdk/pull/25871/files/555bac6e..3bafc256

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25871/head:pull/25871

PR: https://git.openjdk.org/jdk/pull/25871

From duke at openjdk.org  Wed Jun 18 16:52:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 18 Jun 2025 16:52:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <S263fT8bTYjvl04LCchqQ57moFBBX1GJc6plB7vRqSI=.68ff0ba0-b5a4-43c4-a61e-67b66f8d8d93@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <SqGJCtnlDUAiD5Y32j0PwRHP35IGZj_NJqLWYipx-jI=.ff8d75b6-8ca9-4d87-8865-984d53005277@github.com>
 <oL6eZsW-pALWP02IkqNNcIv9FIqUCEQOnDGJCTfv7zQ=.485b252c-145b-4834-9ffa-e2f280afc325@github.com>
 <A6hD_cn-Dwqbsej8eNFks0GvSoEs1xm4sQg7tORkD34=.088d7499-52bd-441d-b6f7-7cfd126a2975@github.com>
 <S263fT8bTYjvl04LCchqQ57moFBBX1GJc6plB7vRqSI=.68ff0ba0-b5a4-43c4-a61e-67b66f8d8d93@github.com>
Message-ID: <_JGcpSDcE62Gjs_ec9Z57ZvKC3-wFVCW8iEop0tnoH8=.28d12dea-9b36-4487-b205-1d0011716231@github.com>

On Wed, 18 Jun 2025 13:54:42 GMT, David Beaumont <duke at openjdk.org> wrote:

>>> Happy to accept rewording here. I do want to pull out that there _is_ a conceptual reason for treating module names like domain authorities though, or just make the code treat the whole path the same. Having unexplained weirdness like this just ends up being a drain on future maintainers otherwise.
>> 
>> I don't disagree on the weirdness but I don't want to mislead readers that this has anything to do with the URL authority component (the jrt scheme does not have this component).  However to explain the weirdness requires digging into history, probably the jake repo where the changes for JEP 220 were accumulated before the JEP was integrated.
>
> The alternative is to permit module names to use percent encoding, since package names (and thus module names) can include non-ASCII characters, and doing so would simplify the code, but it also allows a level of obfuscateability to the URLs which we might not desire (unless we reject any over-encoding of ASCII).

I updated the comment and some TODOs. I'll likely raise a separate PR for it since I suspect we need to end up:
1. allowing percent encoding everywhere (to support non-ASCII Unicode).
2. disallowing over-encoding (e.g. of '/' or '$', or just any ASCII) to prevent obfuscation.
But as it's a behaviour change, I'd rather separate it out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2155083474

From daniel.fuchs at oracle.com  Wed Jun 18 17:42:27 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Jun 2025 18:42:27 +0100
Subject: Potential bug in HttpClientImpl: Thread pool rejection causes
 permanent client failure
In-Reply-To: <CA+mvrzDa66HwJPUw+qZgH8ubtFVgWWa6CE+6SEQH2+GLqPAo7Q@mail.gmail.com>
References: <CA+mvrzDa66HwJPUw+qZgH8ubtFVgWWa6CE+6SEQH2+GLqPAo7Q@mail.gmail.com>
Message-ID: <e8528c9a-2022-44e8-a799-729faee91365@oracle.com>

Hi David,

As a general rule, the client doesn't expect tasks to
be rejected by the executor. Tasks need to be executed,
one way or another, for the client to work as expected.
Executing in the current thread is often not an option
as it may lead to deadlocks.
So if we get a RejectedTaskExection, we shutdown the
client, as there's not much else we can do.

We have some contengency measure for shutdown in case of
RejectedTaskException that will temporarily execute rejected
tasks in the FJP instead when the executor rejects a task,
but this is only a best effort whose only goal is to make
it possible to complete the shutdown, and wakeup any calling
code that may be waiting on send or completable futures returned
by sendAsync.

best regards,

-- daniel

On 18/06/2025 17:24, David Nadeau wrote:
> When overriding the HttpClient executor with a custom ThreadPoolExecutor 
> that uses the default RejectedExecutionHandler.AbortPolicy, the Java 
> HTTP client (java.net.http.HttpClient) becomes permanently unusable if 
> the delegate executor rejects a task.
> 
> This creates a situation where transient thread pool saturation results 
> in a non-recoverable client failure.
> 
> Reproduction of the issue:
> 1. The task rejection triggers a call to the error handler (onSubmitFailure)
> 2. This calls selmgr.abort(failure) with the rejection exception
> 3. SelectorManager.abort() sets this.closed = true permanently
> 4. All subsequent HTTP operations fail with "IOException: selector 
> manager closed"
> 
> The client does not recover from this state.
> 
> I was able to avoid this by using the DiscardPolicy instead of the 
> AbortPolicy. However, this behavior was quite a surprise to?debug. Is 
> this behavior intentional, or does it make sense for the HttpClient to 
> treat task rejection as a recoverable error?


From vyazici at openjdk.org  Wed Jun 18 18:17:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 18 Jun 2025 18:17:31 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v8]
In-Reply-To: <RCB3td-vJKpPAAlFwa2AG8VWNGleJKBZttqDGmLLgX4=.d427ee97-30b5-477f-bc65-bfefae38b8b6@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <RCB3td-vJKpPAAlFwa2AG8VWNGleJKBZttqDGmLLgX4=.d427ee97-30b5-477f-bc65-bfefae38b8b6@github.com>
Message-ID: <Sl4ys3op12GrpOxOFaiJqTkpUIxwc5YlzG7I51nik50=.1c7faf0b-c37c-485b-9e3e-1df081875617@github.com>

On Wed, 18 Jun 2025 10:54:12 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into cookie-8351983
>  - Revert "impl update"
>    
>    This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
>  - impl update
>  - test update
>  - test and impl update
>  - Merge branch 'master' into cookie-8351983
>  - copyright
>  - impl update
>  - whitespace
>  - update
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/cc3287c5...9ee697da

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2940240279

From dnadeau at etsy.com  Wed Jun 18 18:19:20 2025
From: dnadeau at etsy.com (David Nadeau)
Date: Wed, 18 Jun 2025 11:19:20 -0700
Subject: Potential bug in HttpClientImpl: Thread pool rejection causes
 permanent client failure
In-Reply-To: <e8528c9a-2022-44e8-a799-729faee91365@oracle.com>
References: <CA+mvrzDa66HwJPUw+qZgH8ubtFVgWWa6CE+6SEQH2+GLqPAo7Q@mail.gmail.com>
 <e8528c9a-2022-44e8-a799-729faee91365@oracle.com>
Message-ID: <CA+mvrzCaQwjZ_Xy4VihBdh=XqFPM4NgOKnqvaZ+m7=FNZDFpjA@mail.gmail.com>

Hi Daniel,

Thank you for this reply.
In our case, the underlying thread pool doesn't typically become
overloaded, but when it does, we?re forced to manually restart applications
because the HttpClient becomes permanently stalled.

Why is it that tasks need to be executed? Dropping work can be an
acceptable means of backpressure for a threadpool. Are there some tasks
that the HttpClient submits to this delegate threadpool which are essential
for the client to continue behaving correctly? And dropping such a task
could cause the client to continue working, but in a potentially broken way?
If this is the case, it may be risky to apply my fix of switching to a
DiscardPolicy. As this would allow the threadpool to silently drop work
while keeping the http client open. I wonder if it would be safer to use
your FJP idea to write a RejectedExceptionHandler that falls back to
submitting rejected tasks there.


On Wed, Jun 18, 2025 at 10:42?AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi David,
>
> As a general rule, the client doesn't expect tasks to
> be rejected by the executor. Tasks need to be executed,
> one way or another, for the client to work as expected.
> Executing in the current thread is often not an option
> as it may lead to deadlocks.
> So if we get a RejectedTaskExection, we shutdown the
> client, as there's not much else we can do.
>
> We have some contengency measure for shutdown in case of
> RejectedTaskException that will temporarily execute rejected
> tasks in the FJP instead when the executor rejects a task,
> but this is only a best effort whose only goal is to make
> it possible to complete the shutdown, and wakeup any calling
> code that may be waiting on send or completable futures returned
> by sendAsync.
>
> best regards,
>
> -- daniel
>
> On 18/06/2025 17:24, David Nadeau wrote:
> > When overriding the HttpClient executor with a custom ThreadPoolExecutor
> > that uses the default RejectedExecutionHandler.AbortPolicy, the Java
> > HTTP client (java.net.http.HttpClient) becomes permanently unusable if
> > the delegate executor rejects a task.
> >
> > This creates a situation where transient thread pool saturation results
> > in a non-recoverable client failure.
> >
> > Reproduction of the issue:
> > 1. The task rejection triggers a call to the error handler
> (onSubmitFailure)
> > 2. This calls selmgr.abort(failure) with the rejection exception
> > 3. SelectorManager.abort() sets this.closed = true permanently
> > 4. All subsequent HTTP operations fail with "IOException: selector
> > manager closed"
> >
> > The client does not recover from this state.
> >
> > I was able to avoid this by using the DiscardPolicy instead of the
> > AbortPolicy. However, this behavior was quite a surprise to debug. Is
> > this behavior intentional, or does it make sense for the HttpClient to
> > treat task rejection as a recoverable error?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250618/63635a8e/attachment.htm>

From mullan at openjdk.org  Wed Jun 18 18:46:37 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 18 Jun 2025 18:46:37 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
 <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>
Message-ID: <TGSM3KuPzvC_wVIKIfXMO8MeOfUZUhMCLF6Y5U3tyOQ=.5f8ffa6d-c3ce-49f8-bea0-89e457bd3e21@github.com>

On Fri, 6 Jun 2025 16:19:07 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
>> 
>>> 1: /*
>> 
>> I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.
>> 
>> Please add some more comments explaining how the exception case occurs.
>
> Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests, one for each issue:
> 
> 1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
> 2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.

I see. You also have a 3rd: JDK-8359069. It's rare to see one PR fix multiple issues, even though skara supports it. I'm not sure I see specific advantages of having three separate issues instead of just one. Is it primarily because you see these as separate issues? In that case, does it make sense to fix this as 3 different issues in case one or more them needs to be selectively backported?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2155264743

From prr at openjdk.org  Wed Jun 18 20:43:30 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jun 2025 20:43:30 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
Message-ID: <NNqeDPnu_kQAPMFhtHpRw7kkyzHre3PuqbazkJHn6Dc=.619e22e2-a670-4aa2-acdd-bd7c6ef2dd2c@github.com>

On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
> 
> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2940598911

From abarashev at openjdk.org  Wed Jun 18 20:46:28 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 20:46:28 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v4]
In-Reply-To: <TGSM3KuPzvC_wVIKIfXMO8MeOfUZUhMCLF6Y5U3tyOQ=.5f8ffa6d-c3ce-49f8-bea0-89e457bd3e21@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
 <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>
 <TGSM3KuPzvC_wVIKIfXMO8MeOfUZUhMCLF6Y5U3tyOQ=.5f8ffa6d-c3ce-49f8-bea0-89e457bd3e21@github.com>
Message-ID: <0VHE4ir0u_0NE9nLwjsxU8l77tbCpMagmlVA5iSa8Gw=.62daacaf-52dc-4a01-b8f1-e33e52f4fa4b@github.com>

On Wed, 18 Jun 2025 18:43:39 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests, one for each issue:
>> 
>> 1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
>> 2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.
>
> I see. You also have a 3rd: JDK-8359069. It's rare to see one PR fix multiple issues, even though skara supports it. I'm not sure I see specific advantages of having three separate issues instead of just one. Is it primarily because you see these as separate issues? In that case, does it make sense to fix this as 3 different issues in case one or more them needs to be selectively backported?

Done: all 3 issues have been combined into one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2155459746

From abarashev at openjdk.org  Wed Jun 18 20:55:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 20:55:13 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v7]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <CItvJMHc5QSFnWkhWptSLmaOycUv-ygTvq-HGQC9WoM=.81959bcc-efe8-4c74-a3a1-80f2e7172002@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Make certificate checking toggle specific to SunX509. Update issue number.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/eaf343ad..45a4a48e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=05-06

  Stats: 65 lines in 9 files changed: 18 ins; 6 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From abarashev at openjdk.org  Wed Jun 18 20:55:13 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 20:55:13 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v3]
In-Reply-To: <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
 <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
 <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>
Message-ID: <17Zm2X-YP4mMtlLIz4htH2qSpaUwEeqJpnS4yRq0UAI=.6af8d9ba-f831-4011-8677-ef9c00391a17@github.com>

On Fri, 6 Jun 2025 20:01:17 GMT, Hai-May Chao <hchao at openjdk.org> 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 property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> > > 
> > > 
> > > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> > > @seanjmullan What do you think?
> > 
> > 
> > Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.
> 
> I'd agree. As I mentioned in my earlier comment, if the new system property ends up toggling behavior in both `SunX509KeyManager` and `X509KeyManagerImpl`, we could run into an unintended side effect. While we're adding compliant algorithm constraints checking to `SunX509KeyManager`, turning on the property to disable it for compatibility reasons would also disable the already-existing checking in `X509KeyManagerImpl`. The applications already relying on the stricter checks in `X509KeyManagerImpl` might lose that enforcement unintentionally.

I made the toggle specific to SunX509 Key Manager as suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2985653083

From abarashev at openjdk.org  Wed Jun 18 21:12:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 21:12:51 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v8]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <xmD6zFsXfHAK3xD8Jkl2uuaJPCredOd91ZdzfiKiHek=.6c0fef48-48a7-4f86-822b-15d8a423b695@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Remove a couple of empty lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/45a4a48e..bcef7346

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=06-07

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From abarashev at openjdk.org  Wed Jun 18 21:35:47 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 18 Jun 2025 21:35:47 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update system property name in one more test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/bcef7346..a83ea8bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From serb at openjdk.org  Wed Jun 18 22:06:27 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Jun 2025 22:06:27 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
Message-ID: <utm5PdBH5cfS2la-oMs0UEE6kCfbqhfFGytFdboyipM=.2f1c38f1-3528-41d5-90d4-051b6a66a33e@github.com>

On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
> 
> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2940808857

From eirbjo at openjdk.org  Thu Jun 19 09:04:36 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 19 Jun 2025 09:04:36 GMT
Subject: Withdrawn: 8304065: HttpServer.stop should terminate immediately if no
 exchanges are in progress
In-Reply-To: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
References: <2Npic-M0k5PeOIVi10Vswokk6naB8u0fN2GQQKe1bNE=.49d4f6bc-f218-4e90-a85e-a0744ca4701c@github.com>
Message-ID: <Eh1TQfAhGlj0ly2pI-oxHw2otsVnuZ5kMu-71DyLhPc=.439d6d6f-6b3d-472c-a439-9eb6ebb0a186@github.com>

On Sat, 5 Apr 2025 10:23:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please help review this PR which improves `HttpServer::stop` termination timing to better fit user expectations.
> 
> This PR:
> 
> * Makes `ServerImpl::stop` continue without delay when there are no active exchanges during shutdown
> * Attempts to interrupt the dispatcher thread before joining it, giving long-living interruptible exchanges a chance to finish  early
> * Adds testing for boundary conditions with or without an active exchange, delay occurring before exhange completes and exchange completing before delay.
> 
> Additionally, `ServerImpl::stop` is updated to use `System::nanotime` instead of `System::currentTimeMillis` when calculating wait times.
> 
> The test relies on timing to assert the order of events. Not perfect, but it seems to work.
> 
> (This part of the code base is rather new to me. A bit of hand-holding should be expected when reviewing this PR)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24467

From michaelm at openjdk.org  Thu Jun 19 12:00:52 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 19 Jun 2025 12:00:52 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v9]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <ehjMwwDkFYildqSd6lmf_sUjQ6r6CJqT0Ea8tj6RMWo=.e62465e5-79cc-4557-9c97-52c84c7106ea@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  doc update from CSR review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/9ee697da..a6631ae4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=07-08

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From dfuchs at openjdk.org  Thu Jun 19 13:02:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 19 Jun 2025 13:02:31 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v9]
In-Reply-To: <ehjMwwDkFYildqSd6lmf_sUjQ6r6CJqT0Ea8tj6RMWo=.e62465e5-79cc-4557-9c97-52c84c7106ea@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <ehjMwwDkFYildqSd6lmf_sUjQ6r6CJqT0Ea8tj6RMWo=.e62465e5-79cc-4557-9c97-52c84c7106ea@github.com>
Message-ID: <BjHUb-V82aZ2KSooyD1B4xfQ4AxdSZtLz746sXYjr3Y=.954525d3-7ca9-4112-8d59-e8e39466beca@github.com>

On Thu, 19 Jun 2025 12:00:52 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   doc update from CSR review

LGTM. should we be more specific about the partial support?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2942937507

From michaelm at openjdk.org  Thu Jun 19 14:03:42 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 19 Jun 2025 14:03:42 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v10]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <RMT13w-ggtodwb_5m_m1Apow5C5JvaaG_H7bm1HrAy8=.2e6d4cf9-7576-4223-ace6-cab197f20126@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  apidoc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/a6631ae4..8d34be86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=08-09

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From michaelm at openjdk.org  Thu Jun 19 15:12:20 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 19 Jun 2025 15:12:20 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v11]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <iBx8ACEn6Jck-LlecIEOxJO5_6gB91p-Blv4T0mz20c=.97d2f3b5-e632-475b-8797-72f051a6ae42@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon 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 18 additional commits since the last revision:

 - Merge branch 'master' into cookie-8351983
 - apidoc update
 - doc update from CSR review
 - Merge branch 'master' into cookie-8351983
 - Revert "impl update"
   
   This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
 - impl update
 - test update
 - test and impl update
 - Merge branch 'master' into cookie-8351983
 - copyright
 - ... and 8 more: https://git.openjdk.org/jdk/compare/9342ad04...3b71e4ff

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/8d34be86..3b71e4ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=09-10

  Stats: 4662 lines in 102 files changed: 1609 ins; 2508 del; 545 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From alanb at openjdk.org  Thu Jun 19 15:49:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Jun 2025 15:49:34 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
Message-ID: <ar6-WGUAc5eX0kz9_ULqASAYVwpoVJLURNwXoyfrwoQ=.fb00c3f2-c74a-48d4-a9dd-23a34505bfbb@github.com>

On Wed, 18 Jun 2025 16:48:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworking comment and adjusting TODOs.

The changes looks mostly okay, just minor comments on comments, TODOs and naming.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 48:

> 46: 
> 47:     // ImageReader to access resources in jimage (never null).
> 48:     private static final ImageReader READER = ImageReaderFactory.getImageReader();

I think it simpler if you drop "(never null)".

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 50:

> 48:     private static final ImageReader READER = ImageReaderFactory.getImageReader();
> 49: 
> 50:     // The module and resource name in the URL ("jrt:/<module-name>/<resource-name>").

In JEP 220 we use jrt:/[$MODULE[/$PATH]] to make it clear that the resource is optionally.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:

> 54:     // about percent encoding, and it is likely that any differences between how
> 55:     // module names and resource names are treated is unintentional. The rules
> 56:     // about percent encoding may well be tightened up in the future.

I think it would be better to drop this paragraph from the comment, it just begs too many questions.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 64:

> 62: 
> 63:     // The resource node (when connected).
> 64:     private volatile Node resource;

Maybe better to rename to node, resourceNode, or imageNode here.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 69:

> 67:         super(url);
> 68:         // TODO: Allow percent encoding in module names.
> 69:         // TODO: Consider rejecting URLs with fragments, queries or authority.

I'd prefer not include all the TODO messages.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 78:

> 76:             // No trailing resource path. This can never "connect" or return a
> 77:             // resource, but might be useful as a representation to pass around.
> 78:             // The module name *can* be empty here (e.g. "jrt:/") but not null.

If the URL scheme from JEP 220 goes into the first comment then it will be clear that the resource is optionally. This will allow the comment here to be reduced.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25871#pullrequestreview-2943467201
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2157287702
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2157291827
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2157284956
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2157300971
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2157289343
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2157296409

From dfuchs at openjdk.org  Thu Jun 19 16:26:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 19 Jun 2025 16:26:30 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v11]
In-Reply-To: <iBx8ACEn6Jck-LlecIEOxJO5_6gB91p-Blv4T0mz20c=.97d2f3b5-e632-475b-8797-72f051a6ae42@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <iBx8ACEn6Jck-LlecIEOxJO5_6gB91p-Blv4T0mz20c=.97d2f3b5-e632-475b-8797-72f051a6ae42@github.com>
Message-ID: <AL6WwmyNwt-zcuGdM6-x0hA6Kf6C__DmZEp4czQidfM=.6296ea4a-65c2-4c86-985e-e2488419f356@github.com>

On Thu, 19 Jun 2025 15:12:20 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into cookie-8351983
>  - apidoc update
>  - doc update from CSR review
>  - Merge branch 'master' into cookie-8351983
>  - Revert "impl update"
>    
>    This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
>  - impl update
>  - test update
>  - test and impl update
>  - Merge branch 'master' into cookie-8351983
>  - copyright
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/21c5d8c9...3b71e4ff

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2943594878

From dnadeau at etsy.com  Thu Jun 19 17:08:12 2025
From: dnadeau at etsy.com (David Nadeau)
Date: Thu, 19 Jun 2025 10:08:12 -0700
Subject: Potential bug in HttpClientImpl: Thread pool rejection causes
 permanent client failure
In-Reply-To: <CA+mvrzCaQwjZ_Xy4VihBdh=XqFPM4NgOKnqvaZ+m7=FNZDFpjA@mail.gmail.com>
References: <CA+mvrzDa66HwJPUw+qZgH8ubtFVgWWa6CE+6SEQH2+GLqPAo7Q@mail.gmail.com>
 <e8528c9a-2022-44e8-a799-729faee91365@oracle.com>
 <CA+mvrzCaQwjZ_Xy4VihBdh=XqFPM4NgOKnqvaZ+m7=FNZDFpjA@mail.gmail.com>
Message-ID: <CA+mvrzCzB_4uKTWmhX+qMu3egz8L3+duKipPXg2VRL2gSokmcA@mail.gmail.com>

I do want to follow up on the expected behavior of HttpClient in this case.

If this kind of catastrophic failure within the HttpClient when using
ThreadPools with bounded queues is falling within the expected behaviors of
the HttpClient, then I believe it should be made explicitly clear on the
HttpClient.Builder.executor method javadoc, that ThreadPools with bounded
queues are not supported, and can lead to unrecoverable client failure if
used.

On Wed, Jun 18, 2025 at 11:19?AM David Nadeau <dnadeau at etsy.com> wrote:

> Hi Daniel,
>
> Thank you for this reply.
> In our case, the underlying thread pool doesn't typically become
> overloaded, but when it does, we?re forced to manually restart applications
> because the HttpClient becomes permanently stalled.
>
> Why is it that tasks need to be executed? Dropping work can be an
> acceptable means of backpressure for a threadpool. Are there some tasks
> that the HttpClient submits to this delegate threadpool which are essential
> for the client to continue behaving correctly? And dropping such a task
> could cause the client to continue working, but in a potentially broken way?
> If this is the case, it may be risky to apply my fix of switching to a
> DiscardPolicy. As this would allow the threadpool to silently drop work
> while keeping the http client open. I wonder if it would be safer to use
> your FJP idea to write a RejectedExceptionHandler that falls back to
> submitting rejected tasks there.
>
>
> On Wed, Jun 18, 2025 at 10:42?AM Daniel Fuchs <daniel.fuchs at oracle.com>
> wrote:
>
>> Hi David,
>>
>> As a general rule, the client doesn't expect tasks to
>> be rejected by the executor. Tasks need to be executed,
>> one way or another, for the client to work as expected.
>> Executing in the current thread is often not an option
>> as it may lead to deadlocks.
>> So if we get a RejectedTaskExection, we shutdown the
>> client, as there's not much else we can do.
>>
>> We have some contengency measure for shutdown in case of
>> RejectedTaskException that will temporarily execute rejected
>> tasks in the FJP instead when the executor rejects a task,
>> but this is only a best effort whose only goal is to make
>> it possible to complete the shutdown, and wakeup any calling
>> code that may be waiting on send or completable futures returned
>> by sendAsync.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 18/06/2025 17:24, David Nadeau wrote:
>> > When overriding the HttpClient executor with a custom
>> ThreadPoolExecutor
>> > that uses the default RejectedExecutionHandler.AbortPolicy, the Java
>> > HTTP client (java.net.http.HttpClient) becomes permanently unusable if
>> > the delegate executor rejects a task.
>> >
>> > This creates a situation where transient thread pool saturation results
>> > in a non-recoverable client failure.
>> >
>> > Reproduction of the issue:
>> > 1. The task rejection triggers a call to the error handler
>> (onSubmitFailure)
>> > 2. This calls selmgr.abort(failure) with the rejection exception
>> > 3. SelectorManager.abort() sets this.closed = true permanently
>> > 4. All subsequent HTTP operations fail with "IOException: selector
>> > manager closed"
>> >
>> > The client does not recover from this state.
>> >
>> > I was able to avoid this by using the DiscardPolicy instead of the
>> > AbortPolicy. However, this behavior was quite a surprise to debug. Is
>> > this behavior intentional, or does it make sense for the HttpClient to
>> > treat task rejection as a recoverable error?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250619/0a121532/attachment-0001.htm>

From daniel.fuchs at oracle.com  Thu Jun 19 17:56:15 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Jun 2025 18:56:15 +0100
Subject: [External] : Re: Potential bug in HttpClientImpl: Thread pool
 rejection causes permanent client failure
In-Reply-To: <CA+mvrzCzB_4uKTWmhX+qMu3egz8L3+duKipPXg2VRL2gSokmcA@mail.gmail.com>
References: <CA+mvrzDa66HwJPUw+qZgH8ubtFVgWWa6CE+6SEQH2+GLqPAo7Q@mail.gmail.com>
 <e8528c9a-2022-44e8-a799-729faee91365@oracle.com>
 <CA+mvrzCaQwjZ_Xy4VihBdh=XqFPM4NgOKnqvaZ+m7=FNZDFpjA@mail.gmail.com>
 <CA+mvrzCzB_4uKTWmhX+qMu3egz8L3+duKipPXg2VRL2gSokmcA@mail.gmail.com>
Message-ID: <1b52efcc-4a62-4ef5-ae35-ed6ca11dded7@oracle.com>

Hi David,

On 19/06/2025 18:08, David Nadeau wrote:
> I do want to follow up on the expected behavior of HttpClient in this case.
> 
> If this kind of catastrophic failure within the HttpClient when using 
> ThreadPools with bounded queues is falling within the expected behaviors 
> of the HttpClient, then I believe it should be made explicitly clear on 
> the HttpClient.Builder.executor method javadoc, that ThreadPools with 
> bounded queues are not supported, and can lead to unrecoverable client 
> failure if used.
> 

This is a fair point.
We should add an implNote about how the client uses its executor.

> 
> Why is it that tasks need to be executed? Dropping work can be an acceptable means of backpressure for a threadpool. Are there some tasks that the HttpClient submits to this delegate threadpool which are essential for the client to continue behaving correctly? And dropping such a task could cause the client to continue working, but in a potentially broken way?

Tasks submitted to the executor may include for instance,
processing data available for a given stream, completing
a BodySubscriber, etc... So they do need to be executed at
some point.

We have some tests that configure the HttpClient with small
thread pools (single threaded executor, or executor running
inline), but to use these you need to make sure that the
BodySubscribers/BodyPublishers you use will not make blocking
operations - as that could end up blocking the one thread available
to the client when invoking methods on these.

By design the tasks that the client submit should not block,
but they can invoke methods on BodyPublishers/BodySubscribers,
and some of these - like BodyPublishers.ofInputStream, or custom
body publishers or body handlers, may end up performing blocking
operations from tasks submitted to the executor.
In our plan for the future is evaluating to switch to using
VirtualThread executors by default, and that may alleviate
some of those issues.

You are raising an interesting point with your scenario though,
and I will need to think about it some more. At the moment though,
I don't think there's an immediate solution, except for instance,
delegating to the FJP.

best regards,

-- daniel

From aivanov at openjdk.org  Thu Jun 19 19:35:26 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jun 2025 19:35:26 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
Message-ID: <c60_VSGspLAOrnetmTt2N7O4W69LpU6Yg5v7CnVhqqE=.1db1e528-134c-4940-8133-1927270c4eb8@github.com>

On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
> 
> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

You should bump the copyright year in `JNICheck.sh`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2943885449

From aivanov at openjdk.org  Thu Jun 19 19:35:27 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jun 2025 19:35:27 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code
In-Reply-To: <pt7sk9C5zmTJ-OtTTNgW2sVMu_yhEZpjjF_nUM1dNG0=.ae0a2ae9-5ef7-4875-b3de-df7ea87b8c04@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>
 <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com>
 <pt7sk9C5zmTJ-OtTTNgW2sVMu_yhEZpjjF_nUM1dNG0=.ae0a2ae9-5ef7-4875-b3de-df7ea87b8c04@github.com>
Message-ID: <Ie9hzKFASSA67WUgTDZYn3UzZsyqr3iudmd73kQ0uYQ=.9c36d084-db3b-4f44-95eb-2fc5c072df61@github.com>

On Thu, 12 Jun 2025 12:44:12 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> If this check is not needed, then why are we adding it?
>
> just so we don't forget to add it when we modify the enclosing function. The call to `CallStaticBooleanMethod` is located pretty far from the end of the function, and can be easy to miss.

> it wasn't always the case

Does it mean that there was another up-call into Java before this method returns?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2157560846

From vyazici at openjdk.org  Fri Jun 20 07:37:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 20 Jun 2025 07:37:30 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v11]
In-Reply-To: <iBx8ACEn6Jck-LlecIEOxJO5_6gB91p-Blv4T0mz20c=.97d2f3b5-e632-475b-8797-72f051a6ae42@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <iBx8ACEn6Jck-LlecIEOxJO5_6gB91p-Blv4T0mz20c=.97d2f3b5-e632-475b-8797-72f051a6ae42@github.com>
Message-ID: <loUayI3rMK4iAV5DEdMiMI-6a0oRBx8OXS7JbCZOQ8E=.548338d0-987c-454b-a793-2e150b682e10@github.com>

On Thu, 19 Jun 2025 15:12:20 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
>> are present in a cookie, the Max-Age should take precedence.
>> 
>> Thanks
>> Michael
>
> Michael McMahon 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 18 additional commits since the last revision:
> 
>  - Merge branch 'master' into cookie-8351983
>  - apidoc update
>  - doc update from CSR review
>  - Merge branch 'master' into cookie-8351983
>  - Revert "impl update"
>    
>    This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
>  - impl update
>  - test update
>  - test and impl update
>  - Merge branch 'master' into cookie-8351983
>  - copyright
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/1356652f...3b71e4ff

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2944873085

From dfuchs at openjdk.org  Fri Jun 20 08:51:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 20 Jun 2025 08:51:28 GMT
Subject: [jdk25] RFR: 8359709: java.net.HttpURLConnection sends unexpected
 "Host" request header in some cases after JDK-8344190
In-Reply-To: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
References: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
Message-ID: <Expx_cMbUz6z5at2ivOtZ0DKGlLqpB6GDyALOmCFhHo=.6ca57369-9089-4b45-83cb-2eafc997f299@github.com>

On Wed, 18 Jun 2025 09:16:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport to JDK 25 for https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression that was introduced in JDK 24. The mainline fix was integrated a few mintues back through https://github.com/openjdk/jdk/pull/25844.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25867#pullrequestreview-2945077294

From jpai at openjdk.org  Fri Jun 20 09:50:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 20 Jun 2025 09:50:34 GMT
Subject: [jdk25] Integrated: 8359709: java.net.HttpURLConnection sends
 unexpected "Host" request header in some cases after JDK-8344190
In-Reply-To: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
References: <VGrfdjOUmKqNZ3pyJ5BfIJmyIP5uvbY9Yr6KPS93X9k=.705a4f3e-5374-4799-9f7f-f9c09f8e69c6@github.com>
Message-ID: <LoAHEb9B9rdvw91D9vkSSOQnHxqAk5S5VFBpYrbgUjY=.b720fa0c-6f4b-4a07-b7a5-d1d16931e0c8@github.com>

On Wed, 18 Jun 2025 09:16:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this backport to JDK 25 for https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression that was introduced in JDK 24. The mainline fix was integrated a few mintues back through https://github.com/openjdk/jdk/pull/25844.

This pull request has now been integrated.

Changeset: 41928aed
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41928aed7dce0cc15be95f1552e6d62c18e9eea1
Stats:     147 lines in 2 files changed: 143 ins; 0 del; 4 mod

8359709: java.net.HttpURLConnection sends unexpected "Host" request header in some cases after JDK-8344190

Reviewed-by: dfuchs
Backport-of: 57266064a7bb995c3c614c19b936687af35e9aa4

-------------

PR: https://git.openjdk.org/jdk/pull/25867

From duke at openjdk.org  Fri Jun 20 10:59:34 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 20 Jun 2025 10:59:34 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <ar6-WGUAc5eX0kz9_ULqASAYVwpoVJLURNwXoyfrwoQ=.fb00c3f2-c74a-48d4-a9dd-23a34505bfbb@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
 <ar6-WGUAc5eX0kz9_ULqASAYVwpoVJLURNwXoyfrwoQ=.fb00c3f2-c74a-48d4-a9dd-23a34505bfbb@github.com>
Message-ID: <imHtkCfqSNecmyEwWgpDdI0Nr96-Nd5eNtY7GQns6bw=.2d8b52af-a4aa-4ec0-85e4-8015975b87a3@github.com>

On Thu, 19 Jun 2025 15:36:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reworking comment and adjusting TODOs.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 48:
> 
>> 46: 
>> 47:     // ImageReader to access resources in jimage (never null).
>> 48:     private static final ImageReader READER = ImageReaderFactory.getImageReader();
> 
> I think it simpler if you drop "(never null)".

I was just stressing that (unlike the old code) there's actually no need for a null check.

> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 50:
> 
>> 48:     private static final ImageReader READER = ImageReaderFactory.getImageReader();
>> 49: 
>> 50:     // The module and resource name in the URL ("jrt:/<module-name>/<resource-name>").
> 
> In JEP 220 we use jrt:/[$MODULE[/$PATH]] to make it clear that the resource is optionally.

Well the resource is optional only it the same way that you can given any invalid URL. Connection only works when both a module and a resource name are present.

> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:
> 
>> 54:     // about percent encoding, and it is likely that any differences between how
>> 55:     // module names and resource names are treated is unintentional. The rules
>> 56:     // about percent encoding may well be tightened up in the future.
> 
> I think it would be better to drop this paragraph from the comment, it just begs too many questions.

Okay. This will become moot when the URL encoding is tidied up.

> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 64:
> 
>> 62: 
>> 63:     // The resource node (when connected).
>> 64:     private volatile Node resource;
> 
> Maybe better to rename to node, resourceNode, or imageNode here.

Done (resourceNode).

> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 69:
> 
>> 67:         super(url);
>> 68:         // TODO: Allow percent encoding in module names.
>> 69:         // TODO: Consider rejecting URLs with fragments, queries or authority.
> 
> I'd prefer not include all the TODO messages.

These were here explicitly to be discussed in review. If you think it's now covered by JDK-8359949, I can remove them.

> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 78:
> 
>> 76:             // No trailing resource path. This can never "connect" or return a
>> 77:             // resource, but might be useful as a representation to pass around.
>> 78:             // The module name *can* be empty here (e.g. "jrt:/") but not null.
> 
> If the URL scheme from JEP 220 goes into the first comment then it will be clear that the resource is optionally. This will allow the comment here to be reduced.

Can you elaborate? I'm not quite clear what changes you're suggesting here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158674474
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158681461
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158672447
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158683837
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158677926
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158683599

From duke at openjdk.org  Fri Jun 20 11:13:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 20 Jun 2025 11:13:12 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  Feedback changes and renaming field to match nomenclature of JEP 220.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25871/files
  - new: https://git.openjdk.org/jdk/pull/25871/files/3bafc256..930aa2c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=01-02

  Stats: 27 lines in 1 file changed: 2 ins; 11 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25871/head:pull/25871

PR: https://git.openjdk.org/jdk/pull/25871

From duke at openjdk.org  Fri Jun 20 11:13:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 20 Jun 2025 11:13:12 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
Message-ID: <JwFShkIrkJHaxa4Ud-Ez73OTIw0cHhXIjYY9u3qg1Rc=.d6b93fbd-9cbf-4d03-98ff-57f5dbebaac5@github.com>

On Wed, 18 Jun 2025 16:48:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reworking comment and adjusting TODOs.

Changes made. I also renamed the "name" field to "path" since that better matches JEP 220 (thanks for pointing me at that).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25871#issuecomment-2991019713

From duke at openjdk.org  Fri Jun 20 11:13:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 20 Jun 2025 11:13:12 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <imHtkCfqSNecmyEwWgpDdI0Nr96-Nd5eNtY7GQns6bw=.2d8b52af-a4aa-4ec0-85e4-8015975b87a3@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
 <ar6-WGUAc5eX0kz9_ULqASAYVwpoVJLURNwXoyfrwoQ=.fb00c3f2-c74a-48d4-a9dd-23a34505bfbb@github.com>
 <imHtkCfqSNecmyEwWgpDdI0Nr96-Nd5eNtY7GQns6bw=.2d8b52af-a4aa-4ec0-85e4-8015975b87a3@github.com>
Message-ID: <mG8PUt7QHl0ZMoL0XU17DqrknPLgJq2nEcknala952Y=.1e9838d0-3c81-4d64-b2f7-36234edd9f2f@github.com>

On Fri, 20 Jun 2025 10:55:53 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 50:
>> 
>>> 48:     private static final ImageReader READER = ImageReaderFactory.getImageReader();
>>> 49: 
>>> 50:     // The module and resource name in the URL ("jrt:/<module-name>/<resource-name>").
>> 
>> In JEP 220 we use jrt:/[$MODULE[/$PATH]] to make it clear that the resource is optionally.
>
> Well the resource is optional only it the same way that you can given any invalid URL. Connection only works when both a module and a resource name are present.

I updated this and added a direct link to the JEP in the class JavaDoc. It would have been nice if I'd known that when first looking at the class, so it seems right to add it for the next person.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2158704307

From abarashev at openjdk.org  Fri Jun 20 13:42:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 20 Jun 2025 13:42:36 GMT
Subject: Withdrawn: 8272875: Change the default key manager to PKIX
In-Reply-To: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
References: <WqCZ5uzBj7ML8aTXFfBc0B3Gjp3JV4YMZtiCANp8-tg=.2322b2ea-bea8-45de-8d62-75dd4afdfee7@github.com>
Message-ID: <mrHG6zoCSxEes_4_GRKlqRujjCNJ0J0afs1A_92m_V8=.995e657a-70ff-4b79-bbee-ee77ed2d3c6f@github.com>

On Fri, 18 Apr 2025 17:04:56 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> The current key manager is SunX509, which is configured in the java.security. The SunX509 algorithm does not check the local certificate. The PKIX algorithm should be preferred now so that the default key manager could be more robust.
> 
> Compatibility considerations:
> 
> 1) Customers using local certificates signed using algorithms prohibited by the default configuration (notably MD5 and SHA1) no longer will be able to use such certificates without modifying algorithm constraints in `java.security` config file.
> 
> 2) Performance impact: there is about x2 performance decrease for full (non-resume) TLS handshake:
> 
> **SUNX509**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> Finished running test 'micro:java.security.SSLHandshake'
> 
> **PKIX**
> Benchmark                                   (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19724.887 ? 393.636  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1848.927 ?  22.946  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15    **511.684** ?   5.405  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15    **490.698** ?   6.453  ops/s
> Finished running test 'micro:java.security.SSLHandshake'

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24756

From mullan at openjdk.org  Fri Jun 20 14:06:30 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Jun 2025 14:06:30 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
Message-ID: <Nj_wsnpaRUsX_01s9rQzjBx-uFjRjMX5Q8VRQ6gW4Wg=.0a058d5a-698a-4d5b-ad53-ff9e2a56fa9f@github.com>

On Wed, 18 Jun 2025 21:35:47 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update system property name in one more test

test/jdk/sun/security/mscapi/ShortRSAKeyWithinTLS.java line 238:

> 236:         // Disable KeyManager's algorithm constraints checking.
> 237:         System.setProperty(
> 238:                 "jdk.tls.SunX509keymanager.certSelectionChecking", "false");

What if you instead just removed "RSA keySize < 1024" from the `jdk.certpath.disabledAlgorithms` security property - would this test still pass? This way you could still test the other parts of the cert selection code.

This same comment applies to other tests where you have set the `jdk.tls.SunX509keymanager.certSelectionChecking` property to false.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2159064375

From rriggs at openjdk.org  Fri Jun 20 16:37:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Jun 2025 16:37:32 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
Message-ID: <wYutczwbD_BZBbvnaKO1I_lz9eySW3G9yjLsEVi2bos=.13b72cc2-8b0e-42eb-8c4e-84f0b9caadd1@github.com>

On Wed, 18 Jun 2025 13:00:54 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes and renaming field to match nomenclature of JEP 220.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 119:
> 
>> 117:     public long getContentLengthLong() {
>> 118:         try {
>> 119:             return getResourceNode().size();
> 
> Having getResourceNode() return the (lazily fetched) node avoids the reader needing to know/reason about how "connect()" has the side-effect of making the "resource" field non-null.

It looks like ExplodedImage.PathNode.size() throws UncheckedIOException. That might need mapping back to IOException to get the -1 return consistently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159332017

From rriggs at openjdk.org  Fri Jun 20 16:37:34 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Jun 2025 16:37:34 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
Message-ID: <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>

On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes and renaming field to match nomenclature of JEP 220.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 128:

> 126:         if (path.indexOf('%') == -1) {
> 127:             // Nothing to decode (overwhelmingly common case).
> 128:             return path;

Does this make a performance difference, checking for '%' is the first thing in ParseUtil.decode.
It seems redundant to check here too.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 133:

> 131:             return ParseUtil.decode(path);
> 132:         } catch (IllegalArgumentException e) {
> 133:             throw new MalformedURLException(e.getMessage());

The old code treated this as fatal, throwing InternalError.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159338022
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159344192

From mullan at openjdk.org  Fri Jun 20 17:46:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 20 Jun 2025 17:46:29 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
Message-ID: <yn66u1uUdFex4WBoWkdsYDgCKEn_daa5tWyyo0a5AXc=.0301c6ca-e2bc-4520-bd26-8373e6b059d7@github.com>

On Wed, 18 Jun 2025 21:35:47 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
>> 
>> Effectively there should be only 2 differences between 2 key managers:
>> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
>> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
>> 
>> **SUNX509 KeyManager performance before the change**
>> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
>> 
>> **SUNX509 KeyManager performance after the change**
>> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
>> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
>> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
>> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
>> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update system property name in one more test

Please create a CSR for the new system property.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2992372380

From abarashev at openjdk.org  Fri Jun 20 18:01:35 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 20 Jun 2025 18:01:35 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v9]
In-Reply-To: <Nj_wsnpaRUsX_01s9rQzjBx-uFjRjMX5Q8VRQ6gW4Wg=.0a058d5a-698a-4d5b-ad53-ff9e2a56fa9f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <Wk3mID89LSc507djvwGD-N8zcCTMavNardIEBNXQu1o=.aeb21f71-7a11-4122-86a2-e695ad236bc5@github.com>
 <Nj_wsnpaRUsX_01s9rQzjBx-uFjRjMX5Q8VRQ6gW4Wg=.0a058d5a-698a-4d5b-ad53-ff9e2a56fa9f@github.com>
Message-ID: <WEq9BBuYe8Xwfw8JWjKYT8UXtQMl4bIlWuN79RDFSVQ=.bb8c35f6-3cf9-4f62-89ab-6aeb4b02c92f@github.com>

On Fri, 20 Jun 2025 13:58:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update system property name in one more test
>
> test/jdk/sun/security/mscapi/ShortRSAKeyWithinTLS.java line 238:
> 
>> 236:         // Disable KeyManager's algorithm constraints checking.
>> 237:         System.setProperty(
>> 238:                 "jdk.tls.SunX509keymanager.certSelectionChecking", "false");
> 
> What if you instead just removed "RSA keySize < 1024" from the `jdk.certpath.disabledAlgorithms` security property - would this test still pass? This way you could still test the other parts of the cert selection code.
> 
> This same comment applies to other tests where you have set the `jdk.tls.SunX509keymanager.certSelectionChecking` property to false.

Done, good point! It works for this particular test but the same approach doesn't work for other tests because they either rely on TrustManager do the constraints checks or MD5 algorithm being blocks by TLSv1.3 spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2159457776

From abarashev at openjdk.org  Fri Jun 20 18:07:12 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 20 Jun 2025 18:07:12 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v10]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <ycKcCQF-z6xYt06nl3sc1RPlZdzUGDsVf8_E09nEd80=.821aa0e5-00c8-41c2-8579-e9b8d214628d@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Update unit tests. Some code refactoring.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/a83ea8bd..c5e381ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=08-09

  Stats: 184 lines in 5 files changed: 90 ins; 87 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From alanb at openjdk.org  Sat Jun 21 08:29:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 08:29:41 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <imHtkCfqSNecmyEwWgpDdI0Nr96-Nd5eNtY7GQns6bw=.2d8b52af-a4aa-4ec0-85e4-8015975b87a3@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
 <ar6-WGUAc5eX0kz9_ULqASAYVwpoVJLURNwXoyfrwoQ=.fb00c3f2-c74a-48d4-a9dd-23a34505bfbb@github.com>
 <imHtkCfqSNecmyEwWgpDdI0Nr96-Nd5eNtY7GQns6bw=.2d8b52af-a4aa-4ec0-85e4-8015975b87a3@github.com>
Message-ID: <uK6K7tg-MeQDFMZh9LMJcm1GAZXRkyneQru4kWYGho8=.5e69004e-9b7a-4fd0-bbd1-4ebb18fe7dbc@github.com>

On Fri, 20 Jun 2025 10:54:09 GMT, David Beaumont <duke at openjdk.org> wrote:

> These were here explicitly to be discussed in review. If you think it's now covered by JDK-8359949, I can remove them.

Okay, it's just that they initially make it look like the PR is not ready for review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159977074

From alanb at openjdk.org  Sat Jun 21 08:49:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 08:49:37 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
Message-ID: <HQSVU4Bxg04ocT1c4NNAgCFdw3SjiLXTv3wqO1k2Ays=.42465a97-8674-4f46-a220-7e020ae44a34@github.com>

On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes and renaming field to match nomenclature of JEP 220.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 60:

> 58: 
> 59:     // The resource node (when connected).
> 60:     private volatile Node resourceNode;

Did you mean to keep this as a volatile field? The only access right seems to be in the synchronized getResourceNode method but maybe it was accessed without the lock in a previous version?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159980743

From alanb at openjdk.org  Sat Jun 21 08:54:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 08:54:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>
Message-ID: <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>

On Fri, 20 Jun 2025 16:24:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes and renaming field to match nomenclature of JEP 220.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 128:
> 
>> 126:         if (path.indexOf('%') == -1) {
>> 127:             // Nothing to decode (overwhelmingly common case).
>> 128:             return path;
> 
> Does this make a performance difference, checking for '%' is the first thing in ParseUtil.decode.
> It seems redundant to check here too.

The jrt protocol handler only exists because a URL streams a corresponding URLStreamHandler. It's not clear if the protocol handler is actually used. So I don't expect it is performance critical.

> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 133:
> 
>> 131:             return ParseUtil.decode(path);
>> 132:         } catch (IllegalArgumentException e) {
>> 133:             throw new MalformedURLException(e.getMessage());
> 
> The old code treated this as fatal, throwing InternalError.

MalformedURLException seems better here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159981566
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159981211

From alanb at openjdk.org  Sat Jun 21 08:58:29 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 08:58:29 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
Message-ID: <59yoxMYtc3oTUUKYMZjcebWvZW7N4bm3wuQPdNq_mag=.df2d558f-5c0b-419c-a6a5-e4de60d6a35c@github.com>

On Wed, 18 Jun 2025 12:55:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes and renaming field to match nomenclature of JEP 220.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 56:
> 
>> 54: 
>> 55:     // the Resource when connected
>> 56:     private volatile Resource resource;
> 
> The Resource API was never needed here and adds uncalled methods such as `getURL()` which are then implemented with code that could never be invoked.

I suspect it was needed when the protocol handler was initially created. It should have probably been cleaned up before it was brought to main line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159982448

From alanb at openjdk.org  Sat Jun 21 09:08:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 09:08:38 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
Message-ID: <aQYGntSifVoTsmu7VMWEouVfdFkiLSQud1TKrWddnzY=.d3d5f939-2a31-4f1c-b735-a09d8093a6ba@github.com>

On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes and renaming field to match nomenclature of JEP 220.

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 87:

> 85:         if (resourceNode == null) {
> 86:             if (path == null) {
> 87:                 throw new IOException("cannot connect to jrt:/" + module);

Maybe we can make this `module.isEmpty() || (path == null)` as it needs a non-empty module and resource to connect.

test/jdk/sun/net/www/protocol/jrt/Basic.java line 64:

> 62:                 {"jrt:/java.base/", false},
> 63:                 // Cannot escape anything in the module name.
> 64:                 {"jrt:/java%2Ebase/java/lang/Object.class", false},

Can you add "jrt:/" to the list?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159983831
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159984206

From alanb at openjdk.org  Sat Jun 21 09:08:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Jun 2025 09:08:38 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
Message-ID: <cWk6rsI8rqIYyZ7JNtihP0SoAA5LeqGhiMzAsy5XXOU=.192d634e-ba0f-4d22-92ba-2455a4cffb8d@github.com>

On Wed, 18 Jun 2025 12:58:29 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes and renaming field to match nomenclature of JEP 220.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 101:
> 
>> 99:             }
>> 100:             this.resource = node;
>> 101:             super.connected = true;
> 
> I know I don't *need* to use super here, but it documents the fact that this is not a field of this subclass, without readers having to go check. Mutable protected fields are weird and error prone, so I felt calling it out a bit was worth it. Happy to replace with a comment if people feel that's better though.

Sadly, many of the JDK 1.0 era APIs expose protected fields for subclasses, in this case URLConnection.

One thing that is a bit icky is for a getXXX method to have the side effect to set this field. Maybe this is connectNode or something to suggest it connects the URLConnection?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2159984080

From djelinski at openjdk.org  Mon Jun 23 08:32:51 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Jun 2025 08:32:51 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code [v2]
In-Reply-To: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
Message-ID: <Egd5EWXLdOsaxcjLcFloyOMZMgIiKgVXL2voVJceYKA=.7f54d7df-5a6c-4517-9f26-0e20110205c3@github.com>

> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
> 
> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25754/files
  - new: https://git.openjdk.org/jdk/pull/25754/files/4f508157..53b8f84b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25754&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25754&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25754/head:pull/25754

PR: https://git.openjdk.org/jdk/pull/25754

From djelinski at openjdk.org  Mon Jun 23 08:32:51 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Jun 2025 08:32:51 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code [v2]
In-Reply-To: <utm5PdBH5cfS2la-oMs0UEE6kCfbqhfFGytFdboyipM=.2f1c38f1-3528-41d5-90d4-051b6a66a33e@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <utm5PdBH5cfS2la-oMs0UEE6kCfbqhfFGytFdboyipM=.2f1c38f1-3528-41d5-90d4-051b6a66a33e@github.com>
Message-ID: <CiDkYrlQNRFvaJxMmW11qyAlx_j7_xMlBnbrv4c8070=.487a49da-8acf-4831-9dc9-738cc64dc2e0@github.com>

On Wed, 18 Jun 2025 22:04:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> Marked as reviewed by serb (Reviewer).

Thanks @mrserb @prrace @aivanov-jdk for the reviews!

Copyright year updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25754#issuecomment-2995444356

From djelinski at openjdk.org  Mon Jun 23 08:32:52 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 23 Jun 2025 08:32:52 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code [v2]
In-Reply-To: <Ie9hzKFASSA67WUgTDZYn3UzZsyqr3iudmd73kQ0uYQ=.9c36d084-db3b-4f44-95eb-2fc5c072df61@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>
 <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com>
 <pt7sk9C5zmTJ-OtTTNgW2sVMu_yhEZpjjF_nUM1dNG0=.ae0a2ae9-5ef7-4875-b3de-df7ea87b8c04@github.com>
 <Ie9hzKFASSA67WUgTDZYn3UzZsyqr3iudmd73kQ0uYQ=.9c36d084-db3b-4f44-95eb-2fc5c072df61@github.com>
Message-ID: <_F9C0U0OL9cONH_33a6rIwrqrurokPIwKTmp3zV9x_c=.c4b8dd8c-d03e-4651-b99f-4e0c00a756ca@github.com>

On Thu, 19 Jun 2025 19:32:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> just so we don't forget to add it when we modify the enclosing function. The call to `CallStaticBooleanMethod` is located pretty far from the end of the function, and can be easy to miss.
>
>> it wasn't always the case
> 
> Does it mean that there was another up-call into Java before this method returns?

yes, at least on Solaris we used to call other JNI methods after this one, see `parseExclusiveBindProperty` before 071bd521bca2485c6df95c45e4310d39b05bd046

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2161025223

From duke at openjdk.org  Mon Jun 23 10:58:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 10:58:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>
 <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>
Message-ID: <8nRs1GFxt__bdvf85L3IUCKmlWmPUYztN0bItrQ4Juc=.91785f87-9030-4675-b0e4-3ca08e93883f@github.com>

On Sat, 21 Jun 2025 08:51:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 128:
>> 
>>> 126:         if (path.indexOf('%') == -1) {
>>> 127:             // Nothing to decode (overwhelmingly common case).
>>> 128:             return path;
>> 
>> Does this make a performance difference, checking for '%' is the first thing in ParseUtil.decode.
>> It seems redundant to check here too.
>
> The jrt protocol handler only exists because a URL streams a corresponding URLStreamHandler. It's not clear if the protocol handler is actually used. So I don't expect it is performance critical.

This is here because I expect we will want to do something else in the "slow" path where '%' is present.
I wanted to put an 'X' in the code where any additional logic around decoding goes, and none of that needs to happen if no '%' chars exist.
For example, I think that we probably need to "worry about" %2F in the path, since that's not a synonym for '/' according to the URI specification.
I can back this out for now if you want (please say one way of the other), but given we never create paths with '%' in, it won't affect anything for any case we care about (if this wasn't here then the decode call would do it anyway).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161321416

From duke at openjdk.org  Mon Jun 23 11:03:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 11:03:32 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <HQSVU4Bxg04ocT1c4NNAgCFdw3SjiLXTv3wqO1k2Ays=.42465a97-8674-4f46-a220-7e020ae44a34@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <HQSVU4Bxg04ocT1c4NNAgCFdw3SjiLXTv3wqO1k2Ays=.42465a97-8674-4f46-a220-7e020ae44a34@github.com>
Message-ID: <fu5wwh1ZdtJ3dFS7Ilm10iln4EtcskY6HfHTVzc2ecQ=.c5a00807-0ba3-4d38-9aaf-a6f88d4b9d31@github.com>

On Sat, 21 Jun 2025 08:47:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes and renaming field to match nomenclature of JEP 220.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 60:
> 
>> 58: 
>> 59:     // The resource node (when connected).
>> 60:     private volatile Node resourceNode;
> 
> Did you mean to keep this as a volatile field? The only access right seems to be in the synchronized getResourceNode method but maybe it was accessed without the lock in a previous version?

Yeah, I can't see any reason to keep this, but didn't want to risk touching it.
If you are happy to remove it, I will be happy to do so (I don't like unexplained/uncommented things like this).

> test/jdk/sun/net/www/protocol/jrt/Basic.java line 64:
> 
>> 62:                 {"jrt:/java.base/", false},
>> 63:                 // Cannot escape anything in the module name.
>> 64:                 {"jrt:/java%2Ebase/java/lang/Object.class", false},
> 
> Can you add "jrt:/" to the list?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161329951
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161330323

From duke at openjdk.org  Mon Jun 23 11:03:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 11:03:32 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>
 <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>
Message-ID: <bm2e5p2FDuLnqW-cMe8-JVs_a2kLKaqG_RKRI4fSPoQ=.11984aff-91f7-4e45-b33a-94040526f397@github.com>

On Sat, 21 Jun 2025 08:50:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 133:
>> 
>>> 131:             return ParseUtil.decode(path);
>>> 132:         } catch (IllegalArgumentException e) {
>>> 133:             throw new MalformedURLException(e.getMessage());
>> 
>> The old code treated this as fatal, throwing InternalError.
>
> MalformedURLException seems better here.

Yes, but is that good though? This is a public API and surely as a random user I shouldn't be able to trigger an `Error` just by having bad input data?
Since we can reasonably reason that, to a first approximation, "this code path isn't being hit by anyone" it felt reasonable to reflect "bad input data" with a MalformedURLException.
Shall I change it back?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161328242

From duke at openjdk.org  Mon Jun 23 11:06:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 11:06:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <aQYGntSifVoTsmu7VMWEouVfdFkiLSQud1TKrWddnzY=.d3d5f939-2a31-4f1c-b735-a09d8093a6ba@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <aQYGntSifVoTsmu7VMWEouVfdFkiLSQud1TKrWddnzY=.d3d5f939-2a31-4f1c-b735-a09d8093a6ba@github.com>
Message-ID: <7b2kNhFqeDmpUPoOSyxPPz744sHIdV8SjgoebW8py5g=.4aca1e92-b76d-4d37-9f12-f2082591de92@github.com>

On Sat, 21 Jun 2025 09:03:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback changes and renaming field to match nomenclature of JEP 220.
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 87:
> 
>> 85:         if (resourceNode == null) {
>> 86:             if (path == null) {
>> 87:                 throw new IOException("cannot connect to jrt:/" + module);
> 
> Maybe we can make this `module.isEmpty() || (path == null)` as it needs a non-empty module and resource to connect.

Good point. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161334893

From duke at openjdk.org  Mon Jun 23 11:12:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 11:12:32 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <fu5wwh1ZdtJ3dFS7Ilm10iln4EtcskY6HfHTVzc2ecQ=.c5a00807-0ba3-4d38-9aaf-a6f88d4b9d31@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <HQSVU4Bxg04ocT1c4NNAgCFdw3SjiLXTv3wqO1k2Ays=.42465a97-8674-4f46-a220-7e020ae44a34@github.com>
 <fu5wwh1ZdtJ3dFS7Ilm10iln4EtcskY6HfHTVzc2ecQ=.c5a00807-0ba3-4d38-9aaf-a6f88d4b9d31@github.com>
Message-ID: <pflW8gLt8fySVapm8s-IcREK7JkF048LfmJePcCURL8=.a39c40a7-bbcc-404e-b899-631d13766bc6@github.com>

On Mon, 23 Jun 2025 11:01:02 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 60:
>> 
>>> 58: 
>>> 59:     // The resource node (when connected).
>>> 60:     private volatile Node resourceNode;
>> 
>> Did you mean to keep this as a volatile field? The only access right seems to be in the synchronized getResourceNode method but maybe it was accessed without the lock in a previous version?
>
> Yeah, I can't see any reason to keep this, but didn't want to risk touching it.
> If you are happy to remove it, I will be happy to do so (I don't like unexplained/uncommented things like this).

I removed it. It really can't be making any difference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161344204

From duke at openjdk.org  Mon Jun 23 11:16:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 11:16:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <wYutczwbD_BZBbvnaKO1I_lz9eySW3G9yjLsEVi2bos=.13b72cc2-8b0e-42eb-8c4e-84f0b9caadd1@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <ZqF9kr41nX-PS4A_g_j7TMZ8v-QG8RKb_9W7QDopNHo=.164d5e13-1c34-4dbd-9a7b-332144b94048@github.com>
 <wYutczwbD_BZBbvnaKO1I_lz9eySW3G9yjLsEVi2bos=.13b72cc2-8b0e-42eb-8c4e-84f0b9caadd1@github.com>
Message-ID: <93f8b_6fxR4lYrLh_jDqKSmZhjnYSCAZ4oIsa_RVLeQ=.b70a9ac3-c551-42d9-b830-c118476fa75e@github.com>

On Fri, 20 Jun 2025 16:20:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 119:
>> 
>>> 117:     public long getContentLengthLong() {
>>> 118:         try {
>>> 119:             return getResourceNode().size();
>> 
>> Having getResourceNode() return the (lazily fetched) node avoids the reader needing to know/reason about how "connect()" has the side-effect of making the "resource" field non-null.
>
> It looks like ExplodedImage.PathNode.size() throws UncheckedIOException. That might need mapping back to IOException to get the -1 return consistently.

Done. That's a good spot (I comment it since it's a real gotcha otherwise).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161351498

From duke at openjdk.org  Mon Jun 23 11:20:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 11:20:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
Message-ID: <jJd8HZXux58VJwQcUHu-cY-9pITP2-0jE_e3JgNPmXc=.e8e1cb29-488f-424a-a6e8-c8fae01cfd41@github.com>

On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes and renaming field to match nomenclature of JEP 220.

Updated wrt to comments, but still a couple of outstanding questions:
1. InternalError vs MalformedURLException for "junk" input (raised by Roger) ?
2. Not 100% sure about Alan's comment (now outdated) "If the URL scheme from JEP 220 goes into the first comment then it will be clear that the resource is optionally."
3. Should I revert the explicit fast-path test until some non-default percent encoding logic is decided upon (raised by Roger) ?

Other than that, I think I've covered everything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25871#issuecomment-2996019859

From aivanov at openjdk.org  Mon Jun 23 13:44:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 13:44:29 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code [v2]
In-Reply-To: <Egd5EWXLdOsaxcjLcFloyOMZMgIiKgVXL2voVJceYKA=.7f54d7df-5a6c-4517-9f26-0e20110205c3@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <Egd5EWXLdOsaxcjLcFloyOMZMgIiKgVXL2voVJceYKA=.7f54d7df-5a6c-4517-9f26-0e20110205c3@github.com>
Message-ID: <EgwLxv3GIasFJhk_1e9eVZEihXg1h_Uxqu9eTEzY3AQ=.b36d0d46-e33b-4981-91cd-4285ab2b8a3d@github.com>

On Mon, 23 Jun 2025 08:32:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
>> 
>> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25754#pullrequestreview-2950185657

From aivanov at openjdk.org  Mon Jun 23 13:49:28 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 13:49:28 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code [v2]
In-Reply-To: <_F9C0U0OL9cONH_33a6rIwrqrurokPIwKTmp3zV9x_c=.c4b8dd8c-d03e-4651-b99f-4e0c00a756ca@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <RvCzgX9Wnl2a5cPMz7_5zklRszjYKYjvs7igbNZypv0=.26608f8f-0e88-4d7a-817d-584570c9f035@github.com>
 <9gvW-a63lsaKMcvUZrYUFwyB3-EJNs42896HUHNpwng=.f140d758-4761-41d8-8e58-d75aa2a8ad34@github.com>
 <pt7sk9C5zmTJ-OtTTNgW2sVMu_yhEZpjjF_nUM1dNG0=.ae0a2ae9-5ef7-4875-b3de-df7ea87b8c04@github.com>
 <Ie9hzKFASSA67WUgTDZYn3UzZsyqr3iudmd73kQ0uYQ=.9c36d084-db3b-4f44-95eb-2fc5c072df61@github.com>
 <_F9C0U0OL9cONH_33a6rIwrqrurokPIwKTmp3zV9x_c=.c4b8dd8c-d03e-4651-b99f-4e0c00a756ca@github.com>
Message-ID: <jt5XwsQEkCP5nvSPq4-iTJ00NqHvBXcNZhCyihlfViw=.dbd10889-1658-4827-836e-90b1fcf8f332@github.com>

On Mon, 23 Jun 2025 08:29:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> it wasn't always the case
>> 
>> Does it mean that there was another up-call into Java before this method returns?
>
> yes, at least on Solaris we used to call other JNI methods after this one, see `parseExclusiveBindProperty` before 071bd521bca2485c6df95c45e4310d39b05bd046

Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25754#discussion_r2161682127

From rriggs at openjdk.org  Mon Jun 23 14:36:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Jun 2025 14:36:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <8nRs1GFxt__bdvf85L3IUCKmlWmPUYztN0bItrQ4Juc=.91785f87-9030-4675-b0e4-3ca08e93883f@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>
 <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>
 <8nRs1GFxt__bdvf85L3IUCKmlWmPUYztN0bItrQ4Juc=.91785f87-9030-4675-b0e4-3ca08e93883f@github.com>
Message-ID: <cKCTxYMs5fdCq0t1OPfNIVDWtv7VUnpL8iFJVafN92E=.06d97ec3-2b70-4c10-9ffc-a752aabd0075@github.com>

On Mon, 23 Jun 2025 10:55:57 GMT, David Beaumont <duke at openjdk.org> wrote:

>> The jrt protocol handler only exists because a URL streams a corresponding URLStreamHandler. It's not clear if the protocol handler is actually used. So I don't expect it is performance critical.
>
> This is here because I expect we will want to do something else in the "slow" path where '%' is present.
> I wanted to put an 'X' in the code where any additional logic around decoding goes, and none of that needs to happen if no '%' chars exist.
> For example, I think that we probably need to "worry about" %2F in the path, since that's not a synonym for '/' according to the URI specification.
> I can back this out for now if you want (please say one way of the other), but given we never create paths with '%' in, it won't affect anything for any case we care about (if this wasn't here then the decode call would do it anyway).

Drop it until there's a reason for it.  tnx.

>> MalformedURLException seems better here.
>
> Yes, but is that good though? This is a public API and surely as a random user I shouldn't be able to trigger an `Error` just by having bad input data?
> Since we can reasonably reason that, to a first approximation, "this code path isn't being hit by anyone" it felt reasonable to reflect "bad input data" with a MalformedURLException.
> Shall I change it back?

MalformedURLException is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161786366
PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2161786871

From rriggs at openjdk.org  Mon Jun 23 17:23:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 23 Jun 2025 17:23:38 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
Message-ID: <nq1fLXssC8eTZ3-zjm5rpGWijqiYtFFrivCYNyEpwxk=.155e8c52-8343-4693-9799-fb675e0c03de@github.com>

On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes and renaming field to match nomenclature of JEP 220.

I think 1-3 are addressed. (If you push the commits implied by comments).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25871#issuecomment-2997266176

From abarashev at openjdk.org  Mon Jun 23 19:49:50 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Mon, 23 Jun 2025 19:49:50 GMT
Subject: RFR: 8359956: Support algorithm constraints and certificate checks
 in SunX509 key manager [v11]
In-Reply-To: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
Message-ID: <nh1-oP9GggslbWmvrN6ENCkMYVn5SAJKm2KAZmZGKIw=.58f3f881-375f-4edc-b7b3-41f3ae72e0e2@github.com>

> SunX509 key manager should support the same certificate checks that are supported by PKIX key manager.
> 
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while SunX509 supports only a single keystore.
> - SunX509 caches its whole key store on initialization thus improving performance. This means that subsequent modifications of the KeyStore have no effect on SunX509 KM, unlike PKIX .
> 
> **SUNX509 KeyManager performance before the change**
> Benchmark                                    (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  19758.012 ? 758.237  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1861.695 ?  14.681  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1186.962** ?  12.085  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1056.288** ?   7.197  ops/s
> 
> **SUNX509 KeyManager performance after the change**
> Benchmark                 (resume)  (tlsVersion)   Mode  Cnt      Score     Error  Units
> SSLHandshake.doHandshake      true       TLSv1.2  thrpt   15  20954.399 ? 260.817  ops/s
> SSLHandshake.doHandshake      true           TLS  thrpt   15   1813.401 ?  13.917  ops/s
> SSLHandshake.doHandshake     false       TLSv1.2  thrpt   15   **1158.190** ?   6.023  ops/s
> SSLHandshake.doHandshake     false           TLS  thrpt   15   **1012.988** ?  10.943  ops/s

Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:

  Add more unit test cases. Some code tweaks.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25016/files
  - new: https://git.openjdk.org/jdk/pull/25016/files/c5e381ec..3edca307

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=09-10

  Stats: 72 lines in 2 files changed: 25 ins; 15 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/25016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016

PR: https://git.openjdk.org/jdk/pull/25016

From duke at openjdk.org  Mon Jun 23 20:28:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 20:28:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v2]
In-Reply-To: <uK6K7tg-MeQDFMZh9LMJcm1GAZXRkyneQru4kWYGho8=.5e69004e-9b7a-4fd0-bbd1-4ebb18fe7dbc@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <DKtC5tx1GkO-tKPKxaNlxHNTV2cns3wc29HreZTAl3w=.d1472abd-a063-439c-abd2-c6ce85dcf3bf@github.com>
 <ar6-WGUAc5eX0kz9_ULqASAYVwpoVJLURNwXoyfrwoQ=.fb00c3f2-c74a-48d4-a9dd-23a34505bfbb@github.com>
 <imHtkCfqSNecmyEwWgpDdI0Nr96-Nd5eNtY7GQns6bw=.2d8b52af-a4aa-4ec0-85e4-8015975b87a3@github.com>
 <uK6K7tg-MeQDFMZh9LMJcm1GAZXRkyneQru4kWYGho8=.5e69004e-9b7a-4fd0-bbd1-4ebb18fe7dbc@github.com>
Message-ID: <Wt79u78jbtQK4lKGshDYkH2dLPV30XL210z1SLiWJc8=.90b78e54-ffe0-4820-919d-323514fbb540@github.com>

On Sat, 21 Jun 2025 08:26:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> These were here explicitly to be discussed in review. If you think it's now covered by JDK-8359949, I can remove them.
>
>> These were here explicitly to be discussed in review. If you think it's now covered by JDK-8359949, I can remove them.
> 
> Okay, it's just that they initially make it look like the PR is not ready for review.

I did call it out in the PR description explicitly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2162468772

From duke at openjdk.org  Mon Jun 23 22:31:27 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 22:31:27 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v4]
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

David Beaumont has updated the pull request incrementally with three additional commits since the last revision:

 - Remove redundant fast-path check.
 - Change method name.
 - Feedback changes (maybe some still to be done).

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25871/files
  - new: https://git.openjdk.org/jdk/pull/25871/files/930aa2c6..2dcfd102

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=02-03

  Stats: 16 lines in 2 files changed: 4 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25871/head:pull/25871

PR: https://git.openjdk.org/jdk/pull/25871

From duke at openjdk.org  Mon Jun 23 22:31:28 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 23 Jun 2025 22:31:28 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
Message-ID: <6azW04vDsbuiydTVyi0aYuuf6PedqqhZCVsV1GVn7nk=.9a4a2088-82c2-4f5e-9a71-c5d5e4dbcdd4@github.com>

On Fri, 20 Jun 2025 11:13:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback changes and renaming field to match nomenclature of JEP 220.

My apologies. I've been having awful issues with IntelliJ not remembering which branches it should push to, so I was pushing to a different branch :( Should be up to date now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25871#issuecomment-2998140807

From djelinski at openjdk.org  Tue Jun 24 06:11:39 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 24 Jun 2025 06:11:39 GMT
Subject: RFR: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on
 core-libs code [v2]
In-Reply-To: <EgwLxv3GIasFJhk_1e9eVZEihXg1h_Uxqu9eTEzY3AQ=.b36d0d46-e33b-4981-91cd-4285ab2b8a3d@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
 <Egd5EWXLdOsaxcjLcFloyOMZMgIiKgVXL2voVJceYKA=.7f54d7df-5a6c-4517-9f26-0e20110205c3@github.com>
 <EgwLxv3GIasFJhk_1e9eVZEihXg1h_Uxqu9eTEzY3AQ=.b36d0d46-e33b-4981-91cd-4285ab2b8a3d@github.com>
Message-ID: <c3qPiyW5nPNOAjBrDkedC_pzaeYXc7isKYF8RVknwiI=.2e9826ef-d96a-4250-92eb-5212cb282b43@github.com>

On Mon, 23 Jun 2025 13:41:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> Marked as reviewed by aivanov (Reviewer).

Thanks @aivanov-jdk for the re-review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25754#issuecomment-2998947207

From djelinski at openjdk.org  Tue Jun 24 06:11:39 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 24 Jun 2025 06:11:39 GMT
Subject: Integrated: 8131136: java/awt/font/JNICheck/JNICheck.sh issue warning
 on core-libs code
In-Reply-To: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
References: <gHt5g8CrhM7HEIg3tOk6JmQfyqOIkz5sURp_uaOSG_s=.8c77be35-3068-4cf7-93a9-1dd4869a703b@github.com>
Message-ID: <eHbAvtcu9miZfESwtsdzT18Yi4iVqRetP0Og8Rj-zwc=.d7ce5620-fd3b-43c8-a062-e0dc627526b2@github.com>

On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Add an exception check after a JNI static method call, and re-enable checks for CallStatic in JNICheck.sh test.
> 
> I verified that the JNICheck test is passing on all headless and headful platforms I had access to (Windows, Linux and Mac). Other tier1-3 tests also continue to pass.

This pull request has now been integrated.

Changeset: dbbfa76b
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbbfa76b7335291b4bb9d8de6e7db8e6cec144ce
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8131136: java/awt/font/JNICheck/JNICheck.sh issue warning on core-libs code

Reviewed-by: aivanov, prr, serb

-------------

PR: https://git.openjdk.org/jdk/pull/25754

From michaelm at openjdk.org  Tue Jun 24 09:11:22 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 24 Jun 2025 09:11:22 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v12]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <zyiIe8VJULsUU_7mmCSe-ZhHMmkqsj9mPliiV_CxsLY=.7e80586d-2cb7-43e2-b2da-5eef6e9b1c0d@github.com>

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

Michael McMahon 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 19 additional commits since the last revision:

 - Merge branch 'master' into cookie-8351983
 - Merge branch 'master' into cookie-8351983
 - apidoc update
 - doc update from CSR review
 - Merge branch 'master' into cookie-8351983
 - Revert "impl update"
   
   This reverts commit b22113118ce68a5ba710be9072b208e9a36ae533.
 - impl update
 - test update
 - test and impl update
 - Merge branch 'master' into cookie-8351983
 - ... and 9 more: https://git.openjdk.org/jdk/compare/0c9e0f74...6eba52a9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/3b71e4ff..6eba52a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=10-11

  Stats: 3213 lines in 215 files changed: 1274 ins; 569 del; 1370 mod
  Patch: https://git.openjdk.org/jdk/pull/25636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636

PR: https://git.openjdk.org/jdk/pull/25636

From michaelm at openjdk.org  Tue Jun 24 09:18:35 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 24 Jun 2025 09:18:35 GMT
Subject: Integrated: 8351983: HttpCookie Parser Incorrectly Handles Cookies
 with Expires Attribute
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <nIcmYJgh6Cl_l_mEWnvrf6peZW54RkuXwJpvQJyJMoE=.b077b11e-f1d9-4fb1-8cf8-c7ff913e9b9d@github.com>

On Wed, 4 Jun 2025 11:12:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and Expires attributes
> are present in a cookie, the Max-Age should take precedence.
> 
> Thanks
> Michael

This pull request has now been integrated.

Changeset: 116b8543
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/116b8543b04bfcf542af0ba03ac547a744600b7c
Stats:     274 lines in 3 files changed: 235 ins; 24 del; 15 mod

8351983: HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute

Reviewed-by: dfuchs, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/25636

From alanb at openjdk.org  Tue Jun 24 14:51:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jun 2025 14:51:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v4]
In-Reply-To: <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>
Message-ID: <LeR5xk7VaGflIGmEDpTp0p3x65KLES9_J6SnyC-sCg8=.6c64dec1-ea26-4b2a-b8fd-4b146459ac77@github.com>

On Mon, 23 Jun 2025 22:31:27 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove redundant fast-path check.
>  - Change method name.
>  - Feedback changes (maybe some still to be done).

src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 113:

> 111:     public long getContentLengthLong() {
> 112:         // Note: UncheckedIOException is thrown by the Node subclass in
> 113:         // ExplodedImage (this not obvious, so worth calling out).

This protocol handler is for images build, not exploded builds. ImageReaderFactory.getImageReader will fail if you attempt it with an exploded build. So I don't think we need this comment or the catch of UIOE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2164237749

From alanb at openjdk.org  Tue Jun 24 14:51:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jun 2025 14:51:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v3]
In-Reply-To: <cKCTxYMs5fdCq0t1OPfNIVDWtv7VUnpL8iFJVafN92E=.06d97ec3-2b70-4c10-9ffc-a752aabd0075@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yo0Z_ZIw-toAuiDRuA2j2d64s1Rg4Ewx6kBrf2JjFaM=.2f23cfd7-59ab-480c-b3de-5cad27de82ef@github.com>
 <34ZdvfEFojP5DPLOaZInfTB6LYEVa6e__lFGZjgZ1VI=.41e70463-fe9e-468d-b56b-ba4babb2b287@github.com>
 <wJgIdXqzePo2MQKipzuUnn-9aXURJqjcj0ewrb6doms=.724e6e22-7dd9-4027-ab18-ac1b9861ecfb@github.com>
 <8nRs1GFxt__bdvf85L3IUCKmlWmPUYztN0bItrQ4Juc=.91785f87-9030-4675-b0e4-3ca08e93883f@github.com>
 <cKCTxYMs5fdCq0t1OPfNIVDWtv7VUnpL8iFJVafN92E=.06d97ec3-2b70-4c10-9ffc-a752aabd0075@github.com>
Message-ID: <BEZyUCZ47d9-RsT5xVluKbcnGlofJYN6kc-ZdSdWMc8=.c9378712-258f-483b-942b-2562c833c56d@github.com>

On Mon, 23 Jun 2025 14:34:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yes, but is that good though? This is a public API and surely as a random user I shouldn't be able to trigger an `Error` just by having bad input data?
>> Since we can reasonably reason that, to a first approximation, "this code path isn't being hit by anyone" it felt reasonable to reflect "bad input data" with a MalformedURLException.
>> Shall I change it back?
>
> MalformedURLException is fine.

Yes, I agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2164238754

From duke at openjdk.org  Tue Jun 24 15:44:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 24 Jun 2025 15:44:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v4]
In-Reply-To: <LeR5xk7VaGflIGmEDpTp0p3x65KLES9_J6SnyC-sCg8=.6c64dec1-ea26-4b2a-b8fd-4b146459ac77@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>
 <LeR5xk7VaGflIGmEDpTp0p3x65KLES9_J6SnyC-sCg8=.6c64dec1-ea26-4b2a-b8fd-4b146459ac77@github.com>
Message-ID: <_Xx169TsJYf0ewAkcaJeHIUq9VES0xmG-2ITD53PBGs=.1d27f4e9-ba04-4a93-b89b-727875cc39cd@github.com>

On Tue, 24 Jun 2025 14:48:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove redundant fast-path check.
>>  - Change method name.
>>  - Feedback changes (maybe some still to be done).
>
> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 113:
> 
>> 111:     public long getContentLengthLong() {
>> 112:         // Note: UncheckedIOException is thrown by the Node subclass in
>> 113:         // ExplodedImage (this not obvious, so worth calling out).
> 
> This protocol handler is for images build, not exploded builds. ImageReaderFactory.getImageReader will fail if you attempt it with an exploded build. So I don't think we need this comment or the catch of UIOE.

Roger suggested I add the catch for the `UncheckedIOException` because of it. Maybe chat with him to see if this could somehow end up seeing an ExplodedImage build?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2164354818

From duke at openjdk.org  Tue Jun 24 15:52:48 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 24 Jun 2025 15:52:48 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v5]
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  According to Alan, this cannot work with ExplodedImage, so remove the catch/comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25871/files
  - new: https://git.openjdk.org/jdk/pull/25871/files/2dcfd102..0b9176c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25871&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25871/head:pull/25871

PR: https://git.openjdk.org/jdk/pull/25871

From alanb at openjdk.org  Tue Jun 24 15:52:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jun 2025 15:52:48 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v4]
In-Reply-To: <_Xx169TsJYf0ewAkcaJeHIUq9VES0xmG-2ITD53PBGs=.1d27f4e9-ba04-4a93-b89b-727875cc39cd@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>
 <LeR5xk7VaGflIGmEDpTp0p3x65KLES9_J6SnyC-sCg8=.6c64dec1-ea26-4b2a-b8fd-4b146459ac77@github.com>
 <_Xx169TsJYf0ewAkcaJeHIUq9VES0xmG-2ITD53PBGs=.1d27f4e9-ba04-4a93-b89b-727875cc39cd@github.com>
Message-ID: <jXSQLR0XBvfqdfZ2E92A-7U2LYe9ZsaG0ttVpjlPK8Y=.776e85a2-5b2d-4a28-a83d-2d793c9fa224@github.com>

On Tue, 24 Jun 2025 15:42:06 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java line 113:
>> 
>>> 111:     public long getContentLengthLong() {
>>> 112:         // Note: UncheckedIOException is thrown by the Node subclass in
>>> 113:         // ExplodedImage (this not obvious, so worth calling out).
>> 
>> This protocol handler is for images build, not exploded builds. ImageReaderFactory.getImageReader will fail if you attempt it with an exploded build. So I don't think we need this comment or the catch of UIOE.
>
> Roger suggested I add the catch for the `UncheckedIOException` because of it. Maybe chat with him to see if this could somehow end up seeing an ExplodedImage build?

@RogerRiggs The jrt protocol handler is for images builds. Any attempt, in exploded build, to connect to a jrt resource will blow up as ImageReaderFactory.getImageReader fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2164369527

From michaelm at openjdk.org  Tue Jun 24 15:55:38 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 24 Jun 2025 15:55:38 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
Message-ID: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>

Hi,

This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
In a couple of places, the new native code in that fix can potentially throw
an exception while another exception is pending. This needs to be fixed.

Thanks,
Michael

-------------

Commit messages:
 - Merge branch 'master' into JNI-8359268
 - windows compile error
 - update
 - impl fix

Changes: https://git.openjdk.org/jdk/pull/25898/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359268
  Stats: 32 lines in 5 files changed: 15 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25898/head:pull/25898

PR: https://git.openjdk.org/jdk/pull/25898

From michaelm at openjdk.org  Tue Jun 24 16:14:13 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 24 Jun 2025 16:14:13 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
 [v2]
In-Reply-To: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
Message-ID: <dRk3D2Z82jaOGlukmtbCmv79U_eLQNfAFJaCnAQveFg=.fb6eb615-bad7-4134-91a4-13c5edcfd328@github.com>

> Hi,
> 
> This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
> In a couple of places, the new native code in that fix can potentially throw
> an exception while another exception is pending. This needs to be fixed.
> 
> Thanks,
> Michael

Michael McMahon 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 seven additional commits since the last revision:

 - Merge branch 'JNI-8359268' of /Users/mimcmah/git/jdk/open into JNI-8359268
 - Merge branch 'master' into JNI-8359268
 - net_util.c update
 - Merge branch 'master' into JNI-8359268
 - windows compile error
 - update
 - impl fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25898/files
  - new: https://git.openjdk.org/jdk/pull/25898/files/19518caf..65dc96c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=00-01

  Stats: 3488 lines in 218 files changed: 1509 ins; 593 del; 1386 mod
  Patch: https://git.openjdk.org/jdk/pull/25898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25898/head:pull/25898

PR: https://git.openjdk.org/jdk/pull/25898

From rriggs at openjdk.org  Tue Jun 24 16:18:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Jun 2025 16:18:35 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v4]
In-Reply-To: <jXSQLR0XBvfqdfZ2E92A-7U2LYe9ZsaG0ttVpjlPK8Y=.776e85a2-5b2d-4a28-a83d-2d793c9fa224@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>
 <LeR5xk7VaGflIGmEDpTp0p3x65KLES9_J6SnyC-sCg8=.6c64dec1-ea26-4b2a-b8fd-4b146459ac77@github.com>
 <_Xx169TsJYf0ewAkcaJeHIUq9VES0xmG-2ITD53PBGs=.1d27f4e9-ba04-4a93-b89b-727875cc39cd@github.com>
 <jXSQLR0XBvfqdfZ2E92A-7U2LYe9ZsaG0ttVpjlPK8Y=.776e85a2-5b2d-4a28-a83d-2d793c9fa224@github.com>
Message-ID: <z0-1LQCB380KOzUcnWu3SXLT-ceWi3MTjP9wDrxNvqw=.7c3c18e0-c96e-414f-a4b9-788eaf2b0b51@github.com>

On Tue, 24 Jun 2025 15:48:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger suggested I add the catch for the `UncheckedIOException` because of it. Maybe chat with him to see if this could somehow end up seeing an ExplodedImage build?
>
> @RogerRiggs The jrt protocol handler is for images builds. Any attempt, in exploded build, to connect to a jrt resource will blow up as ImageReaderFactory.getImageReader fails.

Right, it would never occur. Remove as unnecessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2164425541

From alanb at openjdk.org  Tue Jun 24 16:22:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 24 Jun 2025 16:22:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v5]
In-Reply-To: <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>
Message-ID: <jY1IuE_5JqWF586kQZExfWNsA6W3FAYZnvGbsirsgfk=.928b1833-ee09-4ee9-8422-b31922330824@github.com>

On Tue, 24 Jun 2025 15:52:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   According to Alan, this cannot work with ExplodedImage, so remove the catch/comment.

Latest version looks okay, no other comments from me.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25871#pullrequestreview-2954538070

From rriggs at openjdk.org  Tue Jun 24 16:22:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Jun 2025 16:22:33 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v4]
In-Reply-To: <z0-1LQCB380KOzUcnWu3SXLT-ceWi3MTjP9wDrxNvqw=.7c3c18e0-c96e-414f-a4b9-788eaf2b0b51@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <yfrKwZc5oMapKcaeESmiUQCdtZCOumpkWSgPPxAdnOA=.0cc8e842-6189-4c6d-ab48-7d4c8f0eadd4@github.com>
 <LeR5xk7VaGflIGmEDpTp0p3x65KLES9_J6SnyC-sCg8=.6c64dec1-ea26-4b2a-b8fd-4b146459ac77@github.com>
 <_Xx169TsJYf0ewAkcaJeHIUq9VES0xmG-2ITD53PBGs=.1d27f4e9-ba04-4a93-b89b-727875cc39cd@github.com>
 <jXSQLR0XBvfqdfZ2E92A-7U2LYe9ZsaG0ttVpjlPK8Y=.776e85a2-5b2d-4a28-a83d-2d793c9fa224@github.com>
 <z0-1LQCB380KOzUcnWu3SXLT-ceWi3MTjP9wDrxNvqw=.7c3c18e0-c96e-414f-a4b9-788eaf2b0b51@github.com>
Message-ID: <tqRcxJ7J5uYfHQneuGBxO7cbj1Cnkmk2ewGd59wv3Wc=.3b49402d-7cbc-491c-9ce8-c3d70ed9787d@github.com>

On Tue, 24 Jun 2025 16:15:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> @RogerRiggs The jrt protocol handler is for images builds. Any attempt, in exploded build, to connect to a jrt resource will blow up as ImageReaderFactory.getImageReader fails.
>
> Right, it would never occur. Remove as unnecessary.

The import of UncheckedIOException can be remove.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25871#discussion_r2164430321

From rriggs at openjdk.org  Tue Jun 24 16:35:31 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Jun 2025 16:35:31 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v5]
In-Reply-To: <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>
Message-ID: <acnfN8IWUx9SyyLSOgszEJ6zGMoCOBaE41kZ3EaHzok=.de059478-7ed5-44c5-819c-f9e3a1111385@github.com>

On Tue, 24 Jun 2025 15:52:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   According to Alan, this cannot work with ExplodedImage, so remove the catch/comment.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25871#pullrequestreview-2954573417

From abarashev at openjdk.org  Tue Jun 24 16:44:36 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 24 Jun 2025 16:44:36 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
Message-ID: <UTDakdKiHIzeZqtMO49ZMLGhgXEJZ1CEVFAWoOLl1k0=.a3f3886c-21be-4979-b632-4a4b9a14c7f4@github.com>

On Tue, 3 Jun 2025 13:11:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
>  - Merge branch 'master' into certbuilder
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 247:

> 245:     private static void setupCertificates() throws Exception {
> 246:         KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> 247:         kpg.initialize(1024);

This line can be removed so implementation uses a default value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2164469651

From abarashev at openjdk.org  Tue Jun 24 16:48:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 24 Jun 2025 16:48:34 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>
Message-ID: <0htGbIzjg033KwgKDz6hjpQ8ItfZI0O6fHId-nplqVI=.c713ce44-b75d-4040-b851-881163c2ed29@github.com>

On Tue, 3 Jun 2025 13:11:31 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
>> 
>> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
>> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
>> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
>  - Merge branch 'master' into certbuilder
>  - expanded wildcard imports
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - reversed order of DN strings when making certificates.
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - Merge branch 'master' into certbuilder
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 390:

> 388: 
> 389:         // create a key store
> 390:         KeyStore ks = KeyStore.getInstance("JKS");

I suggest changing a key store type to `PKCS12`, should be a better choice in the long run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2164477518

From duke at openjdk.org  Tue Jun 24 16:59:34 2025
From: duke at openjdk.org (duke)
Date: Tue, 24 Jun 2025 16:59:34 GMT
Subject: RFR: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources [v5]
In-Reply-To: <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
 <7zQQ9krhjX1j95Ls53N0SxKOVr5C2Uk19XuBD_Oz6Y0=.0ee8e656-e923-43bb-b71b-eb7d72a2dd7f@github.com>
Message-ID: <YI7fSbcxghUiaVsYqp0IMxQNjrl1DvAkeUE1CUBNAmc=.cf8faec8-32f6-4053-b48b-2b119ddff3b6@github.com>

On Tue, 24 Jun 2025 15:52:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
>> 
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
>> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
>> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
>> 4. Small constructor logic simplification (module name cannot be null anymore)
>> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
>> 6. Adding tests for the non-resource cases.
>> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
>> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   According to Alan, this cannot work with ExplodedImage, so remove the catch/comment.

@david-beaumont 
Your change (at version 0b9176c7b33d1d7fb47349205e211d5f158046fe) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25871#issuecomment-3001212158

From duke at openjdk.org  Tue Jun 24 18:43:36 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 24 Jun 2025 18:43:36 GMT
Subject: Integrated: 8359808: JavaRuntimeURLConnection should only connect to
 non-directory resources
In-Reply-To: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
References: <OH5WK-PZsLi78Y1T61PJMv7fCKHsfz2W9kMlk07OvfA=.589d0625-0034-406e-8fa1-657d17e4bd16@github.com>
Message-ID: <gz5GUadH-d5gK-MrnlThyvq5hC44AFoxUkSKD8lrciE=.b22fc18e-09a6-42b6-b8a0-d6a3a372dfdf@github.com>

On Wed, 18 Jun 2025 12:53:56 GMT, David Beaumont <duke at openjdk.org> wrote:

> Simplifying JavaRuntimeURLConnection to avoid accidentally returning non-resource data to users.
> 
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface and related URL generation code (completely unreachable).
> 3. Adding comments explaining why there's a non-obvious distinction in how module and resource names are treated with respect to URL percent encoding.
> 4. Small constructor logic simplification (module name cannot be null anymore)
> 5. Small simplification around 'READER' use, since it is impossible for that to ever be null (other users of ImageReaderFactory already assume it could never be null, and code path analysis agrees).
> 6. Adding tests for the non-resource cases.
> 7. Adding extra test data to check the behaviour with respect to things like percent escaping (previously untested).
> 8. Adding TODO comments for things I could do in this PR or later (reviewer opinions welcome).

This pull request has now been integrated.

Changeset: ba0c1223
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba0c12231b0f5b680951e75765b5d292f31a2cbc
Stats:     132 lines in 2 files changed: 38 ins; 59 del; 35 mod

8359808: JavaRuntimeURLConnection should only connect to non-directory resources

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/25871

From djelinski at openjdk.org  Tue Jun 24 20:04:30 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 24 Jun 2025 20:04:30 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
 [v2]
In-Reply-To: <dRk3D2Z82jaOGlukmtbCmv79U_eLQNfAFJaCnAQveFg=.fb6eb615-bad7-4134-91a4-13c5edcfd328@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
 <dRk3D2Z82jaOGlukmtbCmv79U_eLQNfAFJaCnAQveFg=.fb6eb615-bad7-4134-91a4-13c5edcfd328@github.com>
Message-ID: <Xj2ZExtIqXUekfz5ta15r-trnzF9T6cPtQdlrvfv1KU=.e4eebf8b-c43c-484a-82fa-8cc83613a095@github.com>

On Tue, 24 Jun 2025 16:14:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
>> In a couple of places, the new native code in that fix can potentially throw
>> an exception while another exception is pending. This needs to be fixed.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon 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 seven additional commits since the last revision:
> 
>  - Merge branch 'JNI-8359268' of /Users/mimcmah/git/jdk/open into JNI-8359268
>  - Merge branch 'master' into JNI-8359268
>  - net_util.c update
>  - Merge branch 'master' into JNI-8359268
>  - windows compile error
>  - update
>  - impl fix

src/java.base/windows/native/libnet/Inet4AddressImpl.c line 93:

> 91:         int enh = getEnhancedExceptionsAllowed(env);
> 92:         if (enh == ENH_INIT_ERROR && (*env)->ExceptionCheck(env)) {
> 93:             return NULL;

should it be `goto cleanupAndReturn;` instead?

src/java.base/windows/native/libnet/Inet6AddressImpl.c line 88:

> 86:         int enh = getEnhancedExceptionsAllowed(env);
> 87:         if (enh == ENH_INIT_ERROR && (*env)->ExceptionCheck(env)) {
> 88:             return NULL;

should it be `goto cleanupAndReturn;` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25898#discussion_r2164789558
PR Review Comment: https://git.openjdk.org/jdk/pull/25898#discussion_r2164793497

From michaelm at openjdk.org  Tue Jun 24 20:25:30 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 24 Jun 2025 20:25:30 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
 [v2]
In-Reply-To: <Xj2ZExtIqXUekfz5ta15r-trnzF9T6cPtQdlrvfv1KU=.e4eebf8b-c43c-484a-82fa-8cc83613a095@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
 <dRk3D2Z82jaOGlukmtbCmv79U_eLQNfAFJaCnAQveFg=.fb6eb615-bad7-4134-91a4-13c5edcfd328@github.com>
 <Xj2ZExtIqXUekfz5ta15r-trnzF9T6cPtQdlrvfv1KU=.e4eebf8b-c43c-484a-82fa-8cc83613a095@github.com>
Message-ID: <MML74RqizxNM2jlhkpQwWL2z-i4eXifevjuLotia20o=.7b1ee332-2fcd-4604-8816-44e024473891@github.com>

On Tue, 24 Jun 2025 19:58:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> should it be `goto cleanupAndReturn;` instead?

Yes, good catch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25898#discussion_r2164837680

From michaelm at openjdk.org  Tue Jun 24 20:34:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 24 Jun 2025 20:34:11 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
 [v3]
In-Reply-To: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
Message-ID: <PJeSUnpDJIlt7ltjnKWC7plAcvZ4EEzzYteGN7_-mD8=.9c52261a-7763-4d98-8c81-fd66957b0d35@github.com>

> Hi,
> 
> This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
> In a couple of places, the new native code in that fix can potentially throw
> an exception while another exception is pending. This needs to be fixed.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  DJ review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25898/files
  - new: https://git.openjdk.org/jdk/pull/25898/files/65dc96c1..53588d06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25898/head:pull/25898

PR: https://git.openjdk.org/jdk/pull/25898

From djelinski at openjdk.org  Wed Jun 25 06:02:33 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Jun 2025 06:02:33 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
 [v3]
In-Reply-To: <PJeSUnpDJIlt7ltjnKWC7plAcvZ4EEzzYteGN7_-mD8=.9c52261a-7763-4d98-8c81-fd66957b0d35@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
 <PJeSUnpDJIlt7ltjnKWC7plAcvZ4EEzzYteGN7_-mD8=.9c52261a-7763-4d98-8c81-fd66957b0d35@github.com>
Message-ID: <Kea6xFty0XwpriNUiAFO6uPTZ4KUNsE3w_WIH95UzC4=.e64eee5c-1fe7-4afd-bbd3-a9017cf71436@github.com>

On Tue, 24 Jun 2025 20:34:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
>> In a couple of places, the new native code in that fix can potentially throw
>> an exception while another exception is pending. This needs to be fixed.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   DJ review

LGTM

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25898#pullrequestreview-2956742785

From jpai at openjdk.org  Wed Jun 25 07:38:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 07:38:42 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <ooatWh5P-uq9NOvehhwv-TT_GF3wF9awAZYmzuIXwCc=.4d62ff7e-ad19-44cf-a7e7-92e081fda2c4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <ooatWh5P-uq9NOvehhwv-TT_GF3wF9awAZYmzuIXwCc=.4d62ff7e-ad19-44cf-a7e7-92e081fda2c4@github.com>
Message-ID: <Ml3RL_0YjwZCf9TJ7k9gpTrZnS68yHDWiuN8v2qGR8c=.4ff1e212-745c-426b-ab44-4fbcee765903@github.com>

On Tue, 22 Apr 2025 16:39:21 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: update H3InsertionsLimitTest to start after receival of client settings
>>  - merge latest changes from master branch
>>  - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
>>  - quic: simplify idle timeout management
>>  - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
>>  - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 265:
> 
>> 263: //                    engine, localSupportedSignAlgs, false);
>> 264: //        } else {
>> 265: //            constraints = SSLAlgorithmConstraints.forEngine(engine, false);
> 
> We need these to check peer's certificate against constraints specified in `java.security` config file. It looks like `SSLAlgorithmConstraints` class would need a new `forQuicTLSEngine` method.

Hello Daniel @dfuchs, this can be marked as resolved since the changes proposed by Artur have been implemented in this PR. There's now a `SSLAlgorithmConstraints.forQUIC()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166016865

From jpai at openjdk.org  Wed Jun 25 07:41:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 07:41:43 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <vLvyqUUFPFSJUrFUl8EOEBJHGsoIxWOVGMeB0uhV6Tw=.249ece3e-3a6e-4671-ae9a-5fa23bee0b14@github.com>
Message-ID: <HKN_NQPI7MKzBFtFIwyjpihj4glBEiJf_huvhWoD5TQ=.3fd7c853-93ad-49a2-b58e-a61c8366c275@github.com>

On Tue, 10 Jun 2025 22:16:18 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 164:
> 
>> 162:      */
>> 163:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 164:                                         boolean applyCertPathAlgConstraints) {
> 
> This parameter should be called `withDefaultCertPathConstraints` for consistency with other methods.

Done. The change will be available in the next refresh of this PR.

> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 188:
> 
>> 186:     static AlgorithmConstraints forQUIC(QuicTLSEngine engine,
>> 187:                                         String[] supportedAlgorithms,
>> 188:                                         boolean applyCertPathAlgConstraints) {
> 
> Same as above:  should be called `withDefaultCertPathConstraints`

Done. The change will be available in the next refresh of this PR.

> src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java line 243:
> 
>> 241:         }
>> 242:         // QUIC TLS version is mandated to be always TLSv1.3
>> 243:         if (!ProtocolVersion.useTLS12PlusSpec(session.getProtocol())) {
> 
> Should be `useTLS13PlusSpec`

Done. The change will be available in the next refresh of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166022943
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166022795
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166023188

From jpai at openjdk.org  Wed Jun 25 07:45:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 07:45:48 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
Message-ID: <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>

On Tue, 10 Jun 2025 22:21:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - Improve key destruction
>>  - merge latest changes from master branch
>>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>>  - http3: refactor HTTP/3 connection pool management in a separate class
>>  - Ignore DestroyFailedExceptions
>>  - Remove outdated TODO
>>  - Remove outdated TODO
>>  - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:
> 
>> 245:         if (quicEngine != null) {
>> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
>> 247:                 return engineImpl.getAlgorithmConstraints();
> 
> Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?

Hello Artur, we currently don't expose the `HandshakeContext` outside of the `QuicTLSEngineImpl`. The `HandshakeContext` is what is needed to get the relevant user specified algorithm constraints. So I decided to let the `HandshakeContext` be an internal detail in `QuicTLSEngineImpl` and introduce the `getAlgorithmConstraints()` method on it. Do you think we should hand out the `HandshakeContext` outside of `QuicTLSEngineImpl`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166029169

From djelinski at openjdk.org  Wed Jun 25 08:23:40 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Jun 2025 08:23:40 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <M2N2txL2370OJ-NMxgkQ_qC15SC8cUbhTcFKo--AiP4=.45b41468-c1d9-4378-ac74-48a467113baf@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <9rWMdJ_KuW5Auws9DtD_pOWt2Mb4-nGLBDmN0DLFA_0=.c8106398-609d-482d-a5bf-b8b78bb8144d@github.com>
 <rVqCd_DVMFQ-IvM8H3_h26LN-rcuKon-Zv8ZA-g2t3I=.a55a3fcf-f219-4127-b3df-278534230389@github.com>
 <HICWfI_yKD64mMPhIsGHFT5cPIw4Az-RociRzPvJUXQ=.d3150052-6cb2-486a-b149-5b5617c183d3@github.com>
 <xNTKNw56qEiRc6oU_NMnWtbD1V4FRpC63waNCUm9jdQ=.8b434d7c-8c96-42f9-8e37-4d06651da4a4@github.com>
 <M2N2txL2370OJ-NMxgkQ_qC15SC8cUbhTcFKo--AiP4=.45b41468-c1d9-4378-ac74-48a467113baf@github.com>
Message-ID: <MqJOxFQxAN-Fp0b4fo5rCiBSvaZCIuxghdqn9AhmzNA=.a892b057-9743-40bf-8032-e5ba3cb6345e@github.com>

On Mon, 28 Apr 2025 18:56:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sounds good, this was just FYI.
>
> I may be wrong, but it seems you only re-enable 3DES to test a non-TLS 1.3 cipher suite. But you don't have to use a 3DES suite to do that, you could use one of the suites that are already enabled (and are still considered strong), like "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256".
> 
> As a general comment, I would avoid re-enabling broken or disabled algorithms unless you specifically have to test that algorithm for some reason.

Thanks for pointing it out. Re-enabling was removed in 368f9b58736e4eb4f37d043ecd4df28d316fec49, and we will replace the cipher suite in the next refresh of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166103818

From jpai at openjdk.org  Wed Jun 25 08:54:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 25 Jun 2025 08:54:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <d-C3dWGfCTMMvUNSJEasqpki3hPXsceVRq1Zcvk1ELs=.786376c8-68d2-48f7-8d8c-3a960d44d610@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <d-C3dWGfCTMMvUNSJEasqpki3hPXsceVRq1Zcvk1ELs=.786376c8-68d2-48f7-8d8c-3a960d44d610@github.com>
Message-ID: <utwMIK25ZL47maOh0egih5osEbJeJIFJuALQBXI0QVI=.6510d13b-68e5-4d0e-bf5f-ec08cef38b55@github.com>

On Fri, 25 Apr 2025 19:13:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 172:
> 
>> 170:             userSpecifiedConstraints = engine.getSSLParameters()
>> 171:                     .getAlgorithmConstraints();
>> 172:         }
> 
> Duplicate code block here and in the 2nd `forQUIC` method. We should move it to a private `getUserSpecifiedConstraints` method, like in SSLEngine and SSLSocket cases.

@dfuch this can be resolved. We followed Artur's suggestion and used a private method for this common code. It's done in commit e11998ddce124044d08c95f2c1d03f61dc20f3ed of this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166182635

From dfuchs at openjdk.org  Wed Jun 25 09:02:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Jun 2025 09:02:54 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
 <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>
Message-ID: <uDucsuhHMw9_IVrR2uo1xNxAonbsGxMQYAkKZsKuiAI=.b0dded6a-34a0-4dab-9667-024ff6ede6fd@github.com>

On Wed, 4 Jun 2025 17:43:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: update H3InsertionsLimitTest to start after receival of client settings
>>  - merge latest changes from master branch
>>  - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
>>  - quic: simplify idle timeout management
>>  - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
>>  - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e
>
> src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java line 43:
> 
>> 41: // The encoding is simple and well known: 1 byte <-> 1 char
>> 42: //
>> 43: final class ISO_8859_1 {
> 
> OK - this class is actually used in QPack as well as HPack. Same for the `QuickHuffman` class below (notice that this is Quick - not Quic ;-) )
> 
> It might be interesting to investigate if we could pull out these classes to a common location to break the tie between QPack and HPack. Something to think about after integration maybe.

@AlekseiEfimov I am resolving this conversation now. Something we could think about later!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166201911

From michaelm at openjdk.org  Wed Jun 25 09:22:50 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 25 Jun 2025 09:22:50 GMT
Subject: RFR: 8359268: 3 JNI exception pending defect groups in 2 files
 [v4]
In-Reply-To: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
Message-ID: <KQmEahh9cL6BEZbIBygyO9rPQMPiSO72F2t7rDKSwnM=.4ccc11f4-4376-4fbc-8f6a-8c4d2ff56650@github.com>

> Hi,
> 
> This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
> In a couple of places, the new native code in that fix can potentially throw
> an exception while another exception is pending. This needs to be fixed.
> 
> Thanks,
> Michael

Michael McMahon 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 nine additional commits since the last revision:

 - Merge branch 'master' into JNI-8359268
 - DJ review
 - Merge branch 'JNI-8359268' of /Users/mimcmah/git/jdk/open into JNI-8359268
 - Merge branch 'master' into JNI-8359268
 - net_util.c update
 - Merge branch 'master' into JNI-8359268
 - windows compile error
 - update
 - impl fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25898/files
  - new: https://git.openjdk.org/jdk/pull/25898/files/53588d06..1fdddfcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25898&range=02-03

  Stats: 882 lines in 43 files changed: 638 ins; 69 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/25898.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25898/head:pull/25898

PR: https://git.openjdk.org/jdk/pull/25898

From michaelm at openjdk.org  Wed Jun 25 09:48:36 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 25 Jun 2025 09:48:36 GMT
Subject: Integrated: 8359268: 3 JNI exception pending defect groups in 2 files
In-Reply-To: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
References: <0RTO6SWNjEDvdw4WQW7iEHpCg-fkAMwleE1DbpmKgSA=.a441f793-f8ce-465c-9682-ea2911065764@github.com>
Message-ID: <Wj6DiHxK-oBLdxRLWOojseuiu_bzy0w7Mk-Fe-OI1OE=.9e82ccab-c394-421a-b3a2-bcd1981be38a@github.com>

On Thu, 19 Jun 2025 13:46:41 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This change is a follow on from https://bugs.openjdk.org/browse/JDK-8348986
> In a couple of places, the new native code in that fix can potentially throw
> an exception while another exception is pending. This needs to be fixed.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: 1fa09052
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9
Stats:     32 lines in 5 files changed: 15 ins; 7 del; 10 mod

8359268: 3 JNI exception pending defect groups in 2 files

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/25898

From michaelm at openjdk.org  Wed Jun 25 10:03:46 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 25 Jun 2025 10:03:46 GMT
Subject: [jdk25] RFR: 8359268: 3 JNI exception pending defect groups in 2 files
Message-ID: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>

Hi all,

This pull request contains a backport of commit [1fa09052](https://github.com/openjdk/jdk/commit/1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Michael McMahon on 25 Jun 2025 and was reviewed by Daniel Jeli?ski.

Thanks!
Michael

-------------

Commit messages:
 - Backport 1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9

Changes: https://git.openjdk.org/jdk/pull/25973/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25973&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359268
  Stats: 32 lines in 5 files changed: 15 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25973/head:pull/25973

PR: https://git.openjdk.org/jdk/pull/25973

From dfuchs at openjdk.org  Wed Jun 25 10:48:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 25 Jun 2025 10:48:29 GMT
Subject: [jdk25] RFR: 8359268: 3 JNI exception pending defect groups in 2
 files
In-Reply-To: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>
References: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>
Message-ID: <V-bDEASVptrUjlJBo_CMr7ypCu1BRazlRW_Vo8ttO7o=.aec1b9fc-4e39-4697-b42c-66c5f5a02361@github.com>

On Wed, 25 Jun 2025 09:58:55 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1fa09052](https://github.com/openjdk/jdk/commit/1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Michael McMahon on 25 Jun 2025 and was reviewed by Daniel Jeli?ski.
> 
> Thanks!
> Michael

This looks reasonable to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25973#pullrequestreview-2957661541

From djelinski at openjdk.org  Wed Jun 25 11:04:41 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Jun 2025 11:04:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <fopFSoDFZHwFvMU9afn5Z0GeiECsjaMNr0ng4-rtXAQ=.72243a2e-a505-4e2b-943c-9ec644d47a4b@github.com>
 <oGSPDZ3vfqSMEE64wxCFmFw9MSgZV0eWGKbmvFQetXM=.ce8d8479-bbf8-4af2-8ed9-f70bfad1b8f3@github.com>
Message-ID: <kukozivajzBYdadZ_CUaHlIktZAcrymye1v_duXMZ44=.3e3cabab-1ce5-46e5-9e2f-a7f52c39dc49@github.com>

On Tue, 10 Jun 2025 22:55:31 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/CertificateMessage.java line 1221:
>> 
>>> 1219:                         tm.checkClientTrusted(
>>> 1220:                                 certs.clone(),
>>> 1221:                                 authType);
>> 
>> This call doesn't check against `SSLAlgorithmConstraints` unlike 2 calls for `SSLSocket` and `SSLEngine` above.
>
> What would be the reason it's not addressed like in `checkServerCerts` below?

That will be addressed in the next update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2166438709

From djelinski at openjdk.org  Wed Jun 25 11:06:28 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 25 Jun 2025 11:06:28 GMT
Subject: [jdk25] RFR: 8359268: 3 JNI exception pending defect groups in 2
 files
In-Reply-To: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>
References: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>
Message-ID: <Lo0HmbbU0UDRs5jUDSB7Z4jX-y8wt2xFXwzt9GPlqR8=.07767775-172d-4845-b269-625e87f3702d@github.com>

On Wed, 25 Jun 2025 09:58:55 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1fa09052](https://github.com/openjdk/jdk/commit/1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Michael McMahon on 25 Jun 2025 and was reviewed by Daniel Jeli?ski.
> 
> Thanks!
> Michael

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25973#pullrequestreview-2957710529

From michaelm at openjdk.org  Wed Jun 25 16:20:35 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 25 Jun 2025 16:20:35 GMT
Subject: [jdk25] Integrated: 8359268: 3 JNI exception pending defect groups in
 2 files
In-Reply-To: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>
References: <YobcZmZtEVdgHkUTW9W_-RoEIuajRCKTZ4oJsEVAkBo=.df8ef8ba-9986-4bdb-82db-d4aa42747553@github.com>
Message-ID: <VZJUoTce7I8j63pQ3yR-HVWU_7P-GzJpidnPlx9eyPI=.eebaf0d6-d941-4a4e-bcd9-a35a63180ca3@github.com>

On Wed, 25 Jun 2025 09:58:55 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1fa09052](https://github.com/openjdk/jdk/commit/1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Michael McMahon on 25 Jun 2025 and was reviewed by Daniel Jeli?ski.
> 
> Thanks!
> Michael

This pull request has now been integrated.

Changeset: a84946dd
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a84946dde4283fd423ef00ce3176bbe1985d7046
Stats:     32 lines in 5 files changed: 15 ins; 7 del; 10 mod

8359268: 3 JNI exception pending defect groups in 2 files

Reviewed-by: dfuchs, djelinski
Backport-of: 1fa090524a7c3bb5f2c92fb0f7217b9277ade9d9

-------------

PR: https://git.openjdk.org/jdk/pull/25973

From abarashev at openjdk.org  Wed Jun 25 19:51:41 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 25 Jun 2025 19:51:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
Message-ID: <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>

On Wed, 25 Jun 2025 07:42:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java line 247:
>> 
>>> 245:         if (quicEngine != null) {
>>> 246:             if (quicEngine instanceof QuicTLSEngineImpl engineImpl) {
>>> 247:                 return engineImpl.getAlgorithmConstraints();
>> 
>> Any particular reason constraints selection code was moved to `engineImpl.getAlgorithmConstraints()` and not kept in this file for consistency with `SSLEngine` and `SSLSocket`?
>
> Hello Artur, we currently don't expose the `HandshakeContext` outside of the `QuicTLSEngineImpl`. The `HandshakeContext` is what is needed to get the relevant user specified algorithm constraints. So I decided to let the `HandshakeContext` be an internal detail in `QuicTLSEngineImpl` and introduce the `getAlgorithmConstraints()` method on it. Do you think we should hand out the `HandshakeContext` outside of `QuicTLSEngineImpl`?

Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2167491992

From jpai at openjdk.org  Thu Jun 26 01:07:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Jun 2025 01:07:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
 <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
Message-ID: <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>

On Wed, 25 Jun 2025 19:48:47 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Hello Artur, we currently don't expose the `HandshakeContext` outside of the `QuicTLSEngineImpl`. The `HandshakeContext` is what is needed to get the relevant user specified algorithm constraints. So I decided to let the `HandshakeContext` be an internal detail in `QuicTLSEngineImpl` and introduce the `getAlgorithmConstraints()` method on it. Do you think we should hand out the `HandshakeContext` outside of `QuicTLSEngineImpl`?
>
> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.

Thank you Artur.

@dfuch this conversation can be resolved too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2167888998

From duke at openjdk.org  Thu Jun 26 02:12:20 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 26 Jun 2025 02:12:20 GMT
Subject: RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
Message-ID: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>

Please review this PR which use hostname not cname to check imply. And alse add test case.

If there are any problems please let me know and I will correct them promptly.

-------------

Commit messages:
 - 8360166: CodeSource.implies(): Wildcard host fails to imply specific host

Changes: https://git.openjdk.org/jdk/pull/25991/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360166
  Stats: 24 lines in 2 files changed: 10 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25991/head:pull/25991

PR: https://git.openjdk.org/jdk/pull/25991

From alanb at openjdk.org  Thu Jun 26 06:26:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 06:26:27 GMT
Subject: RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
In-Reply-To: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
References: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
Message-ID: <wELEjWaYJps-GT7gnvVqWalPLKOB_90XbxtHFSJT8UI=.accdc86c-fb69-4e2f-89b5-8445ce0b7c5f@github.com>

On Thu, 26 Jun 2025 01:43:51 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Please review this PR which use hostname not cname to check imply. And alse add test case.
> 
> If there are any problems please let me know and I will correct them promptly.

JDK-8356557 tracks updating CodeSource.imples so that it is not dependent on SocketPermission. This would move things on so that SocketPermission can be deprecated for removal (several permission classes have been deprecated for removal in JDK 25, but SocketPermission couldn't be done at the same time).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25991#issuecomment-3007269516

From duke at openjdk.org  Thu Jun 26 06:33:28 2025
From: duke at openjdk.org (Lei Zhu)
Date: Thu, 26 Jun 2025 06:33:28 GMT
Subject: RFR: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
In-Reply-To: <wELEjWaYJps-GT7gnvVqWalPLKOB_90XbxtHFSJT8UI=.accdc86c-fb69-4e2f-89b5-8445ce0b7c5f@github.com>
References: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
 <wELEjWaYJps-GT7gnvVqWalPLKOB_90XbxtHFSJT8UI=.accdc86c-fb69-4e2f-89b5-8445ce0b7c5f@github.com>
Message-ID: <5EU5mNIFWIGLqbStWtPSg-82RmxNH0cgCk_pKag1Z-g=.2cc22def-be09-4d4b-b062-e8f4c9c213d1@github.com>

On Thu, 26 Jun 2025 06:24:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> JDK-8356557 tracks updating CodeSource.imples so that it is not dependent on SocketPermission. This would move things on so that SocketPermission can be deprecated for removal (several permission classes have been deprecated for removal in JDK 25, but SocketPermission couldn't be done at the same time).

Thanks for replying, I will close this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25991#issuecomment-3007295972

From dclarke at openjdk.org  Thu Jun 26 10:52:44 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Thu, 26 Jun 2025 10:52:44 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion fails
 with non 100
Message-ID: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>

Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.

This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.

I also added a test to cover some possible responses.

-------------

Commit messages:
 - Response Message could be null

Changes: https://git.openjdk.org/jdk/pull/25999/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25999&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352502
  Stats: 195 lines in 3 files changed: 195 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25999.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25999/head:pull/25999

PR: https://git.openjdk.org/jdk/pull/25999

From dfuchs at openjdk.org  Thu Jun 26 11:07:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 11:07:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
 <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
 <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>
Message-ID: <HbAo_8dRZqucHKQBzukLcdNAGNyoF9r4rDB9jBhWAeI=.39bedbfb-bf00-4f94-ae19-bb2ab4086a51@github.com>

On Thu, 26 Jun 2025 01:04:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.
>
> Thank you Artur.
> 
> @dfuch this conversation can be resolved too.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2168804498

From dfuchs at openjdk.org  Thu Jun 26 11:19:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 11:19:28 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100
In-Reply-To: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
Message-ID: <JTC8lA9VyTUcnxi41dF1CvhokvkYYZMAXP9MreSBqlQ=.76405931-f0b4-46a8-be8d-e947e9b5bc8d@github.com>

On Thu, 26 Jun 2025 10:48:56 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
> 
> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
> 
> I also added a test to cover some possible responses.

test/jdk/java/net/httpclient/ExpectContinueResponseMessageTest.java line 128:

> 126:                     // ignore
> 127:                 } catch (IOException e) {
> 128:                     throw new RuntimeException(e);

This exception will be swallowed, it will have no effect.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2168824980

From dfuchs at openjdk.org  Thu Jun 26 11:34:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 11:34:31 GMT
Subject: RFR: 8352502: Response message is null if expect 100 assertion
 fails with non 100
In-Reply-To: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
References: <Wdwcz-OrrHA0ZkTpjFSZ4e7ThgwHIEtaousm-NYbRVQ=.d170fc75-0dbf-404b-b59b-85ad52b56ca4@github.com>
Message-ID: <0ZoDeYamXkQaRZYlnv-o8bK5x135ZGSpn-40eaEAtqo=.79b78164-fb10-4849-bedd-0df437a2d278@github.com>

On Thu, 26 Jun 2025 10:48:56 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> Currently if a request has set Expect-Continue and receives a non 100 response the `responseMessage` wouldn't be set.
> 
> This PR sets `responseMessage`, it also updates `getResponseMessage` to check if the message has already been set. This should match the way that `responseCode` is currently handled.
> 
> I also added a test to cover some possible responses.

test/jdk/java/net/httpclient/ExpectContinueResponseMessageTest.java line 98:

> 96:             while (!control.stop) {
> 97:                 try {
> 98:                     Socket socket = control.serverSocket.accept();

So this socket will not be closed... I understand closing it here might cause a reset...
Is that the reason for the catch clause on the client side?

test/jdk/java/net/httpclient/ExpectContinueResponseMessageTest.java line 124:

> 122:                     //send a wrong response
> 123:                     outputStream.write(control.statusLine.getBytes());
> 124:                     outputStream.flush();

If you added Content-Length: 0 the the status line (which should be better called response BTW) then you should be able to at least call `socket.shutdownOutput()` here.

test/jdk/java/net/httpclient/ExpectContinueResponseMessageTest.java line 149:

> 147:         String body = "Testing: " + expectedCode;
> 148:         Control control = this.control;
> 149:         control.statusLine = statusLine + "\r\n\r\n";

Shouldn't you add Content-Length: 0 here?

test/jdk/java/net/httpclient/ExpectContinueResponseMessageTest.java line 159:

> 157:         } catch (Exception ex) {
> 158:             // swallow the exception
> 159:         }

@DarraghClarke - I am curious, is this catch clause necessary? If it is maybe you could improve the comment here to explain why it is necessary.

test/jdk/java/net/httpclient/ExpectContinueResponseMessageTest.java line 167:

> 165:         assertTrue(expectedMessage.equals(responseMessage),
> 166:                 String.format("Expected Response Message  %s, instead received %s",
> 167:                         expectedMessage, responseMessage));

maybe the connection should be explicitely closed at the end.
maybe the accepted socket should be added to Control and closed here too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2168831749
PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2168849333
PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2168833905
PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2168825892
PR Review Comment: https://git.openjdk.org/jdk/pull/25999#discussion_r2168844935

From jpai at openjdk.org  Thu Jun 26 13:25:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 26 Jun 2025 13:25:50 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>
Message-ID: <afmL2M4nq0XFNAahf4ScMmsrMGx5GAE2esNJULn45ls=.e543668e-8ec7-4721-a389-8cb4df77a297@github.com>

On Tue, 22 Apr 2025 16:15:29 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 506 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: update H3InsertionsLimitTest to start after receival of client settings
>>  - merge latest changes from master branch
>>  - quic: separate out the idle termination timer and the STREAM_DATA_BLOCKED timer
>>  - quic: simplify idle timeout management
>>  - http3: rely on the sole isOpen() method instead of isOpen() and isClosed()
>>  - quic: do not let h3 idle (in pool) timeout to influence the quic transport idle timeout
>>  - merge latest changes from master branch
>>  - http3: improve H3ConnectionPoolTest.java
>>  - Fix snippet
>>  - ... and 496 more: https://git.openjdk.org/jdk/compare/8d33ea73...d4984d5e
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226:
> 
>> 224:                     chc.peerSupportedAuthorities == null ? null :
>> 225:                             chc.peerSupportedAuthorities.clone(),
>> 226:                     chc.algorithmConstraints);
> 
> These `algorithmConstraints` won't include `peerSupportedSignAlgs`.

@dfuch this too can be marked as resolved. The updated code in this PR now calls `X509KeyManagerImpl.chooseClientAlias(String[] keyTypes, Principal[] issuers, QuicTLSEngineImpl quicTLSEngine)` which internally picks up the `peerSupportedSignAlgs` from the handshake session.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169064530

From dfuchs at openjdk.org  Thu Jun 26 14:17:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 14:17:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v8]
In-Reply-To: <afmL2M4nq0XFNAahf4ScMmsrMGx5GAE2esNJULn45ls=.e543668e-8ec7-4721-a389-8cb4df77a297@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <jvZfcaNkmERbDbJ7mXSp3TxkEPv7AjSm2AJIgAhZahw=.b0567300-9711-41e2-a079-854cd47dfbc6@github.com>
 <afmL2M4nq0XFNAahf4ScMmsrMGx5GAE2esNJULn45ls=.e543668e-8ec7-4721-a389-8cb4df77a297@github.com>
Message-ID: <jB-0b1xVLntHpirb5us68Lep8jcCKDgFLqQBbdhNLcc=.e813f3e7-2562-4014-9d60-6d0afa1b49ac@github.com>

On Thu, 26 Jun 2025 13:22:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 226:
>> 
>>> 224:                     chc.peerSupportedAuthorities == null ? null :
>>> 225:                             chc.peerSupportedAuthorities.clone(),
>>> 226:                     chc.algorithmConstraints);
>> 
>> These `algorithmConstraints` won't include `peerSupportedSignAlgs`.
>
> @dfuch this too can be marked as resolved. The updated code in this PR now calls `X509KeyManagerImpl.chooseClientAlias(String[] keyTypes, Principal[] issuers, QuicTLSEngineImpl quicTLSEngine)` which internally picks up the `peerSupportedSignAlgs` from the handshake session.

Thanks. done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169182330

From dfuchs at openjdk.org  Thu Jun 26 16:14:41 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 16:14:41 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <HbAo_8dRZqucHKQBzukLcdNAGNyoF9r4rDB9jBhWAeI=.39bedbfb-bf00-4f94-ae19-bb2ab4086a51@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>
 <bzvffTIetPOaCPk8bKt4q77OBVIyKKdWmJGHZy8sYNE=.d284be58-fc5b-4119-a77f-b599644aab03@github.com>
 <U6fLg8WGJxG5SNHdIG2vRabKNioqjOYB1o04zr_UHWw=.c26afd8f-a9f1-4483-a9cd-393e8ffce2b7@github.com>
 <ra9gm3RuAwdsQL_FoxIW9XtcAsZcnaQQTmfaVkWYAzI=.8ee132d1-06bf-4fef-8ff5-ccbe4ba4d0f9@github.com>
 <pdvp8wxixS97HINttsn0fe2GujbNR_izHQMG_ONNFR8=.6e2e2b37-c841-4f84-bc5f-c44197f9baea@github.com>
 <HbAo_8dRZqucHKQBzukLcdNAGNyoF9r4rDB9jBhWAeI=.39bedbfb-bf00-4f94-ae19-bb2ab4086a51@github.com>
Message-ID: <DK8078guiUeaohxiP9d16rdJY4rX9HlqxsWyuBowY6E=.5aeb666f-c640-473a-ba3e-edaad0705fc1@github.com>

On Thu, 26 Jun 2025 11:04:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Thank you Artur.
>> 
>> @dfuch this conversation can be resolved too.
>
> Done

> Hi Jaikiran! Sounds good. It's likely we are going to re-work this code anyhow when we make QUIC engine public in the next iteration. We had a discussion with Daniel about it today.

Note that there's no definite plan to provide a public API for that yet. This is something that we will need to evaluate once the current iteration is integrated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169422961

From dfuchs at openjdk.org  Thu Jun 26 16:36:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 16:36:40 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:

 - merge latest changes from master branch
 - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
 - retry the ResetControlStream test as needed
 - http3: fix pending connection and reconnection on stream limit reached logic
 - http3: pending acknowledgement should be registered before actually sending the packet
 - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
 - http3: improve exceptions in Http3ServerExchange.java
 - http3: fix exception handling in CancelRequestTest.java
 - http3: review feedback - revert HPACK.java
 - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
 - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=08
  Stats: 105143 lines in 471 files changed: 102311 ins; 1336 del; 1496 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From dfuchs at openjdk.org  Thu Jun 26 17:04:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 17:04:47 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 70:

> 68:         if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
> 69:             return false;
> 70:         }

Would there be a way to check the implementation of the X509TrustManager here too? Or can we only do that later on during the handshake?

src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 126:

> 124:      *
> 125:      * @param peerHost The peer hostname or IP address. Can be null.
> 126:      * @param peerPort The peer port, can be -1 if the port is unknown

Would that be the hostname in the URI, or in the AltService?
Maybe we could add an `@apiNote` here to clarify it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169497642
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169502934

From dfuchs at openjdk.org  Thu Jun 26 17:32:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 17:32:50 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <PZ-Qh13ciNdoU-HCI-8y7p6kxzdz5diMz8fhqmLeMcQ=.13aa42e5-34d7-4412-b22b-13dbc299d914@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/jdk/internal/net/quic/QuicVersion.java line 33:

> 31: 
> 32: /**
> 33:  * Represents the Quic versions defined in their corresponding RFCs

Maybe add a note here to warn that new enum constants may be added to this enum in the future.

src/java.base/share/classes/jdk/internal/net/quic/QuicVersion.java line 40:

> 38:     QUIC_V2(0x6b3343cf); // RFC 9369
> 39: 
> 40:     private final int versionNumber;

Could add a comment here to say that the version is defined as a 32bits unsigned number, and we chose a simple int to represent it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169538372
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169549829

From djelinski at openjdk.org  Thu Jun 26 17:38:44 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 17:38:44 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>
Message-ID: <GPG7cbPxZnW8iIIBCLJZU84WTjiPuVHCDYEuvc6GdvQ=.1070c0c7-3006-46b0-9cd1-f72a8e2bd5b6@github.com>

On Thu, 26 Jun 2025 16:57:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 70:
> 
>> 68:         if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
>> 69:             return false;
>> 70:         }
> 
> Would there be a way to check the implementation of the X509TrustManager here too? Or can we only do that later on during the handshake?

that's what the `isUsableWithQuic` method below does.

> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 126:
> 
>> 124:      *
>> 125:      * @param peerHost The peer hostname or IP address. Can be null.
>> 126:      * @param peerPort The peer port, can be -1 if the port is unknown
> 
> Would that be the hostname in the URI, or in the AltService?
> Maybe we could add an `@apiNote` here to clarify it.

Well the javadoc here was written to match the one on SSLContext#createSSLEngine. The peer information is used for caching, but it's also used in the SNI extension, so ideally users should use the URI address, not the alt service one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169562950
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169561558

From djelinski at openjdk.org  Thu Jun 26 17:44:48 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 17:44:48 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <I8PsbJp206UJRkv1vA-GuQVq8rimRLZr1eeSZr6JDqE=.2165bb62-ae07-4f1f-8fbf-748e54450765@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <I8PsbJp206UJRkv1vA-GuQVq8rimRLZr1eeSZr6JDqE=.2165bb62-ae07-4f1f-8fbf-748e54450765@github.com>
Message-ID: <7Im8fuoKvFsClr07Sq8cJ1LhU6LuNK6U44j7_12P-P0=.ca3982f1-b4ce-4375-a1f6-595732c4e104@github.com>

On Tue, 22 Apr 2025 16:21:30 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 221:
> 
>> 219:                             chc.peerSupportedAuthorities.clone(),
>> 220:                     engine);
>> 221:             // TODO should we have a method that can take QuicTLSEngine?
> 
> Yes, I think we should have a method for `QuicTLSEngine` in `X509KeyManagerImpl`. In that new method we should use session's `peerSupportedSignAlgs` to construct algorithm constraints the same way we do it for `SSLSocketImpl` and for `SSLEngineImpl`. This is per TLSv1.3 RFC:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3

Done in 1b75ef8b8579f4f8682bff28f40ed394401e8805

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169578294

From djelinski at openjdk.org  Thu Jun 26 18:02:47 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:02:47 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <sWlJhX9smaVlYnJXwnhev6rXJBTEgIackPrRITGTs9g=.efaa1edf-d0fe-4c6b-8205-a20ae68adcc0@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <sWlJhX9smaVlYnJXwnhev6rXJBTEgIackPrRITGTs9g=.efaa1edf-d0fe-4c6b-8205-a20ae68adcc0@github.com>
Message-ID: <xQA5Rtc-9ei4bQFRIlU-CneJjxE-NDWeiN-_PjdUXoA=.dd732c03-840f-412d-a8c6-a5f3a270f32e@github.com>

On Fri, 25 Apr 2025 19:42:34 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 532:
> 
>> 530:     }
>> 531: 
>> 532:     public boolean isQuic() {
> 
> This method never called.

Removed in 9f7f9e190b124d569eae8bf1df5e6c076ad00a06

> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 275:
> 
>> 273:         final X509Certificate[] trustedChain = v.validate(chain, null,
>> 274:                 responseList, constraints, authType);
>> 275:         if (sslParameters != null && handshakeSession != null) {
> 
> Looks like this `if` block is not needed: `sslParameters != null` condition is always `true`, and we should throw an exception in the beginning of the method if session is null.

Moved earlier in 10e3e3508415b901fe0008da4edb5c4f1e8eb85d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169589570
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169588546

From djelinski at openjdk.org  Thu Jun 26 18:02:49 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:02:49 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <BIio-Z0QtUmG0jk3kL8gxJjsOIxydScAlPb5DYbLUtQ=.4b83e750-328e-46c9-8434-aca1ea98a646@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <BIio-Z0QtUmG0jk3kL8gxJjsOIxydScAlPb5DYbLUtQ=.4b83e750-328e-46c9-8434-aca1ea98a646@github.com>
Message-ID: <hob__05VFHcenn0aV8VV6oSmD0oJ_JRqboqnTqEEDN8=.66784a2c-8d15-43a0-b959-e8057a4620a1@github.com>

On Tue, 22 Apr 2025 16:49:10 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 286:
> 
>> 284:         X509Certificate[] trustedChain = v.validate(chain, null,
>> 285:                 Collections.emptyList(),
>> 286:                 sslParameters.getAlgorithmConstraints(), authType);
> 
> SSLParameter's algorithm constraints don't include constraints specified in `java.security` config file.

Addressed in 633375f342b6dbf1fc608f9b9abc9bf15c15ada4

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169586259

From djelinski at openjdk.org  Thu Jun 26 18:02:50 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:02:50 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v2]
In-Reply-To: <MQP9ydYlNHaWHQMfVjWUnVXaB8To0aV9rSXgT1Pad_M=.84b03782-6aa0-4a21-85e1-3c59d7e9c7bc@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <4NiUu2j0KfeAitRjY5rmWaVfRwMkdqPHowYfriXMZYY=.178ad86f-9d4a-424e-a9cb-b7202b33e840@github.com>
 <MQP9ydYlNHaWHQMfVjWUnVXaB8To0aV9rSXgT1Pad_M=.84b03782-6aa0-4a21-85e1-3c59d7e9c7bc@github.com>
Message-ID: <Nx1-gHh-L6XEGFXgtEHv-cpuVh9ckOwJ1qDQLHRNhiI=.ef26aa39-16a3-4df6-8f12-b43676c50069@github.com>

On Mon, 28 Apr 2025 18:52:10 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 409 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: add missing <p> separator to Http3DiscoveryMode.ALT_SVC API documentation
>>  - http3: improve documentation for Http3DiscoveryMode.ALT_SVC
>>  - http3: Use AlgorithmConstraints and OCSP responses when validating server certificate during QUIC TLS handshake
>>  - http3: Artur's review - use SecurityUtils.removeFromDisabledTlsAlgs() in test
>>  - http3: minor improvement to log message
>>  - http3: Artur's review - remove commented out code from test
>>  - http3: Artur's review - make methods package private
>>  - http3: qpack - allow 0 capacity when max capacity is 0
>>  - Remove flow control from stream limit comments
>>  - ... and 399 more: https://git.openjdk.org/jdk/compare/1ec64811...4da61bbe
>
> test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java line 130:
> 
>> 128:                             + "expect UnsupportedProtocolVersionException",
>> 129:                     () -> connect(uriString, new SSLParameters(
>> 130:                             new String[] { "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA" },
> 
> Shouldn't this be "TLS_AES_128_GCM_SHA256" (per the test comment above)?

Corrected in 368f9b58736e4eb4f37d043ecd4df28d316fec49

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169591633

From dfuchs at openjdk.org  Thu Jun 26 18:13:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 18:13:40 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <GPG7cbPxZnW8iIIBCLJZU84WTjiPuVHCDYEuvc6GdvQ=.1070c0c7-3006-46b0-9cd1-f72a8e2bd5b6@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <bRfgBwVg54V3xLBoM7pkcN0f62GCRbMl0f1M0ibT3RQ=.e0d21848-79d2-458b-9310-a293f02bbf49@github.com>
 <GPG7cbPxZnW8iIIBCLJZU84WTjiPuVHCDYEuvc6GdvQ=.1070c0c7-3006-46b0-9cd1-f72a8e2bd5b6@github.com>
Message-ID: <lHsCVZKhak3qpFTyHhcICl0hBmTgGAo082NpDWZtSD8=.629d1aa9-52cc-4337-96a6-11709b4ee40c@github.com>

On Thu, 26 Jun 2025 17:36:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 70:
>> 
>>> 68:         if (!(underlyingImpl instanceof SSLContextImpl ssci)) {
>>> 69:             return false;
>>> 70:         }
>> 
>> Would there be a way to check the implementation of the X509TrustManager here too? Or can we only do that later on during the handshake?
>
> that's what the `isUsableWithQuic` method below does.

Oh! I had missed that. Very good then!

>> src/java.base/share/classes/jdk/internal/net/quic/QuicTLSContext.java line 126:
>> 
>>> 124:      *
>>> 125:      * @param peerHost The peer hostname or IP address. Can be null.
>>> 126:      * @param peerPort The peer port, can be -1 if the port is unknown
>> 
>> Would that be the hostname in the URI, or in the AltService?
>> Maybe we could add an `@apiNote` here to clarify it.
>
> Well the javadoc here was written to match the one on SSLContext#createSSLEngine. The peer information is used for caching, but it's also used in the SNI extension, so ideally users should use the URI address, not the alt service one.

OK. Maybe that would deserve a note - since with HTTP/3 we have potentially two addresses and two ports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169650283
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169653256

From djelinski at openjdk.org  Thu Jun 26 18:13:45 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Jun 2025 18:13:45 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <JeKINmYcmLWz8AVolTvNOTzymhXNuV6w2mguL6VAJYg=.7f38e31b-5a56-48bf-b72e-63f829175234@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/Finished.java line 852:

> 850:                     QuicTLSEngineImpl engine =
> 851:                             (QuicTLSEngineImpl) shc.conContext.transport;
> 852:                     engine.deriveOneRTTKeys();

We should not derive the server's 1RTT read keys before processing the client's Finished message.

Also, we could skip calculating the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169636620

From dfuchs at openjdk.org  Thu Jun 26 18:13:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 26 Jun 2025 18:13:46 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java line 49:

> 47:     static final ExtensionConsumer chOnLoadConsumer =
> 48:             new CHKeyShareConsumer();
> 49:     static final HandshakeAbsence chOnTradeAbsence =

Could we fix that one in mainline to remove this file from the PR?

src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 168:

> 166:         throw new UnsupportedOperationException();
> 167:     }
> 168: 

Do we need those two methods here? Or could we just have them on `QuicEngineOutputRecord` and do the appropriate cast at the point they are called?
Or do we have that at this level for performance reasons?

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 61:

> 59:     static final HandshakeConsumer chOnTradeConsumer =
> 60:             new CHPreSharedKeyUpdate();
> 61:     static final HandshakeAbsence chOnTradeAbsence =

Could we bring this change to mainline to remove this file from this PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169560172
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169583454
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2169585913

From duke at openjdk.org  Fri Jun 27 01:51:46 2025
From: duke at openjdk.org (Lei Zhu)
Date: Fri, 27 Jun 2025 01:51:46 GMT
Subject: Withdrawn: 8360166: CodeSource.implies(): Wildcard host fails to imply
 specific host
In-Reply-To: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
References: <ur4mHeoj7jMT70bdThSjpfNk-DZgAS7pP0jeNwrs0oM=.36eb133c-a364-423b-824b-54332cf03d77@github.com>
Message-ID: <9p92Lkx7ZcKmG54yTC4izWDWqpA3F2vNRiy9fIS0PdY=.744b636a-8123-47bd-bb42-86a0a9f8f609@github.com>

On Thu, 26 Jun 2025 01:43:51 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Please review this PR which use hostname not cname to check imply. And alse add test case.
> 
> If there are any problems please let me know and I will correct them promptly.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/25991

From dfuchs at openjdk.org  Fri Jun 27 08:19:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 08:19:06 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <qqRnOdt43mTxoxspZcXBrov-Ic0EQfzxxVIrLM_z7Ro=.9ae22464-e982-481b-9482-7bd2db47f7c7@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/QuicCipher.java line 375:

> 373:             super(cipherSuite, secret, new T13AESHPCipher(hp), keyPhase);
> 374:             this.key = key;
> 375:             this.iv = iv;

Suggestion:

            this.iv = iv.clone();

src/java.base/share/classes/sun/security/ssl/QuicCipher.java line 451:

> 449:             super(cipherSuite, secret, new T13AESHPCipher(hp), keyPhase);
> 450:             this.key = key;
> 451:             this.iv = iv;

Suggestion:

            this.iv = iv.clone();

src/java.base/share/classes/sun/security/ssl/QuicCipher.java line 619:

> 617:             super(cipherSuite, secret, new T13CC20HPCipher(hp), keyPhase);
> 618:             this.key = key;
> 619:             this.iv = iv;

Suggestion:

            this.iv = iv.clone();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171138262
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171167148
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171168244

From dfuchs at openjdk.org  Fri Jun 27 09:54:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 09:54:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <sRrFfMwi7-AB95otK9r0yVDjwkkAOzol6qh0J_00r6M=.6068f49c-0d79-4030-952b-6b4924e87d41@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/QuicTransportParametersExtension.java line 37:

> 35: /**
> 36:  * QuicTransportParametersExtension is an implementation of RFC 9000.
> 37:  * It is only used by QUIC connections.

I believe referencing RFC 9001 Section 8.2 would be more appropriate here. 
The QUIC transport parameters themselves are defined in RFC 9000, but the use of the quic_transport_parameters extension in the ClientHello and the EncryptedExtensions messages is described in RFC 9001.
Or else the purpose and description of this class could be clarified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171444954

From dfuchs at openjdk.org  Fri Jun 27 10:00:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 10:00:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <sfwzdQ0sp1xjfYi6rP-PX9FDUyrSIRH96W4tU1ilvxo=.56a5f3b2-661f-486f-8c8a-82f00c03ab15@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/SSLExtension.java line 461:

> 459:                                 KeyShareExtension.hrrStringizer),
> 460: 
> 461:     // Extension defined in RFC 9000

Shouldn't this be RFC 9001 here too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171464016

From djelinski at openjdk.org  Fri Jun 27 10:27:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Jun 2025 10:27:53 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <zfAyPC-xmCsYT0LtOlVqaJN17hgFb8DZhWUP1rwbSWM=.571fc63f-d165-40b6-b374-d2ab743058f0@github.com>
Message-ID: <Sio-byu14_9C3KXO2V6faMHvvKR9eVzdgl4Uc5ruMlQ=.8ef12c8f-af20-4858-9bf2-ebee075f0202@github.com>

On Thu, 26 Jun 2025 17:43:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/OutputRecord.java line 168:
> 
>> 166:         throw new UnsupportedOperationException();
>> 167:     }
>> 168: 
> 
> Do we need those two methods here? Or could we just have them on `QuicEngineOutputRecord` and do the appropriate cast at the point they are called?
> Or do we have that at this level for performance reasons?

This was done to match the surrounding code. There's a bunch of methods in OutputRecord that throw UOE and are overridden by one class only. I suppose it would be cleaner to just do the cast, but "when in Rome, do as the Romans do"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171543796

From djelinski at openjdk.org  Fri Jun 27 11:25:54 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Jun 2025 11:25:54 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <wg6q7AM-mNmEpoWP-0eNamXxRfCOc_eNwYJoLXWHGPI=.e203a18c-4ad0-4305-a09e-ce129f47e024@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 216:

> 214: 
> 215:     // true if previous attempt resulted in streamLimitReached
> 216:     public boolean hasReachedStreamLimit(Version version) { return streamLimitReached == version; }

it seems that `streamLimitReached` will either be equal to `version` or `null`. If that's the case, let's use a boolean instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171687180

From djelinski at openjdk.org  Fri Jun 27 11:39:55 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Jun 2025 11:39:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:

> 119:     }
> 120: 
> 121:     // Keeps track of the underlying connection when establishing an HTTP/2

since this is now used with HTTP/3, should we update this comment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171720043

From dfuchs at openjdk.org  Fri Jun 27 11:39:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 11:39:55 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <wg6q7AM-mNmEpoWP-0eNamXxRfCOc_eNwYJoLXWHGPI=.e203a18c-4ad0-4305-a09e-ce129f47e024@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <wg6q7AM-mNmEpoWP-0eNamXxRfCOc_eNwYJoLXWHGPI=.e203a18c-4ad0-4305-a09e-ce129f47e024@github.com>
Message-ID: <WtVK68Cxlrn-AGssHcRhjZzKNG5CHGzfxZph2sG_T04=.3da5dfaf-f470-40dd-839d-32234ce5c2a3@github.com>

On Fri, 27 Jun 2025 11:22:51 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 216:
> 
>> 214: 
>> 215:     // true if previous attempt resulted in streamLimitReached
>> 216:     public boolean hasReachedStreamLimit(Version version) { return streamLimitReached == version; }
> 
> it seems that `streamLimitReached` will either be equal to `version` or `null`. If that's the case, let's use a boolean instead.

That's a good point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171718034

From jpai at openjdk.org  Fri Jun 27 12:42:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 27 Jun 2025 12:42:46 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <lBpC_n5PukNWbhsUIuAda93LMd1uuI-5k4ruCKSwB6c=.ed2059dc-6e32-4616-9572-096b9aff0f7f@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Alan, Daniel, I don't have anything more planned in this PR. Michael has approved this change. If the current state looks OK to you too, then I'll go ahead and integrate this next week after one final round of testing this in the CI.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3012942623

From jpai at openjdk.org  Fri Jun 27 12:42:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 27 Jun 2025 12:42:47 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <LLrH_1nc3-5wLLQk1VAUoKJAK11YCT4bST0iE1HISao=.4b47ae2a-d4a0-476a-a10c-baa4c7014d42@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
 <0J9FpqcZ0P2JZYQc1iCDL4EpTZez1vPJQObQOQaiIQE=.674a6bdd-5512-427f-8d3b-8fdebfea36ea@github.com>
 <LLrH_1nc3-5wLLQk1VAUoKJAK11YCT4bST0iE1HISao=.4b47ae2a-d4a0-476a-a10c-baa4c7014d42@github.com>
Message-ID: <Cq44LOx1Ldq8jEVRfweNNSWeGkMwBcZDTq1HggNce5k=.e0fda06e-fcce-45e4-8621-950bb6802d4f@github.com>

On Tue, 17 Jun 2025 09:26:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 96:
>> 
>>> 94:                 // do not attempt any more connections
>>> 95:                 break;
>>> 96:             }
>> 
>> hmm... interesting: so we don't need to leave the socket open to increase the backlog. I guess the server side has to accept the socket and read the FIN, so the backlog won't be decremented until the socket is accepted (even if it's already closed on the client side).
>
> That's a good question. The current behaviour (on Windows and *nix) is that, closing the Socket which initiated the connection doesn't affect the number of connections that were put into a pending queue (backlog) on the server side. I will need to read up a bit to see if that is specified or if it is merely an implementation detail.

> hmm... interesting: so we don't need to leave the socket open to increase the backlog. I guess the server side has to accept the socket and read the FIN, so the backlog won't be decremented until the socket is accepted (even if it's already closed on the client side).

I couldn't find this specified anywhere, but I went through the Linux source code. In that implementation, the backlog is used to size the accept queue. When a connection is made by a client, the count is incremented and tracked against the backlog value. When a connection is `accept()` that count is decremented. So unless the server `accept()`s a connection, the counter keeps increasing and thus hitting the backlog limit. This behaviour matches what's being done in this test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2171963956

From dfuchs at openjdk.org  Fri Jun 27 12:49:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 12:49:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <sZqtNoTLqHcpgpaIQ3htp1aSzrAgGkUyLx7mxR9P8jg=.5bf2e89f-2776-4a82-8eff-83ac07995836@github.com>
Message-ID: <0uFs6gr4vZ3wgNvAsWhQfjl1_Wq9njUMcHHO-atXhJ0=.60d8e149-5ca9-4b8f-8268-76ca4b03e31a@github.com>

On Fri, 27 Jun 2025 11:37:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 121:
> 
>> 119:     }
>> 120: 
>> 121:     // Keeps track of the underlying connection when establishing an HTTP/2
> 
> since this is now used with HTTP/3, should we update this comment?

I have verified the other comments in this class and updated to mention or HTTP/3 in a few places in this class, in my local repo. Will appear the next time I sync this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2171978343

From alanb at openjdk.org  Fri Jun 27 12:53:44 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Jun 2025 12:53:44 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <tBV0Sel0gopfT5tOTce3izf7_C15zNAglgHWWDFuzeY=.0cb739aa-e550-4f3f-83b8-56848eb36f52@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

src change is okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25819#pullrequestreview-2966482054

From dfuchs at openjdk.org  Fri Jun 27 12:53:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 12:53:44 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <-aaZ8GWRNfYTy0XExaS5ycPBRpHCXsSjutIC92lI7is=.786a50d8-520b-4ca0-ad57-78508bdb7558@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25819#pullrequestreview-2966475358

From dfuchs at openjdk.org  Fri Jun 27 13:21:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 13:21:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <ZUOzzdiol4GwFgYqiR8l23DWvdHvBXfdVn4DUmDIa14=.b0fbc9df-0013-4c23-8d17-58d82f556420@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java line 50:

> 48:     static final ExtensionConsumer chOnLoadConsumer =
> 49:             new CHSupportedGroupsConsumer();
> 50:     static final HandshakeAbsence chOnTradeAbsence =

Another one that could disappear if we fixed that typo in mainline first.
@djelinski would you be willing to do that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172033315

From dfuchs at openjdk.org  Fri Jun 27 13:24:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 13:24:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <FmP9p94joz0UZx-X4ijp-ssEuOP5866kdRKiu1scKH8=.994d9c2d-781f-481f-930b-18c4a5cc1621@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 224:

> 222:             // TODO in future, when QuicTLSEngine might become a public exported interface
> 223:             // we should have a method on javax.net.ssl.X509ExtendedKeyManager that
> 224:             // takes QuicTLSEngine.

Suggestion:

            // TODO in future, if QuicTLSEngine ever becomes a public exported interface
            // we might have a method on javax.net.ssl.X509ExtendedKeyManager that
            // takes QuicTLSEngine.

src/java.base/share/classes/sun/security/ssl/X509Authentication.java line 318:

> 316:                 // TODO in future, when QuicTLSEngine might become a public exported interface
> 317:                 // we should have a method on javax.net.ssl.X509ExtendedKeyManager that
> 318:                 // takes QuicTLSEngine.

Suggestion:

                // TODO in future, if QuicTLSEngine ever becomes a public exported interface
                // we might have a method on javax.net.ssl.X509ExtendedKeyManager that
                // takes QuicTLSEngine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172037488
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172039159

From jpai at openjdk.org  Fri Jun 27 13:45:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 27 Jun 2025 13:45:47 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <3LBsjxpWNEAajok5P7-DTOKRKkUmGmyjudWTWlshZ64=.3780c643-dd12-489f-a237-cc3b32b642e0@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <3LBsjxpWNEAajok5P7-DTOKRKkUmGmyjudWTWlshZ64=.3780c643-dd12-489f-a237-cc3b32b642e0@github.com>
Message-ID: <uR8156yK3B-4z7Y1d-Iso0zq9Whzt3txQyBMwNk0_D4=.b6045511-7f14-49d5-aa65-154bd067c5ca@github.com>

On Wed, 23 Apr 2025 06:16:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the got local
>
> Stay open

Hello @TheShermanTanker, I see that this PR is marked as ready for integration since several months. But there's also your comment which says:

> I still need awt and accessibility to be approved 

I don't see any client area changes in this PR. Is there anything that's needed to be done to move forward with integrating this? I don't mean that you should integrate it "now" - I see that this branch hasn't been merged against master branch for several months, so that would be the first thing to do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3013136883

From dfuchs at openjdk.org  Fri Jun 27 14:04:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 14:04:54 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <Ti2XlE8-hiDRBn_bXh-fgFvE9jNNH68iIHF57tmBKP0=.b709481d-8405-4886-8465-808b14dd000d@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/java/net/http/package-info.java line 43:

> 41:  * Version 3 (HTTP/3)</a>, the <a href="https://tools.ietf.org/html/rfc7540">
> 42:  * Hypertext Transfer Protocol Version 2 (HTTP/2)</a>, the
> 43:  * <a href="https://tools.ietf.org/html/rfc2616">

It is strange to link to a different place here than in the `@spec` tags below. I will fix that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172115870

From dfuchs at openjdk.org  Fri Jun 27 15:02:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 27 Jun 2025 15:02:37 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <4t44zDtXWaOP26sXJUh2TDXhARbG57u_l2oU9CSZRdA=.0731d03f-b9ae-4160-9a23-7e809db2d28a@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/AltServicesRegistry.java line 186:

> 184:             return new Origin(scheme, originHost, addr.getPort());
> 185:         }
> 186:     }

I don't think it's a good idea to rely on `InetSocketAddress::getHostString()` as this can change depending on how the `InetSocketAddress` was constructed and whether `getHost()` has been called. 
I believe it would be more reliable to add a new `URI origin` parameter to the `HttpConnection` constructor. We could build that origin from the request URI for which the connection was created. Probably `origin` should be `null` for `PlainProxyConnection`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172224088

From jpai at openjdk.org  Mon Jun 30 02:01:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 02:01:09 GMT
Subject: RFR: 8330940: Impossible to create a socket backlog greater than
 200 on Windows 8+ [v2]
In-Reply-To: <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
 <A3RzfHgozdVorCxO-ozDuZLnhE54QaXIEANMCrWIdLk=.0729a3fd-0966-4776-ac6e-42f4cb2eae62@github.com>
Message-ID: <Xm8HD6U8mqI2IxxeZ6RYA8c-zNWidG8PwKWXGfUEedk=.9c27d19b-733f-49e1-932a-24205ee04315@github.com>

On Mon, 16 Jun 2025 09:44:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
>> 
>> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
>> 
>> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
>> 
>> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - include a test for AsynchronousServerSocketChannel
>  - System.err instead of System.out
>  - trim down code comment
>  -  > 200 instead of >= 200

Thank you all for the reviews. tier1, tier2 and tier3 testing with this change continues pass. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25819#issuecomment-3017500571

From jpai at openjdk.org  Mon Jun 30 02:01:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 02:01:09 GMT
Subject: Integrated: 8330940: Impossible to create a socket backlog greater
 than 200 on Windows 8+
In-Reply-To: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
References: <vl3aQErBr52AWrFPUrtq3zcj5_hpTukp-4MrIUNaOco=.e2457fa6-15ab-463c-8296-0a4c223bf68c@github.com>
Message-ID: <3H9JZaWTj_HZonCc7Dpxb8dV5UxdYJySR0qwej_KfG8=.e204ad3e-60e8-4d38-8b60-4ad57c672002@github.com>

On Mon, 16 Jun 2025 06:54:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to enhance the implementation of `ServerSocket` and `ServerSocketChannel` to allow for `backlog` values to be greater than 200 on Windows? This addresses https://bugs.openjdk.org/browse/JDK-8330940.
> 
> As noted in that enhancement request, right now on Windows, if the backlog is specified to be more than 200, then Windows caps it to a platform internal `SOMAXCONN`. As noted in the documentation here https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen applications can increase that limit by using the `SOMAXCONN_HINT` macro. That macro then adjusts the value to be between 200 and 65535, thus allowing for a higher backlog of connections.
> 
> The commit in this PR uses this macro when the specified backlog is 200 or more. A new jtreg test has been introduced to verify this change. This test and other existing tests in tier1, tier2 and tier3 continue to pass.
> 
> A similar restriction on the backlog value applies in Linux too https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.rst#tcp-variables. But from what I can see, unlike Windows, it cannot be adjusted when calling `listen()`.

This pull request has now been integrated.

Changeset: 4dd1b3a6
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4dd1b3a6100f9e379c7cee3c699d63d0d01144a7
Stats:     117 lines in 2 files changed: 117 ins; 0 del; 0 mod

8330940: Impossible to create a socket backlog greater than 200 on Windows 8+

Reviewed-by: michaelm, dfuchs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25819

From djelinski at openjdk.org  Mon Jun 30 08:10:57 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Jun 2025 08:10:57 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <sRrFfMwi7-AB95otK9r0yVDjwkkAOzol6qh0J_00r6M=.6068f49c-0d79-4030-952b-6b4924e87d41@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <sRrFfMwi7-AB95otK9r0yVDjwkkAOzol6qh0J_00r6M=.6068f49c-0d79-4030-952b-6b4924e87d41@github.com>
Message-ID: <YDH5OpjsRwpC3fX3dNWSxsAGtCcUMa1eIe3d_danADw=.4abfcee6-7fdc-4e3c-9736-44be7f686b86@github.com>

On Fri, 27 Jun 2025 09:49:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.base/share/classes/sun/security/ssl/QuicTransportParametersExtension.java line 37:
> 
>> 35: /**
>> 36:  * QuicTransportParametersExtension is an implementation of RFC 9000.
>> 37:  * It is only used by QUIC connections.
> 
> I believe referencing RFC 9001 Section 8.2 would be more appropriate here. 
> The QUIC transport parameters themselves are defined in RFC 9000, but the use of the quic_transport_parameters extension in the ClientHello and the EncryptedExtensions messages is described in RFC 9001.
> Or else the purpose and description of this class could be clarified.

Most of the extensions have a generic JavaDoc, I will update this one to match the others.

> src/java.base/share/classes/sun/security/ssl/SSLExtension.java line 461:
> 
>> 459:                                 KeyShareExtension.hrrStringizer),
>> 460: 
>> 461:     // Extension defined in RFC 9000
> 
> Shouldn't this be RFC 9001 here too?

Will be updated in the next refresh.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174477328
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174479150

From jpai at openjdk.org  Mon Jun 30 09:14:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 09:14:56 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <4t44zDtXWaOP26sXJUh2TDXhARbG57u_l2oU9CSZRdA=.0731d03f-b9ae-4160-9a23-7e809db2d28a@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <4t44zDtXWaOP26sXJUh2TDXhARbG57u_l2oU9CSZRdA=.0731d03f-b9ae-4160-9a23-7e809db2d28a@github.com>
Message-ID: <iIzts4EuH4WNoOfQ9tYHbfqM4GWYCp9CdY95up8L32k=.907c963d-d92b-4aad-8a05-c78e9574659e@github.com>

On Fri, 27 Jun 2025 14:55:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/AltServicesRegistry.java line 186:
> 
>> 184:             return new Origin(scheme, originHost, addr.getPort());
>> 185:         }
>> 186:     }
> 
> I don't think it's a good idea to rely on `InetSocketAddress::getHostString()` as this can change depending on how the `InetSocketAddress` was constructed and whether `getHost()` has been called. 
> I believe it would be more reliable to add a new `URI origin` parameter to the `HttpConnection` constructor. We could build that origin from the request URI for which the connection was created. Probably `origin` should be `null` for `PlainProxyConnection`.

I've created https://bugs.openjdk.org/browse/JDK-8361060 to track this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174603879

From djelinski at openjdk.org  Mon Jun 30 09:37:58 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 30 Jun 2025 09:37:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:

> 122:     // exchange so that it can be aborted/timed out mid setup.
> 123:     final class ConnectionAborter {
> 124:         // In case of HTTP/3 direct connection we may have

"direct" is usually used to refer to connections that don't use a proxy; since H3 connections never use a proxy, can we drop the "direct" here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174648431

From dfuchs at openjdk.org  Mon Jun 30 09:48:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 09:48:59 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
 <gJjX2SWnVaY5_Iu8xzVmwlIdgYS8PgPYVHEvOaz00KY=.53ed95dc-6560-48da-8db2-49823788a63c@github.com>
Message-ID: <_KViTKZGBXQP1jf-JCdme4Wwzhc1VxUbIgeIaqCuA3E=.b36c2681-216d-4377-9492-9164eef40b51@github.com>

On Mon, 30 Jun 2025 09:34:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
>> 
>>  - merge latest changes from master branch
>>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>>  - retry the ResetControlStream test as needed
>>  - http3: fix pending connection and reconnection on stream limit reached logic
>>  - http3: pending acknowledgement should be registered before actually sending the packet
>>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>>  - http3: improve exceptions in Http3ServerExchange.java
>>  - http3: fix exception handling in CancelRequestTest.java
>>  - http3: review feedback - revert HPACK.java
>>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 124:
> 
>> 122:     // exchange so that it can be aborted/timed out mid setup.
>> 123:     final class ConnectionAborter {
>> 124:         // In case of HTTP/3 direct connection we may have
> 
> "direct" is usually used to refer to connections that don't use a proxy; since H3 connections never use a proxy, can we drop the "direct" here?

Good point. I will rephrase. We should be speaking of HTTP/3 requests (and not connection) here anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2174668926

From dfuchs at openjdk.org  Mon Jun 30 09:48:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 09:48:58 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v9]
In-Reply-To: <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <kndznJZZH6s5fbZh3SdLr99uyypWihLc5VTVgvYJ-4o=.55af7211-1f2e-45a4-ab2e-33bfa87565d9@github.com>
Message-ID: <kTIIcfqilyJuMUP65znNS6M7QoUQGpws8bXRmcbC0hQ=.a7fa725f-be22-41c1-b2b3-378ad0695ea9@github.com>

On Thu, 26 Jun 2025 16:36:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 525 commits:
> 
>  - merge latest changes from master branch
>  - http3: run H3StreamLimitReachedTest.java with -Djdk.httpclient.http3.maxStreamLimitTimeout=0 too
>  - retry the ResetControlStream test as needed
>  - http3: fix pending connection and reconnection on stream limit reached logic
>  - http3: pending acknowledgement should be registered before actually sending the packet
>  - http3: fix race with ping requests in PacketSpaceManager.java causing intermittent failures in H3ErrorHandlingTest.java
>  - http3: improve exceptions in Http3ServerExchange.java
>  - http3: fix exception handling in CancelRequestTest.java
>  - http3: review feedback - revert HPACK.java
>  - Implement X509TrustManagerImpl#checkClientTrusted for QUIC
>  - ... and 515 more: https://git.openjdk.org/jdk/compare/5a1301df...0229c215

src/java.net.http/share/classes/jdk/internal/net/http/AltSvcProcessor.java line 360:

> 358:             return new ParsedHeaderValue(altValue, alpnName, hostPort.host(), hostPort.port(), Map.of());
> 359:         }
> 360:         // parse the semi-colon delimited parameters out of the rest of the remaining string

Suggestion:

        // parse the semicolon delimited parameters out of the rest of the remaining string

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 85:

> 83: 
> 84:     // This will be set to true only when it is guaranteed that the server hasn't processed
> 85:     // the request. Typically this happens when the server explicitly states (through a GOAWAY frame

Suggestion:

    // the request. Typically, this happens when the server explicitly states (through a GOAWAY frame

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172279904
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2172285806

From jpai at openjdk.org  Mon Jun 30 11:12:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 11:12:56 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed
Message-ID: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>

Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.

This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.

No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

-------------

Commit messages:
 - 8361060: Keep track of the origin server against which a jdk.internal.net.http.HttpConnection was constructed

Changes: https://git.openjdk.org/jdk/pull/26041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26041&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361060
  Stats: 153 lines in 9 files changed: 131 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/26041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26041/head:pull/26041

PR: https://git.openjdk.org/jdk/pull/26041

From dfuchs at openjdk.org  Mon Jun 30 11:28:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 11:28:40 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed
In-Reply-To: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
Message-ID: <EPud-Vpxr0h-gg2VJ3y16hapXW-qMOHUDvySPMn0BXI=.11c04f19-b460-44ab-ac89-85edd2e34ef8@github.com>

On Mon, 30 Jun 2025 11:07:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
> 
> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

src/java.net.http/share/classes/jdk/internal/net/http/AsyncSSLConnection.java line 50:

> 48:                        String[] alpn,
> 49:                        String label) {
> 50:         super(originServer, addr, client, Utils.getServerName(addr), addr.getPort(), alpn, label);

Do we still need Utils.getServerName(addr), addr.getPort(), now that we have originServer? Or in other words - should we base these calls on the `addr` parameter or on the `originServer` parameters?

src/java.net.http/share/classes/jdk/internal/net/http/AsyncSSLTunnelConnection.java line 54:

> 52:                              String label)
> 53:     {
> 54:         super(originServer, addr, client, Utils.getServerName(addr), addr.getPort(), alpn, label);

Same question

src/java.net.http/share/classes/jdk/internal/net/http/Origin.java line 94:

> 92:         return host + ":" + port;
> 93:     }
> 94: }

Missing newline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2174834618
PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2174835728
PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2174839334

From dfuchs at openjdk.org  Mon Jun 30 11:31:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 11:31:37 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed
In-Reply-To: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
Message-ID: <bxmeHoK2_2Sip7WHMZ_qg793yR5Y-iYpUaZ4rI5_A9w=.fee28f07-7b10-4e5b-969c-ddd1b06838b7@github.com>

On Mon, 30 Jun 2025 11:07:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
> 
> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

src/java.net.http/share/classes/jdk/internal/net/http/Origin.java line 48:

> 46:             throw new IllegalArgumentException("Invalid port");
> 47:         }
> 48:     }

Should we enforce lower case for scheme and host in this constructor?
For instance - convert to lower case if needed in `from(URI)` and throw/assert here if not lower case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2174852642

From jpai at openjdk.org  Mon Jun 30 15:23:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 15:23:22 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v2]
In-Reply-To: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
Message-ID: <5A_SpOuvlXtTWrMOvuCA48FSlJ0j8mwUZFtF4CYogaQ=.1152a6c6-3a7f-47aa-b09c-c33a0c8dc53b@github.com>

> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
> 
> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:

 - SNI server names can now be derived from the Origin instance
 - strip the square brackets from URI's host when constructing an Origin
 - support only lower case http and https literals for scheme in Origin
 - add new line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26041/files
  - new: https://git.openjdk.org/jdk/pull/26041/files/7b34255e..c8825e0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26041&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26041&range=00-01

  Stats: 127 lines in 5 files changed: 50 ins; 64 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26041/head:pull/26041

PR: https://git.openjdk.org/jdk/pull/26041

From jpai at openjdk.org  Mon Jun 30 15:23:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 15:23:22 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v2]
In-Reply-To: <bxmeHoK2_2Sip7WHMZ_qg793yR5Y-iYpUaZ4rI5_A9w=.fee28f07-7b10-4e5b-969c-ddd1b06838b7@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <bxmeHoK2_2Sip7WHMZ_qg793yR5Y-iYpUaZ4rI5_A9w=.fee28f07-7b10-4e5b-969c-ddd1b06838b7@github.com>
Message-ID: <6GVB3XyRuX88JZav3GczRcFQQN6ZC3yz6dwFQ8vYytI=.bb9e1661-21bc-471d-a563-29fd24f9a0d5@github.com>

On Mon, 30 Jun 2025 11:28:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - SNI server names can now be derived from the Origin instance
>>  - strip the square brackets from URI's host when constructing an Origin
>>  - support only lower case http and https literals for scheme in Origin
>>  - add new line
>
> src/java.net.http/share/classes/jdk/internal/net/http/Origin.java line 48:
> 
>> 46:             throw new IllegalArgumentException("Invalid port");
>> 47:         }
>> 48:     }
> 
> Should we enforce lower case for scheme and host in this constructor?
> For instance - convert to lower case if needed in `from(URI)` and throw/assert here if not lower case?

We only support `http` and `https`. So I think it makes sense to convert it to lower case and expect the scheme to be either of these. I've updated the PR accordingly.

> src/java.net.http/share/classes/jdk/internal/net/http/Origin.java line 94:
> 
>> 92:         return host + ":" + port;
>> 93:     }
>> 94: }
> 
> Missing newline.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2175338532
PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2175335449

From jpai at openjdk.org  Mon Jun 30 15:28:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 30 Jun 2025 15:28:40 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v2]
In-Reply-To: <EPud-Vpxr0h-gg2VJ3y16hapXW-qMOHUDvySPMn0BXI=.11c04f19-b460-44ab-ac89-85edd2e34ef8@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <EPud-Vpxr0h-gg2VJ3y16hapXW-qMOHUDvySPMn0BXI=.11c04f19-b460-44ab-ac89-85edd2e34ef8@github.com>
Message-ID: <M7PNZ34U-4gILukv3GYgA06qptxaxpnpt6Kk7bSFXd8=.5fb3be81-adc8-4415-9a80-a3ccef52b749@github.com>

On Mon, 30 Jun 2025 11:18:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - SNI server names can now be derived from the Origin instance
>>  - strip the square brackets from URI's host when constructing an Origin
>>  - support only lower case http and https literals for scheme in Origin
>>  - add new line
>
> src/java.net.http/share/classes/jdk/internal/net/http/AsyncSSLConnection.java line 50:
> 
>> 48:                        String[] alpn,
>> 49:                        String label) {
>> 50:         super(originServer, addr, client, Utils.getServerName(addr), addr.getPort(), alpn, label);
> 
> Do we still need Utils.getServerName(addr), addr.getPort(), now that we have originServer? Or in other words - should we base these calls on the `addr` parameter or on the `originServer` parameters?

I had a look at it and you are right - with the introduction of this `Origin` construct, it should now be possible (and in fact prefered) to use it for constructing the SNI names. I updated this code to use the `Origin` instance. 

While doing that, the change caused a test failure which exposed one detail that I hadn't considered. `java.net.URI.getHost()` is specified to return a IPv6 address enclosed in square brackets. The `Origin` class hadn't considered that previously. It's now been updated to strip the square brackets when constructing the host value. This will allow the `Origin.host()` to be used in places where it was/is being used as a host that might be returned from a `InetAddress`. Local testing with this change now passes all the tests. I'll now trigger tier testing in our CI.

> src/java.net.http/share/classes/jdk/internal/net/http/AsyncSSLTunnelConnection.java line 54:
> 
>> 52:                              String label)
>> 53:     {
>> 54:         super(originServer, addr, client, Utils.getServerName(addr), addr.getPort(), alpn, label);
> 
> Same question

Updated to use the `Origin` instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2175349780
PR Review Comment: https://git.openjdk.org/jdk/pull/26041#discussion_r2175351647

From dfuchs at openjdk.org  Mon Jun 30 15:43:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 30 Jun 2025 15:43:39 GMT
Subject: RFR: 8361060: Keep track of the origin server against which a
 jdk.internal.net.http.HttpConnection was constructed [v2]
In-Reply-To: <5A_SpOuvlXtTWrMOvuCA48FSlJ0j8mwUZFtF4CYogaQ=.1152a6c6-3a7f-47aa-b09c-c33a0c8dc53b@github.com>
References: <mgiNMCpCrwtfRcLvshItSAgIfOQvMANjk1LwZVi5u2Y=.8e68607a-c060-4fb4-b74d-f42b11a1380b@github.com>
 <5A_SpOuvlXtTWrMOvuCA48FSlJ0j8mwUZFtF4CYogaQ=.1152a6c6-3a7f-47aa-b09c-c33a0c8dc53b@github.com>
Message-ID: <S4HMmrGf5u7Q-oZHDCihlN5Acu3ws_NAbfL4kA71zWE=.f3d4992d-db58-4783-8d9e-cd735a07b44e@github.com>

On Mon, 30 Jun 2025 15:23:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which updates the `jdk.internal.net.http.HttpConnection` to keep track of the origin server for which the `HttpConnection` was constructed? This addresses https://bugs.openjdk.org/browse/JDK-8361060.
>> 
>> This is an internal implementation change which will allow other parts of the JDK's HttpClient implementation to use the origin server information. An example of such usage is the alternate services that are going to be supported in the JDK's HttpClient upcoming implementation for HTTP/3.
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - SNI server names can now be derived from the Origin instance
>  - strip the square brackets from URI's host when constructing an Origin
>  - support only lower case http and https literals for scheme in Origin
>  - add new line

Looks good. I wonder if we should lower case the host returned by getHost() too (when not a literal address).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26041#pullrequestreview-2971761888