From aoqi at openjdk.java.net  Fri Oct  1 03:26:29 2021
From: aoqi at openjdk.java.net (Ao Qi)
Date: Fri, 1 Oct 2021 03:26:29 GMT
Subject: RFR: 8274561: sun/net/ftp/TestFtpTimeValue.java timed out on slow
 machines
In-Reply-To: <mOmw090uP49OO3P43f3TFATwmEQItme3Q1fWV8yAbP4=.2037c674-e414-4d3b-ba8d-f64dcea29ec1@github.com>
References: <FepxkAxyQ8j2mwpRA2MAlnJ6xzoLy38Pp_ig2nj9MW4=.b05b47a6-dc6b-4735-8ff9-be071c8d2070@github.com>
 <mOmw090uP49OO3P43f3TFATwmEQItme3Q1fWV8yAbP4=.2037c674-e414-4d3b-ba8d-f64dcea29ec1@github.com>
Message-ID: <EnLFxlvp5B5GmiLmQ63G-aj-jdlnDN2wLGACW4jx0XI=.1fe4299b-7b42-42c5-9f1e-0bb3d63b0d41@github.com>

On Thu, 30 Sep 2021 11:37:41 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> When we do fastdebug testing with -Xcomp, sun/net/ftp/TestFtpTimeValue.java timed out on slow machines. The parameter of setSoTimeout in the test should be set larger.
>
> The copyright year?

Thanks, @DamonFool @dfuch !

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

PR: https://git.openjdk.java.net/jdk/pull/5774

From aoqi at openjdk.java.net  Fri Oct  1 08:55:42 2021
From: aoqi at openjdk.java.net (Ao Qi)
Date: Fri, 1 Oct 2021 08:55:42 GMT
Subject: Integrated: 8274561: sun/net/ftp/TestFtpTimeValue.java timed out on
 slow machines
In-Reply-To: <FepxkAxyQ8j2mwpRA2MAlnJ6xzoLy38Pp_ig2nj9MW4=.b05b47a6-dc6b-4735-8ff9-be071c8d2070@github.com>
References: <FepxkAxyQ8j2mwpRA2MAlnJ6xzoLy38Pp_ig2nj9MW4=.b05b47a6-dc6b-4735-8ff9-be071c8d2070@github.com>
Message-ID: <uYphvfZIBaB5ht2Z8_W53Y3mi6TPG62ZFhOonqoz4jY=.c9fd76ea-7e80-4afa-b5cb-e68fb6171b5b@github.com>

On Thu, 30 Sep 2021 11:14:18 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> When we do fastdebug testing with -Xcomp, sun/net/ftp/TestFtpTimeValue.java timed out on slow machines. The parameter of setSoTimeout in the test should be set larger.

This pull request has now been integrated.

Changeset: b7b78ff1
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b7b78ff1f380d19214dbca48455772bc87cc137d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8274561: sun/net/ftp/TestFtpTimeValue.java timed out on slow machines

Reviewed-by: jiefu, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5774

From aefimov at openjdk.java.net  Fri Oct  1 09:51:32 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 1 Oct 2021 09:51:32 GMT
Subject: Integrated: 8274227: Remove "impl.prefix" jdk system property usage
 from InetAddress
In-Reply-To: <8OOtiAIfKosb9qGEs2Gn-xJwLuZ6HlfMlXBpj7TindY=.7ac23e30-e6a0-400a-86b0-6734d2faed85@github.com>
References: <8OOtiAIfKosb9qGEs2Gn-xJwLuZ6HlfMlXBpj7TindY=.7ac23e30-e6a0-400a-86b0-6734d2faed85@github.com>
Message-ID: <kyOcXS5BTnQqlB4Fb0hm0bJYZjTycBWPEPFWof648eE=.2afc8dcd-bc3d-4ee1-bf83-4456dae7c0b4@github.com>

On Wed, 29 Sep 2021 15:41:06 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> The following fix proposes to remove usages of `"impl.prefix"` JDK system property from the `java.net.InetAddress` class.
> This system property  is used to locate concrete implementations of the package private "java.net.InetAddressImpl" interface.
> 
> The list of changes:
>  -  `impl.prefix` usages are removed
>  -  `InetAddressImpl` made sealed interface by only allowing default implementations available in 'java.net' package: `Inet4AddressImpl` and `Inet6AddressImpl`.
> 
> tier1-tier3 tests show no failures  with this fix.

This pull request has now been integrated.

Changeset: cc14c6f0
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc14c6f076356731f78aea4e890027f4e2a91642
Stats:     53 lines in 4 files changed: 0 ins; 45 del; 8 mod

8274227: Remove "impl.prefix" jdk system property usage from InetAddress

Reviewed-by: alanb, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5755

From aefimov at openjdk.java.net  Tue Oct  5 12:10:28 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 5 Oct 2021 12:10:28 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution
 SPI
Message-ID: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>

This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.

The following API classes are added to `java.net.spi` package to facilitate this:
- `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
- `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
- `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
- `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  

More details in [JEP-418](https://openjdk.java.net/jeps/418).

Testing: new and existing `tier1:tier3` tests

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

Commit messages:
 - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI

Changes: https://git.openjdk.java.net/jdk/pull/5822/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244202
  Stats: 2779 lines in 50 files changed: 2524 ins; 134 del; 121 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From github.com+741251+turbanoff at openjdk.java.net  Tue Oct  5 13:40:12 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 5 Oct 2021 13:40:12 GMT
Subject: Integrated: 8274079: Cleanup unnecessary calls to
 Throwable.initCause() in java.base module
In-Reply-To: <yT2Auvz6F8-c5nHnfMb5rIfI7Q42sNyOHsyMFANd1jk=.5797dd93-89fd-4c53-9259-ec82fda1b387@github.com>
References: <yT2Auvz6F8-c5nHnfMb5rIfI7Q42sNyOHsyMFANd1jk=.5797dd93-89fd-4c53-9259-ec82fda1b387@github.com>
Message-ID: <dpR9pQwrUaQTc8PuRX7r1vXO7uf7xcE_rJp_0cL1Fmw=.20c9e2ac-ee63-4ec7-bcfa-17b78b0da439@github.com>

On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Pass "cause" exception as constructor parameter is shorter and easier to read.

This pull request has now been integrated.

Changeset: 1459180f
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1459180f352a5632c0afca2ed55abf31e4b0bfb0
Stats:     132 lines in 22 files changed: 0 ins; 77 del; 55 mod

8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

Reviewed-by: weijun

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

PR: https://git.openjdk.java.net/jdk/pull/5551

From darcy at openjdk.java.net  Tue Oct  5 19:03:16 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 5 Oct 2021 19:03:16 GMT
Subject: RFR: 8274793: Suppress warnings on non-serializable non-transient
 instance fields in sun.net
Message-ID: <xsyIFRJMKZWbPoR_nrPgQQMoEiUSUvvOHbyCNWcU0eA=.7cf6f87a-bafc-4da1-927a-8379998534e0@github.com>

Augmentations to javac's Xlint:serial checking are out for review (#5709) and the sun.net classes in this PR would need some changes to pass under the expanded checks.

The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

The changes in the PR are consistent with similar changes made in JDK libraries under the umbrella issue JDK-8231641.

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

Commit messages:
 - 8274793: Suppress warnings on non-serializable non-transient instance fields in sun.net

Changes: https://git.openjdk.java.net/jdk/pull/5826/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5826&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274793
  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5826.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5826/head:pull/5826

PR: https://git.openjdk.java.net/jdk/pull/5826

From alanb at openjdk.java.net  Tue Oct  5 19:07:16 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 5 Oct 2021 19:07:16 GMT
Subject: RFR: 8274793: Suppress warnings on non-serializable non-transient
 instance fields in sun.net
In-Reply-To: <xsyIFRJMKZWbPoR_nrPgQQMoEiUSUvvOHbyCNWcU0eA=.7cf6f87a-bafc-4da1-927a-8379998534e0@github.com>
References: <xsyIFRJMKZWbPoR_nrPgQQMoEiUSUvvOHbyCNWcU0eA=.7cf6f87a-bafc-4da1-927a-8379998534e0@github.com>
Message-ID: <bNi21wEMrOywlyTLd914Ugz8jkqK2BSN7Occ7ET6rCk=.fe1d165c-e575-4be1-925c-b2b5d2b6b8e4@github.com>

On Tue, 5 Oct 2021 18:55:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and the sun.net classes in this PR would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> The changes in the PR are consistent with similar changes made in JDK libraries under the umbrella issue JDK-8231641.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5826

From darcy at openjdk.java.net  Tue Oct  5 19:14:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 5 Oct 2021 19:14:12 GMT
Subject: Integrated: 8274793: Suppress warnings on non-serializable
 non-transient instance fields in sun.net
In-Reply-To: <xsyIFRJMKZWbPoR_nrPgQQMoEiUSUvvOHbyCNWcU0eA=.7cf6f87a-bafc-4da1-927a-8379998534e0@github.com>
References: <xsyIFRJMKZWbPoR_nrPgQQMoEiUSUvvOHbyCNWcU0eA=.7cf6f87a-bafc-4da1-927a-8379998534e0@github.com>
Message-ID: <uhiXrRb7o1umCFYATlrapETsfMce34ozS49V_0UDYWU=.792a4785-3f61-48c6-8220-7fcfbb34a7d9@github.com>

On Tue, 5 Oct 2021 18:55:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Augmentations to javac's Xlint:serial checking are out for review (#5709) and the sun.net classes in this PR would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> The changes in the PR are consistent with similar changes made in JDK libraries under the umbrella issue JDK-8231641.

This pull request has now been integrated.

Changeset: d34ec6cc
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d34ec6ccfc27d9401acce0e03595b910764fbfaf
Stats:     3 lines in 2 files changed: 3 ins; 0 del; 0 mod

8274793: Suppress warnings on non-serializable non-transient instance fields in sun.net

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/5826

From Elliot.Barlas at logmein.com  Tue Oct  5 22:05:06 2021
From: Elliot.Barlas at logmein.com (Elliot Barlas)
Date: Tue, 5 Oct 2021 22:05:06 +0000
Subject: HttpClient Send Method Guaranteed Completion
Message-ID: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>

Hello net-dev!

I'm emailing about a surprising observation in the HttpClient send method related to guaranteed completion.

Despite explicit timeout configurations, a call to send can block indefinitely. The stacktrace below was obtained from a thread dump on a running OpenJDK 16.0.2 JVM. The thread was stuck in that state for over a week. An application restart was required to recover. The related Java source code is also included below.

My sense is that this is due to a missed notification from the async I/O subsystem. Unfortunately, I'm not an expert on HttpClient internals, and the asynchronous nature of the code makes it challenging to debug.

Is this the intended behavior? That is, are there scenarios in which send should never return? Did I miss a socket timeout option?

-----

HttpClient httpClient = HttpClient.newBuilder()
        .version(HttpClient.Version.HTTP_1_1)
        .connectTimeout(Duration.ofSeconds(5))
        .build();
...
HttpRequest request = HttpRequest.newBuilder()
        .timeout(Duration.ofSeconds(5))
        .uri(URI.create("http://" + ip + ":" + port + "/frontend"))
        .build();
...
String html = httpClient.send(request, HttpResponse.BodyHandlers.ofString()).body();

-----

"pool-1-thread-70" #164 prio=5 os_prio=0 cpu=100038.29ms elapsed=1891832.58s tid=0x00007fe0211d4050 nid=0x29e waiting on condition  [0x00007fdf025ac000]
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(java.base at 16.0.2/Native Method)
        - parking to wait for  <0x00000000e7fc9be0> (a java.util.concurrent.CompletableFuture$Signaller)
        at java.util.concurrent.locks.LockSupport.park(java.base at 16.0.2/LockSupport.java:211)
        at java.util.concurrent.CompletableFuture$Signaller.block(java.base at 16.0.2/CompletableFuture.java:1860)
        at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 16.0.2/ForkJoinPool.java:3137)
        at java.util.concurrent.CompletableFuture.waitingGet(java.base at 16.0.2/CompletableFuture.java:1894)
        at java.util.concurrent.CompletableFuture.get(java.base at 16.0.2/CompletableFuture.java:2068)
        at jdk.internal.net.http.HttpClientImpl.send(java.net.http at 16.0.2/HttpClientImpl.java:535)
        at jdk.internal.net.http.HttpClientFacade.send(java.net.http at 16.0.2/HttpClientFacade.java:119)
        at com.logmein.haproxy.ProxyFrontendConnectionCounter.countCurrentConnections(ProxyFrontendConnectionCounter.java:89)
        at com.logmein.haproxy.ProxyFrontendConnectionCounter.doRun(ProxyFrontendConnectionCounter.java:74)
        at com.logmein.haproxy.ProxyFrontendConnectionCounter.run(ProxyFrontendConnectionCounter.java:59)
        at com.logmein.haproxy.ProxyFrontendConnectionCounter$$Lambda$712/0x00000008010a0a88.run(Unknown Source)
        at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 16.0.2/Executors.java:515)
        at java.util.concurrent.FutureTask.runAndReset(java.base at 16.0.2/FutureTask.java:305)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 16.0.2/ScheduledThreadPoolExecutor.java:305)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 16.0.2/ThreadPoolExecutor.java:1130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 16.0.2/ThreadPoolExecutor.java:630)
        at java.lang.Thread.run(java.base at 16.0.2/Thread.java:831)


Elliot Barlas
elliot.barlas at logmein.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211005/4ec6237e/attachment-0001.htm>

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 07:12:20 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 07:12:20 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
Message-ID: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>

8274809: Update java.base classes to use try-with-resources

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

Commit messages:
 - [PATCH] Use try-with-resources to close FileInputStream in java.base

Changes: https://git.openjdk.java.net/jdk/pull/5818/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274809
  Stats: 54 lines in 7 files changed: 2 ins; 40 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5818/head:pull/5818

PR: https://git.openjdk.java.net/jdk/pull/5818

From daniel.fuchs at oracle.com  Wed Oct  6 09:42:13 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 6 Oct 2021 10:42:13 +0100
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
Message-ID: <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>

Hi Eliot,

Unless the server keeps the connection open, and fails to send all the
body bytes it has promised to send, the send operation should eventually
terminate. The behavior you describe looks indeed like a bug.

Could you please log a ticket with:
https://bugreport.java.com/bugreport/

That said - there is very little information here to work with.
It would be helpful to understand with which version of the protocol
this happened: HTTP or HTTPS? Version 1.1 or Version 2? Was it
with an upgrade request (h2c)?

If you manage to reproduce, it would be helpful if HTTP traces
could be enabled - I'd suggest:
`-Djdk.httpclient.HttpClient.log=headers,requests,errors`
(see https://docs.oracle.com/en/java/javase/17/core/java-networking.html)

Another issue here is that the request timeout set through
`HttpRequestBuilder::timeout` only runs until the response
headers are received. The reception of the body bytes is not
covered by this timeout. This is not well documented, and
we should probably do a better job there.

We have an enhancement request related to this:
https://bugs.openjdk.java.net/browse/JDK-8258397

However - setting up a global timeout for the request
is already possible:

If you wish to set a timeout for the reception of the body
bytes you can do so by making use of the timeout facility
provided by CompletableFuture:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html#get(long,java.util.concurrent.TimeUnit)

Instead of:

```
   String html = httpClient.send(request,
       HttpResponse.BodyHandlers.ofString()).body();
```

Use:

```
   long timeout = 5000; // ms
   String html;
   CompletableFuture<HttpResponse<String>> cf;
   try {
       cf = httpClient.sendAsync(request,
           HttpResponse.BodyHandlers.ofString());
       html = cf.get(timeout, TimedUnit.MILLISECONDS)
                .body();
   } catch (TimeoutException x) {
       // timeout: cancel request to free up
       //   any related resources
       cf.cancel();
   } catch (CancellationException x) {
       // cancelled
   } catch (InterruptedException x) {
       // interrupted
   } catch (ExecutionException x) {
       // IO etc..
       // unwrap to get exception and rethrow...
   }
```

This offers the possibility to set up a global timeout
You can also cancel the request asynchronously at any
time by calling cf.cancel() (since Java 15 IIRC).

best regards,

-- daniel


On 05/10/2021 23:05, Elliot Barlas wrote:
> Hello net-dev!
> 
> I'm emailing about a surprising observation in the HttpClient send 
> method related to guaranteed completion.
> 
> Despite explicit timeout configurations, a call to send can block 
> indefinitely. The stacktrace below was obtained from a thread dump on a 
> running OpenJDK 16.0.2 JVM. The thread was stuck in that state for over 
> a week. An application restart was required to recover. The related Java 
> source code is also included below.
> 
> My sense is that this is due to a missed notification from the async I/O 
> subsystem. Unfortunately, I'm not an expert on HttpClient internals, and 
> the asynchronous nature of the code makes it challenging to debug.
> 
> Is this the intended behavior? That is, are there scenarios in which 
> send should never return? Did I miss a socket timeout option?
> 
> -----
> 
> HttpClient httpClient = HttpClient.newBuilder()
>  ? ? ? ? .version(HttpClient.Version.HTTP_1_1)
>  ? ? ? ? .connectTimeout(Duration.ofSeconds(5))
>  ? ? ? ? .build();
> ...
> HttpRequest request = HttpRequest.newBuilder()
>  ? ? ? ? .timeout(Duration.ofSeconds(5))
>  ? ? ? ? .uri(URI.create("http://" + ip + ":" + port + "/frontend"))
>  ? ? ? ? .build();
> ...
> String html = httpClient.send(request, 
> HttpResponse.BodyHandlers.ofString()).body();
> 
> -----
> 
> "pool-1-thread-70" #164 prio=5 os_prio=0 cpu=100038.29ms 
> elapsed=1891832.58s tid=0x00007fe0211d4050 nid=0x29e waiting on 
> condition ?[0x00007fdf025ac000]
>  ? ?java.lang.Thread.State: WAITING (parking)
>  ? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 16.0.2/Native Method)
>  ? ? ? ? - parking to wait for ?<0x00000000e7fc9be0> (a 
> java.util.concurrent.CompletableFuture$Signaller)
>  ? ? ? ? at 
> java.util.concurrent.locks.LockSupport.park(java.base at 16.0.2/LockSupport.java:211)
>  ? ? ? ? at 
> java.util.concurrent.CompletableFuture$Signaller.block(java.base at 16.0.2/CompletableFuture.java:1860)
>  ? ? ? ? at 
> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 16.0.2/ForkJoinPool.java:3137)
>  ? ? ? ? at 
> java.util.concurrent.CompletableFuture.waitingGet(java.base at 16.0.2/CompletableFuture.java:1894)
>  ? ? ? ? at 
> java.util.concurrent.CompletableFuture.get(java.base at 16.0.2/CompletableFuture.java:2068)
>  ? ? ? ? at 
> jdk.internal.net.http.HttpClientImpl.send(java.net.http at 16.0.2/HttpClientImpl.java:535)
>  ? ? ? ? at 
> jdk.internal.net.http.HttpClientFacade.send(java.net.http at 16.0.2/HttpClientFacade.java:119)
>  ? ? ? ? at 
> com.logmein.haproxy.ProxyFrontendConnectionCounter.countCurrentConnections(ProxyFrontendConnectionCounter.java:89)
>  ? ? ? ? at 
> com.logmein.haproxy.ProxyFrontendConnectionCounter.doRun(ProxyFrontendConnectionCounter.java:74)
>  ? ? ? ? at 
> com.logmein.haproxy.ProxyFrontendConnectionCounter.run(ProxyFrontendConnectionCounter.java:59)
>  ? ? ? ? at 
> com.logmein.haproxy.ProxyFrontendConnectionCounter$$Lambda$712/0x00000008010a0a88.run(Unknown 
> Source)
>  ? ? ? ? at 
> java.util.concurrent.Executors$RunnableAdapter.call(java.base at 16.0.2/Executors.java:515)
>  ? ? ? ? at 
> java.util.concurrent.FutureTask.runAndReset(java.base at 16.0.2/FutureTask.java:305)
>  ? ? ? ? at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 16.0.2/ScheduledThreadPoolExecutor.java:305)
>  ? ? ? ? at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 16.0.2/ThreadPoolExecutor.java:1130)
>  ? ? ? ? at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 16.0.2/ThreadPoolExecutor.java:630)
>  ? ? ? ? at java.lang.Thread.run(java.base at 16.0.2/Thread.java:831)
> 
> 
> Elliot Barlas
> elliot.barlas at logmein.com


From myano at openjdk.java.net  Wed Oct  6 11:27:14 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 6 Oct 2021 11:27:14 GMT
Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if
 some process is holding the file
In-Reply-To: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
References: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
Message-ID: <zeDqyaNaUREBPXFAFp1WSgK2KwQEjlUeygaO-ipOVkE=.600bba63-bfba-4747-94b7-e0d815bcde32@github.com>

On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8233674 bug fixes?
> This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried.

I inquired of the Microsoft Technical Support about this problem. They said that using a simple retry mechanism is the effective workaround for this problem as in the article. But, they are not sure which is wrong the application or the virus checker because it depends on the situation. Which method do you think is better, to fix the JDK or to change the configuration of the virus checker?

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

PR: https://git.openjdk.java.net/jdk/pull/5460

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 12:29:23 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 12:29:23 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
Message-ID: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>

Redundant castings make code harder to read.
Found them by IntelliJ IDEA.
I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

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

Commit messages:
 - [PATCH] Remove unnecessary castings in java.base
 - [PATCH] Remove unnecessary castings in java.base

Changes: https://git.openjdk.java.net/jdk/pull/5454/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5454&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274835
  Stats: 38 lines in 15 files changed: 1 ins; 4 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5454.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5454/head:pull/5454

PR: https://git.openjdk.java.net/jdk/pull/5454

From mullan at openjdk.java.net  Wed Oct  6 13:05:07 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 6 Oct 2021 13:05:07 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <2g6lp6Qoc6CkGSZxYcxU6J9lyufzUB_nM-JtXOt7Yng=.66528e37-4512-47d6-9818-7acc6a99a42d@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

The security related files look fine.

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

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5454

From mullan at openjdk.java.net  Wed Oct  6 13:08:11 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 6 Oct 2021 13:08:11 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <UgKQoKJ7M34sdcOjGUoMS7m6VIqxLqm786L-NEHVbuo=.08be5cf9-d796-43f2-b113-faf4a09c054d@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8274809: Update java.base classes to use try-with-resources

The security related files look fine.

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

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5818

From wetmore at openjdk.java.net  Wed Oct  6 16:05:13 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 16:05:13 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8274809: Update java.base classes to use try-with-resources

Reviewed the crypto/security files.

src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 115:

> 113: 
> 114:         // Send the request
> 115:         try (DataOutputStream output = new DataOutputStream(connection.getOutputStream())) {

Please break this up so it doesn't have lines > 80.  e.g.

        try (DataOutputStream output =
                new DataOutputStream(connection.getOutputStream())) {

This makes side-by-side viewing very hard without a wider monitor.  

Thank you.

src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 127:

> 125:         // Receive the reply
> 126:         byte[] replyBuffer = null;
> 127:         try (BufferedInputStream input = new BufferedInputStream(connection.getInputStream())) {

Same comment as above.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5818

From wetmore at openjdk.java.net  Wed Oct  6 16:14:09 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 16:14:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>

On Tue, 5 Oct 2021 09:36:23 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8274809: Update java.base classes to use try-with-resources

I checked the rest.  The one BufferedInputStream change is puzzling.  Please explain or address.

Files like HttpTimestamper need the copyright dates updated to 2021.

src/java.base/share/classes/sun/net/NetProperties.java line 71:

> 69:             f = new File(f, "net.properties");
> 70:             fname = f.getCanonicalPath();
> 71:             try (FileInputStream fis = new FileInputStream(fname)) {

Why did the BufferedInputStream get pulled out here?

src/java.base/share/classes/sun/security/util/PolicyUtil.java line 156:

> 154:                 }
> 155: 
> 156:                 try (InputStream inStream = new BufferedInputStream(getInputStream(keyStoreUrl))) {

Same comment as above.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5818

From naoto at openjdk.java.net  Wed Oct  6 16:28:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 16:28:06 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <bjZ-M-6Z6gJtz-cqjVE5v8-6mkv_3XnoLeU8vuq3U0E=.61ef8c3b-31e6-4ad2-872c-7934502fa8a7@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Calendar-related changes look good to me.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5454

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 16:29:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 16:29:08 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
Message-ID: <j2azoLMg49XzvhEi1EFfnNsuz2hKET6ONLfeGdsmPxg=.dd2a061f-d27d-4f03-a8d6-4037b0340666@github.com>

On Wed, 6 Oct 2021 16:04:54 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> src/java.base/share/classes/sun/net/NetProperties.java line 71:
> 
>> 69:             f = new File(f, "net.properties");
>> 70:             fname = f.getCanonicalPath();
>> 71:             try (FileInputStream fis = new FileInputStream(fname)) {
> 
> Why did the BufferedInputStream get pulled out here?

I decieded to remove it because `Properties.load` already buffers inputstream. So usage of BufferedInputStream seems redundant.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Properties.java#L471

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 16:29:09 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 16:29:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <j2azoLMg49XzvhEi1EFfnNsuz2hKET6ONLfeGdsmPxg=.dd2a061f-d27d-4f03-a8d6-4037b0340666@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
 <j2azoLMg49XzvhEi1EFfnNsuz2hKET6ONLfeGdsmPxg=.dd2a061f-d27d-4f03-a8d6-4037b0340666@github.com>
Message-ID: <aMlE4gAtTbyeoi6GXIEn9eeET1dkLFdZOJcqSOqCylY=.b218b6f9-48d2-4de2-9981-0ec2d3fb4a2b@github.com>

On Wed, 6 Oct 2021 16:24:03 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/NetProperties.java line 71:
>> 
>>> 69:             f = new File(f, "net.properties");
>>> 70:             fname = f.getCanonicalPath();
>>> 71:             try (FileInputStream fis = new FileInputStream(fname)) {
>> 
>> Why did the BufferedInputStream get pulled out here?
>
> I decieded to remove it because `Properties.load` already buffers inputstream. So usage of BufferedInputStream seems redundant.
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Properties.java#L471

I will revert back to `BufferedInputStream` and will create a separate PR to cleanup redundant buffering around Properties.load calls.

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From prappo at openjdk.java.net  Wed Oct  6 16:29:09 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 6 Oct 2021 16:29:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
In-Reply-To: <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
Message-ID: <XMuOg0gXY_Zrqud8qSHFffGKuSbGJG2snnFhvI7A_TE=.f10f99d8-f43e-4d9d-8de6-b6b2079e3b60@github.com>

On Wed, 6 Oct 2021 16:00:41 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 127:
> 
>> 125:         // Receive the reply
>> 126:         byte[] replyBuffer = null;
>> 127:         try (BufferedInputStream input = new BufferedInputStream(connection.getInputStream())) {
> 
> Same comment as above.

In this and the immediately preceding case, it might be better to use `var`.

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From lancea at openjdk.java.net  Wed Oct  6 16:33:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 6 Oct 2021 16:33:09 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <izYxd9rrVsXAmp4ucJKzcuPcA9YMeQ8TcBQSARA-484=.fcfdb84d-518e-44b7-b878-d9a2aa7fe92e@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5454

From darcy at openjdk.java.net  Wed Oct  6 17:15:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 6 Oct 2021 17:15:08 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis.

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

PR: https://git.openjdk.java.net/jdk/pull/5454

From Elliot.Barlas at logmein.com  Wed Oct  6 17:22:01 2021
From: Elliot.Barlas at logmein.com (Elliot Barlas)
Date: Wed, 6 Oct 2021 17:22:01 +0000
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
 <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
Message-ID: <BYAPR15MB26473BF17C95BA4D4FD79225E8B09@BYAPR15MB2647.namprd15.prod.outlook.com>

Thanks for the reply, Daniel.

This was an HTTP 1.1 connection. The code snippet for building the URL and configuring the HttpClient was included in my previous email for reference.

I can't make any claims about what was happening with packet transmissions at the network level. It's entirely possible that the destination maintained the TCP connection over an extended period without fulfilling its obligation to send the body. But there must be a way to guarantee completion for such scenarios. This was the function of socket timeouts in the world of synchronous network APIs. In this new asynchronous world, it looks like that might have been forgotten.

The alternative timeout code you mentioned addresses the problem in a narrow sense, but it results in a resource leak. If the HTTP session is abandoned at the application level via CompletableFuture timed wait, there is still a footprint within HttpClient. Over time, socket handles, callback objects, and other resources can accumulate with no visibility to application code.

________________________________
From: Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Wednesday, October 6, 2021 2:42 AM
To: Elliot Barlas <Elliot.Barlas at logmein.com>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: Re: HttpClient Send Method Guaranteed Completion

Hi Eliot,

Unless the server keeps the connection open, and fails to send all the
body bytes it has promised to send, the send operation should eventually
terminate. The behavior you describe looks indeed like a bug.

Could you please log a ticket with:
https://urldefense.com/v3/__https://bugreport.java.com/bugreport/__;!!OA8L0MA-!sPeWGu915xnLugfAz60R8t6hJfzTFK_1ZMX7cI0b-SgYHEDvWjnOSVCVmjsgoCLBZNA$

That said - there is very little information here to work with.
It would be helpful to understand with which version of the protocol
this happened: HTTP or HTTPS? Version 1.1 or Version 2? Was it
with an upgrade request (h2c)?

If you manage to reproduce, it would be helpful if HTTP traces
could be enabled - I'd suggest:
`-Djdk.httpclient.HttpClient.log=headers,requests,errors`
(see https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/17/core/java-networking.html__;!!OA8L0MA-!sPeWGu915xnLugfAz60R8t6hJfzTFK_1ZMX7cI0b-SgYHEDvWjnOSVCVmjsgmoTmRXo$ )

Another issue here is that the request timeout set through
`HttpRequestBuilder::timeout` only runs until the response
headers are received. The reception of the body bytes is not
covered by this timeout. This is not well documented, and
we should probably do a better job there.

We have an enhancement request related to this:
https://urldefense.com/v3/__https://bugs.openjdk.java.net/browse/JDK-8258397__;!!OA8L0MA-!sPeWGu915xnLugfAz60R8t6hJfzTFK_1ZMX7cI0b-SgYHEDvWjnOSVCVmjsg46sP2Vg$

However - setting up a global timeout for the request
is already possible:

If you wish to set a timeout for the reception of the body
bytes you can do so by making use of the timeout facility
provided by CompletableFuture:
https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html*get(long,java.util.concurrent.TimeUnit)__;Iw!!OA8L0MA-!sPeWGu915xnLugfAz60R8t6hJfzTFK_1ZMX7cI0b-SgYHEDvWjnOSVCVmjsgABT3nlI$

Instead of:

```
   String html = httpClient.send(request,
       HttpResponse.BodyHandlers.ofString()).body();
```

Use:

```
   long timeout = 5000; // ms
   String html;
   CompletableFuture<HttpResponse<String>> cf;
   try {
       cf = httpClient.sendAsync(request,
           HttpResponse.BodyHandlers.ofString());
       html = cf.get(timeout, TimedUnit.MILLISECONDS)
                .body();
   } catch (TimeoutException x) {
       // timeout: cancel request to free up
       //   any related resources
       cf.cancel();
   } catch (CancellationException x) {
       // cancelled
   } catch (InterruptedException x) {
       // interrupted
   } catch (ExecutionException x) {
       // IO etc..
       // unwrap to get exception and rethrow...
   }
```

This offers the possibility to set up a global timeout
You can also cancel the request asynchronously at any
time by calling cf.cancel() (since Java 15 IIRC).

best regards,

-- daniel


On 05/10/2021 23:05, Elliot Barlas wrote:
> Hello net-dev!
>
> I'm emailing about a surprising observation in the HttpClient send
> method related to guaranteed completion.
>
> Despite explicit timeout configurations, a call to send can block
> indefinitely. The stacktrace below was obtained from a thread dump on a
> running OpenJDK 16.0.2 JVM. The thread was stuck in that state for over
> a week. An application restart was required to recover. The related Java
> source code is also included below.
>
> My sense is that this is due to a missed notification from the async I/O
> subsystem. Unfortunately, I'm not an expert on HttpClient internals, and
> the asynchronous nature of the code makes it challenging to debug.
>
> Is this the intended behavior? That is, are there scenarios in which
> send should never return? Did I miss a socket timeout option?
>
> -----
>
> HttpClient httpClient = HttpClient.newBuilder()
>          .version(HttpClient.Version.HTTP_1_1)
>          .connectTimeout(Duration.ofSeconds(5))
>          .build();
> ...
> HttpRequest request = HttpRequest.newBuilder()
>          .timeout(Duration.ofSeconds(5))
>          .uri(URI.create("http://" + ip + ":" + port + "/frontend"))
>          .build();
> ...
> String html = httpClient.send(request,
> HttpResponse.BodyHandlers.ofString()).body();
>
> -----
>
> "pool-1-thread-70" #164 prio=5 os_prio=0 cpu=100038.29ms
> elapsed=1891832.58s tid=0x00007fe0211d4050 nid=0x29e waiting on
> condition  [0x00007fdf025ac000]
>     java.lang.Thread.State: WAITING (parking)
>          at jdk.internal.misc.Unsafe.park(java.base at 16.0.2/Native Method)
>          - parking to wait for  <0x00000000e7fc9be0> (a
> java.util.concurrent.CompletableFuture$Signaller)
>          at
> java.util.concurrent.locks.LockSupport.park(java.base at 16.0.2/LockSupport.java:211)
>          at
> java.util.concurrent.CompletableFuture$Signaller.block(java.base at 16.0.2/CompletableFuture.java:1860)
>          at
> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 16.0.2/ForkJoinPool.java:3137)
>          at
> java.util.concurrent.CompletableFuture.waitingGet(java.base at 16.0.2/CompletableFuture.java:1894)
>          at
> java.util.concurrent.CompletableFuture.get(java.base at 16.0.2/CompletableFuture.java:2068)
>          at
> jdk.internal.net.http.HttpClientImpl.send(java.net.http at 16.0.2/HttpClientImpl.java:535)
>          at
> jdk.internal.net.http.HttpClientFacade.send(java.net.http at 16.0.2/HttpClientFacade.java:119)
>          at
> com.logmein.haproxy.ProxyFrontendConnectionCounter.countCurrentConnections(ProxyFrontendConnectionCounter.java:89)
>          at
> com.logmein.haproxy.ProxyFrontendConnectionCounter.doRun(ProxyFrontendConnectionCounter.java:74)
>          at
> com.logmein.haproxy.ProxyFrontendConnectionCounter.run(ProxyFrontendConnectionCounter.java:59)
>          at
> com.logmein.haproxy.ProxyFrontendConnectionCounter$$Lambda$712/0x00000008010a0a88.run(Unknown
> Source)
>          at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base at 16.0.2/Executors.java:515)
>          at
> java.util.concurrent.FutureTask.runAndReset(java.base at 16.0.2/FutureTask.java:305)
>          at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 16.0.2/ScheduledThreadPoolExecutor.java:305)
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 16.0.2/ThreadPoolExecutor.java:1130)
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 16.0.2/ThreadPoolExecutor.java:630)
>          at java.lang.Thread.run(java.base at 16.0.2/Thread.java:831)
>
>
> Elliot Barlas
> elliot.barlas at logmein.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211006/f514c014/attachment-0001.htm>

From dfuchs at openjdk.java.net  Wed Oct  6 18:04:06 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 6 Oct 2021 18:04:06 GMT
Subject: RFR: 8273910: Redundant condition and assignment in java.net.URI
In-Reply-To: <Naw1o2EW4fiL28UiHRsTUA0gOH2G5N_ZY5XeOm-9ObE=.dee1b0fd-b8b0-4635-8581-c1e8912a2667@github.com>
References: <Naw1o2EW4fiL28UiHRsTUA0gOH2G5N_ZY5XeOm-9ObE=.dee1b0fd-b8b0-4635-8581-c1e8912a2667@github.com>
Message-ID: <6OvtR-FNLv-V79q2lcZpuc4iXo1B5-gxChWen5gnfEo=.207034c9-5243-40c4-bd5d-ed864534d811@github.com>

On Thu, 19 Aug 2021 19:08:59 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 1. Assignment `ru.host = child.host;` is duplicated and hence redundant.
> 2. Condition `q > p` is always `true`, because it just bellow inverse check
> 
>                 if (q <= p)
>                     break;

I have sent this patch to our test system. I will come back with the results when they are available.

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

PR: https://git.openjdk.java.net/jdk/pull/5190

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:27:35 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:27:35 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v2]
In-Reply-To: <XMuOg0gXY_Zrqud8qSHFffGKuSbGJG2snnFhvI7A_TE=.f10f99d8-f43e-4d9d-8de6-b6b2079e3b60@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
 <XMuOg0gXY_Zrqud8qSHFffGKuSbGJG2snnFhvI7A_TE=.f10f99d8-f43e-4d9d-8de6-b6b2079e3b60@github.com>
Message-ID: <U5j_EMVmod4TeFOPUYJoM-i0f8xCc3TIt4YEVhlDqP4=.1dd8529c-a29d-46ad-93f2-951d501b7ce8@github.com>

On Wed, 6 Oct 2021 16:20:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 127:
>> 
>>> 125:         // Receive the reply
>>> 126:         byte[] replyBuffer = null;
>>> 127:         try (BufferedInputStream input = new BufferedInputStream(connection.getInputStream())) {
>> 
>> Same comment as above.
>
> In this and the immediately preceding case, it might be better to use `var`.

I like variant with `var` more. Updated

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:27:34 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:27:34 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v2]
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <kCR9NYb_cjq355Utk1hloVrmWB0HTTKyLJbjaYtaNGY=.3e54ac08-5fdc-4422-a95e-490ed596af5d@github.com>

> 8274809: Update java.base classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274809: Update java.base classes to use try-with-resources
  fix post-review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5818/files
  - new: https://git.openjdk.java.net/jdk/pull/5818/files/6d8ce900..78893df9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=00-01

  Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5818/head:pull/5818

PR: https://git.openjdk.java.net/jdk/pull/5818

From daniel.fuchs at oracle.com  Wed Oct  6 18:46:15 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 6 Oct 2021 19:46:15 +0100
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <BYAPR15MB26473BF17C95BA4D4FD79225E8B09@BYAPR15MB2647.namprd15.prod.outlook.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
 <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
 <BYAPR15MB26473BF17C95BA4D4FD79225E8B09@BYAPR15MB2647.namprd15.prod.outlook.com>
Message-ID: <14624a6a-c350-2462-bc07-daa1baf0e337@oracle.com>

Hi Eliot,

On 06/10/2021 18:22, Elliot Barlas wrote:
> Thanks for the reply, Daniel.
> 
> This was an HTTP 1.1 connection. The code snippet for building the URL 
> and configuring the HttpClient was included in my previous email for 
> reference.
> 
> I can't make any claims about what was happening with packet 
> transmissions at the network level. It's entirely possible that the 
> destination maintained the TCP connection over an extended period 
> without fulfilling its obligation to send the body. But there must be a 
> way to guarantee completion for such scenarios. This was the function of 
> socket timeouts in the world of synchronous network APIs. In this new 
> asynchronous world, it looks like that might have been forgotten.
> 
> The alternative timeout code you mentioned addresses the problem in a 
> narrow sense, but it results in a resource leak. If the HTTP session is 
> abandoned at the application level via?CompletableFuture timed wait, 
> there is still a footprint within HttpClient. Over time, socket handles, 
> callback objects, and other resources can accumulate with no visibility 
> to application code.

There should be no leak if you call CompletableFuture::cancel when 
catching the TimeoutException as shown in my suggestion, and provided
you're on a recent JDK (16+). That should take care of reclaiming
all the resources linked to the exchange.
(that was taken care of by https://bugs.openjdk.java.net/browse/JDK-8245462)

If we had to implement a global timeout that's how we would do
it internally.

best regards,

-- daniel



From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:47:26 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:47:26 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>

> 8274809: Update java.base classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274809: Update java.base classes to use try-with-resources
  update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5818/files
  - new: https://git.openjdk.java.net/jdk/pull/5818/files/78893df9..423c3069

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=01-02

  Stats: 5 lines in 4 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5818/head:pull/5818

PR: https://git.openjdk.java.net/jdk/pull/5818

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 18:47:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 18:47:27 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
Message-ID: <UUjftXz7iJaziZeMCKWfEuTHd1fx-yf6juWqnJcm_Uk=.c8f6a1c7-0368-42bc-8b65-2ad965fa60e4@github.com>

On Wed, 6 Oct 2021 16:11:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>Files like HttpTimestamper need the copyright dates updated to 2021.

Updated

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From daniel.fuchs at oracle.com  Wed Oct  6 19:08:38 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 6 Oct 2021 20:08:38 +0100
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
 <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
Message-ID: <a308074c-e00a-0ff8-ea52-df1da37c678b@oracle.com>

On 06/10/2021 10:42, Daniel Fuchs wrote:
>  ? } catch (TimeoutException x) {
>  ????? // timeout: cancel request to free up
>  ????? //?? any related resources
>  ????? cf.cancel();

Correction: that should be `cf.cancel(true)`

From wetmore at openjdk.java.net  Wed Oct  6 19:48:09 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 19:48:09 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
Message-ID: <vOTsKEjrvDfZ81YauUCn6-FM8yA6x-Wly9ucYRRsQS4=.f36e216e-fe56-49a4-b892-73d1e6b5ee76@github.com>

On Wed, 6 Oct 2021 18:47:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274809: Update java.base classes to use try-with-resources
>   update copyright year

Greater than 80 chars comment missing in latest changeset.

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From wetmore at openjdk.java.net  Wed Oct  6 19:48:10 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 19:48:10 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <KcG21Oq0uEV7w1JePghs-IzRIU0rsAs4_pGI85FfDyE=.110f8a90-2dad-4343-88cf-fe8c75cefcea@github.com>
Message-ID: <Xuaobz8vUg6qQCiTrqN45KysxBN3a2qTAoLfi11lylE=.8bdc7ee0-aa14-48a8-8154-b0c81a120d07@github.com>

On Wed, 6 Oct 2021 16:07:12 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274809: Update java.base classes to use try-with-resources
>>   update copyright year
>
> src/java.base/share/classes/sun/security/util/PolicyUtil.java line 156:
> 
>> 154:                 }
>> 155: 
>> 156:                 try (InputStream inStream = new BufferedInputStream(getInputStream(keyStoreUrl))) {
> 
> Same comment as above.

Looks like it's still > 80 chars

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From wetmore at openjdk.java.net  Wed Oct  6 19:56:08 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 6 Oct 2021 19:56:08 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v3]
In-Reply-To: <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <p4RmkWflTy0hyhddirGbpYAO2ayfwDKxwKiDSCkQW2Y=.1d71ebfb-dea3-401e-a04f-49fbda53a6b4@github.com>
Message-ID: <lYZpk_72o-DFp2R1PwL9ZvijUF_uRvdyDVIpukL5RUY=.38c59cb6-64bb-4fed-9799-604f1e8d50ec@github.com>

On Wed, 6 Oct 2021 18:47:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8274809: Update java.base classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274809: Update java.base classes to use try-with-resources
>   update copyright year

src/java.base/share/classes/sun/net/NetProperties.java line 72:

> 70:             fname = f.getCanonicalPath();
> 71:             try (FileInputStream in = new FileInputStream(fname)) {
> 72:                 BufferedInputStream bin = new BufferedInputStream(in);

Shouldn't this have a multiple resource block in the try-with block here:  

    try (FileInputStream in = new FileInputStream(fname);
            BufferedInputStream bin = new BufferedInputStream(in)) {
        props.land(bin);
    }

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From Elliot.Barlas at logmein.com  Wed Oct  6 20:06:59 2021
From: Elliot.Barlas at logmein.com (Elliot Barlas)
Date: Wed, 6 Oct 2021 20:06:59 +0000
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <a308074c-e00a-0ff8-ea52-df1da37c678b@oracle.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
 <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
 <a308074c-e00a-0ff8-ea52-df1da37c678b@oracle.com>
Message-ID: <BYAPR15MB26475394EC00CD0F48CE9D29E8B09@BYAPR15MB2647.namprd15.prod.outlook.com>

Thank you for pointing that out! That addresses my immediate concern. This ought to work just fine.
________________________________
From: Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Wednesday, October 6, 2021 12:08 PM
To: Elliot Barlas <Elliot.Barlas at logmein.com>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: Re: HttpClient Send Method Guaranteed Completion

On 06/10/2021 10:42, Daniel Fuchs wrote:
>    } catch (TimeoutException x) {
>        // timeout: cancel request to free up
>        //   any related resources
>        cf.cancel();

Correction: that should be `cf.cancel(true)`
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211006/2207ddec/attachment.htm>

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 20:37:29 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 20:37:29 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v4]
In-Reply-To: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
Message-ID: <FZuIidy72Sp0Bj9To9eH5dUGHDyF_kd20Dyqw-fPPAA=.61a14a85-d5ab-4268-97f3-3d6e511e5988@github.com>

> 8274809: Update java.base classes to use try-with-resources

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274809: Update java.base classes to use try-with-resources
  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5818/files
  - new: https://git.openjdk.java.net/jdk/pull/5818/files/423c3069..3b05ec49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5818&range=02-03

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5818/head:pull/5818

PR: https://git.openjdk.java.net/jdk/pull/5818

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 20:37:30 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 20:37:30 GMT
Subject: RFR: 8274809: Update java.base classes to use try-with-resources
 [v4]
In-Reply-To: <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
References: <NIhcEALtWMfPW2z9M3VQHhpg1OXK1nHocQ-mWpiuXdw=.ae6caa99-1bfd-44ff-9e94-6dbc1b4947e8@github.com>
 <8vS2rfHkUZ_KrdCq8XUiU37uhmbP2RyQYMCX_JGs__g=.f0249d06-12d7-45ce-8a66-552268e43d15@github.com>
Message-ID: <G11s28BssBpoI4hpV5H4jLErkk6yLbhh-USd3wcDJqg=.f9b097a0-0738-4a87-8881-787ab10239bf@github.com>

On Wed, 6 Oct 2021 16:00:26 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274809: Update java.base classes to use try-with-resources
>>   fix review comments
>
> src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line 115:
> 
>> 113: 
>> 114:         // Send the request
>> 115:         try (DataOutputStream output = new DataOutputStream(connection.getOutputStream())) {
> 
> Please break this up so it doesn't have lines > 80.  e.g.
> 
>         try (DataOutputStream output =
>                 new DataOutputStream(connection.getOutputStream())) {
> 
> This makes side-by-side viewing very hard without a wider monitor.  
> 
> Thank you.

Update.

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

PR: https://git.openjdk.java.net/jdk/pull/5818

From dfuchs at openjdk.java.net  Wed Oct  6 20:41:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 6 Oct 2021 20:41:07 GMT
Subject: RFR: 8273910: Redundant condition and assignment in java.net.URI
In-Reply-To: <Naw1o2EW4fiL28UiHRsTUA0gOH2G5N_ZY5XeOm-9ObE=.dee1b0fd-b8b0-4635-8581-c1e8912a2667@github.com>
References: <Naw1o2EW4fiL28UiHRsTUA0gOH2G5N_ZY5XeOm-9ObE=.dee1b0fd-b8b0-4635-8581-c1e8912a2667@github.com>
Message-ID: <Dxx27op8VnC3F0k0aGS8BrMwWwnbRte6YxM6SIncWeQ=.d58454b8-f71c-418b-9040-9eb95811af65@github.com>

On Thu, 19 Aug 2021 19:08:59 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 1. Assignment `ru.host = child.host;` is duplicated and hence redundant.
> 2. Condition `q > p` is always `true`, because it just bellow inverse check
> 
>                 if (q <= p)
>                     break;

The updated logic looks correct, and my tests (tier1,tier2,tier3) came back with no failure.
Reviewed.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5190

From bpb at openjdk.java.net  Wed Oct  6 21:08:12 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 6 Oct 2021 21:08:12 GMT
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <wee37TyGNDjU0xrCVV9iO2UWHgZtVwT22jL8ZQTTJpI=.7ecb2791-480e-4b2b-b155-c826bcd7d161@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

`java.io` change looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5454

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 07:35:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 07:35:21 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within
 java.base classes
Message-ID: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>

StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
1. Plain String concatenation should be preferred
2. StringBuilder is a direct replacement to StringBuffer which generally have better performance

In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

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

Commit messages:
 - [PATCH] Cleanup usages of StringBuffer in java.base module
 - [PATCH] Cleanup usages of StringBuffer in java.base module

Changes: https://git.openjdk.java.net/jdk/pull/5432/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274879
  Stats: 32 lines in 12 files changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5432.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5432/head:pull/5432

PR: https://git.openjdk.java.net/jdk/pull/5432

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 10:26:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 10:26:28 GMT
Subject: RFR: 8274894: Use Optional.empty() instead of ofNullable(null) in
 HttpResponse.BodySubscribers.discarding
Message-ID: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>

Usage of `Optional.ofNullable` is unnecessary when value is known. If it's `null` value Optional.empty() should be preferred, as it doesn't perform redundant `null` check.

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

Commit messages:
 - [PATCH] Cleanup Optional usage in HttpResponse.BodySubscribers.discarding

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

PR: https://git.openjdk.java.net/jdk/pull/5159

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 10:26:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 10:26:28 GMT
Subject: RFR: 8274894: Use Optional.empty() instead of ofNullable(null) in
 HttpResponse.BodySubscribers.discarding
In-Reply-To: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
References: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
Message-ID: <yr76voWOXrDFeuXQBiCz_JJeqczlXE2LDhXhd3DZg98=.7ae30013-5702-4757-8181-eeec687b86ac@github.com>

On Wed, 18 Aug 2021 07:55:35 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of `Optional.ofNullable` is unnecessary when value is known. If it's `null` value Optional.empty() should be preferred, as it doesn't perform redundant `null` check.

Not sure if it worth separate issue. But this this is small improvement in http client code.

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

PR: https://git.openjdk.java.net/jdk/pull/5159

From dfuchs at openjdk.java.net  Thu Oct  7 10:42:09 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 7 Oct 2021 10:42:09 GMT
Subject: RFR: 8274894: Use Optional.empty() instead of ofNullable(null) in
 HttpResponse.BodySubscribers.discarding
In-Reply-To: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
References: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
Message-ID: <NfiQosc3pQyHGYj_D_X3n3uO1L8joeX-lCjxh9b3UMA=.61363baa-1e78-4b26-88f5-45c120ae5145@github.com>

On Wed, 18 Aug 2021 07:55:35 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of `Optional.ofNullable` is unnecessary when value is known. If it's `null` value Optional.empty() should be preferred, as it doesn't perform redundant `null` check.

If you integrate I will sponsor.

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

PR: https://git.openjdk.java.net/jdk/pull/5159

From dfuchs at openjdk.java.net  Thu Oct  7 10:44:19 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 7 Oct 2021 10:44:19 GMT
Subject: RFR: 8274894: Use Optional.empty() instead of ofNullable(null) in
 HttpResponse.BodySubscribers.discarding
In-Reply-To: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
References: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
Message-ID: <zf-kGRPoMk763U6V8D9C0k2facy_Ynzh09ghMeYgkyQ=.354a960d-0398-4075-9cac-0dd9dbb9f20f@github.com>

On Wed, 18 Aug 2021 07:55:35 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of `Optional.ofNullable` is unnecessary when value is known. If it's `null` value Optional.empty() should be preferred, as it doesn't perform redundant `null` check.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5159

From aefimov at openjdk.java.net  Thu Oct  7 12:11:36 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 7 Oct 2021 12:11:36 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v2]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <dMUneM5p-a7rqI0dGENOIlnu5UeYpsqz8LWFqAlJpSM=.4ec033de-9e34-41c0-a81d-b53855161d5f@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/77551538..41717fc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00-01

  Stats: 4216 lines in 179 files changed: 1929 ins; 1744 del; 543 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From michael.x.mcmahon at oracle.com  Thu Oct  7 14:40:12 2021
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 7 Oct 2021 15:40:12 +0100
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
 <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
Message-ID: <d2d6f5b6-e9b7-c002-26ca-98b24123f696@oracle.com>

I think we should at least clarify the behavior of 
HttpRequest.Builder.timeout() ie. that it is specifically related to the 
response headers, and maybe consider adding a timeout variant that sets 
the timeout for the entire response, including the body.

- Michael.

On 06/10/2021 10:42, Daniel Fuchs wrote:
> Hi Eliot,
>
> Unless the server keeps the connection open, and fails to send all the
> body bytes it has promised to send, the send operation should eventually
> terminate. The behavior you describe looks indeed like a bug.
>
> Could you please log a ticket with:
> https://bugreport.java.com/bugreport/
>
> That said - there is very little information here to work with.
> It would be helpful to understand with which version of the protocol
> this happened: HTTP or HTTPS? Version 1.1 or Version 2? Was it
> with an upgrade request (h2c)?
>
> If you manage to reproduce, it would be helpful if HTTP traces
> could be enabled - I'd suggest:
> `-Djdk.httpclient.HttpClient.log=headers,requests,errors`
> (see https://docs.oracle.com/en/java/javase/17/core/java-networking.html)
>
> Another issue here is that the request timeout set through
> `HttpRequestBuilder::timeout` only runs until the response
> headers are received. The reception of the body bytes is not
> covered by this timeout. This is not well documented, and
> we should probably do a better job there.
>
> We have an enhancement request related to this:
> https://bugs.openjdk.java.net/browse/JDK-8258397
>
> However - setting up a global timeout for the request
> is already possible:
>
> If you wish to set a timeout for the reception of the body
> bytes you can do so by making use of the timeout facility
> provided by CompletableFuture:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html#get(long,java.util.concurrent.TimeUnit) 
>
>
> Instead of:
>
> ```
> ? String html = httpClient.send(request,
> ????? HttpResponse.BodyHandlers.ofString()).body();
> ```
>
> Use:
>
> ```
> ? long timeout = 5000; // ms
> ? String html;
> ? CompletableFuture<HttpResponse<String>> cf;
> ? try {
> ????? cf = httpClient.sendAsync(request,
> ????????? HttpResponse.BodyHandlers.ofString());
> ????? html = cf.get(timeout, TimedUnit.MILLISECONDS)
> ?????????????? .body();
> ? } catch (TimeoutException x) {
> ????? // timeout: cancel request to free up
> ????? //?? any related resources
> ????? cf.cancel();
> ? } catch (CancellationException x) {
> ????? // cancelled
> ? } catch (InterruptedException x) {
> ????? // interrupted
> ? } catch (ExecutionException x) {
> ????? // IO etc..
> ????? // unwrap to get exception and rethrow...
> ? }
> ```
>
> This offers the possibility to set up a global timeout
> You can also cancel the request asynchronously at any
> time by calling cf.cancel() (since Java 15 IIRC).
>
> best regards,
>
> -- daniel
>
>
> On 05/10/2021 23:05, Elliot Barlas wrote:
>> Hello net-dev!
>>
>> I'm emailing about a surprising observation in the HttpClient send 
>> method related to guaranteed completion.
>>
>> Despite explicit timeout configurations, a call to send can block 
>> indefinitely. The stacktrace below was obtained from a thread dump on 
>> a running OpenJDK 16.0.2 JVM. The thread was stuck in that state for 
>> over a week. An application restart was required to recover. The 
>> related Java source code is also included below.
>>
>> My sense is that this is due to a missed notification from the async 
>> I/O subsystem. Unfortunately, I'm not an expert on HttpClient 
>> internals, and the asynchronous nature of the code makes it 
>> challenging to debug.
>>
>> Is this the intended behavior? That is, are there scenarios in which 
>> send should never return? Did I miss a socket timeout option?
>>
>> -----
>>
>> HttpClient httpClient = HttpClient.newBuilder()
>> ?? ? ? ? .version(HttpClient.Version.HTTP_1_1)
>> ?? ? ? ? .connectTimeout(Duration.ofSeconds(5))
>> ?? ? ? ? .build();
>> ...
>> HttpRequest request = HttpRequest.newBuilder()
>> ?? ? ? ? .timeout(Duration.ofSeconds(5))
>> ?? ? ? ? .uri(URI.create("http://" + ip + ":" + port + "/frontend"))
>> ?? ? ? ? .build();
>> ...
>> String html = httpClient.send(request, 
>> HttpResponse.BodyHandlers.ofString()).body();
>>
>> -----
>>
>> "pool-1-thread-70" #164 prio=5 os_prio=0 cpu=100038.29ms 
>> elapsed=1891832.58s tid=0x00007fe0211d4050 nid=0x29e waiting on 
>> condition ?[0x00007fdf025ac000]
>> ?? ?java.lang.Thread.State: WAITING (parking)
>> ?? ? ? ? at jdk.internal.misc.Unsafe.park(java.base at 16.0.2/Native 
>> Method)
>> ?? ? ? ? - parking to wait for ?<0x00000000e7fc9be0> (a 
>> java.util.concurrent.CompletableFuture$Signaller)
>> ?? ? ? ? at 
>> java.util.concurrent.locks.LockSupport.park(java.base at 16.0.2/LockSupport.java:211)
>> ?? ? ? ? at 
>> java.util.concurrent.CompletableFuture$Signaller.block(java.base at 16.0.2/CompletableFuture.java:1860)
>> ?? ? ? ? at 
>> java.util.concurrent.ForkJoinPool.managedBlock(java.base at 16.0.2/ForkJoinPool.java:3137)
>> ?? ? ? ? at 
>> java.util.concurrent.CompletableFuture.waitingGet(java.base at 16.0.2/CompletableFuture.java:1894)
>> ?? ? ? ? at 
>> java.util.concurrent.CompletableFuture.get(java.base at 16.0.2/CompletableFuture.java:2068)
>> ?? ? ? ? at 
>> jdk.internal.net.http.HttpClientImpl.send(java.net.http at 16.0.2/HttpClientImpl.java:535)
>> ?? ? ? ? at 
>> jdk.internal.net.http.HttpClientFacade.send(java.net.http at 16.0.2/HttpClientFacade.java:119)
>> ?? ? ? ? at 
>> com.logmein.haproxy.ProxyFrontendConnectionCounter.countCurrentConnections(ProxyFrontendConnectionCounter.java:89)
>> ?? ? ? ? at 
>> com.logmein.haproxy.ProxyFrontendConnectionCounter.doRun(ProxyFrontendConnectionCounter.java:74)
>> ?? ? ? ? at 
>> com.logmein.haproxy.ProxyFrontendConnectionCounter.run(ProxyFrontendConnectionCounter.java:59)
>> ?? ? ? ? at 
>> com.logmein.haproxy.ProxyFrontendConnectionCounter$$Lambda$712/0x00000008010a0a88.run(Unknown 
>> Source)
>> ?? ? ? ? at 
>> java.util.concurrent.Executors$RunnableAdapter.call(java.base at 16.0.2/Executors.java:515)
>> ?? ? ? ? at 
>> java.util.concurrent.FutureTask.runAndReset(java.base at 16.0.2/FutureTask.java:305)
>> ?? ? ? ? at 
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 16.0.2/ScheduledThreadPoolExecutor.java:305)
>> ?? ? ? ? at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 16.0.2/ThreadPoolExecutor.java:1130)
>> ?? ? ? ? at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 16.0.2/ThreadPoolExecutor.java:630)
>> ?? ? ? ? at java.lang.Thread.run(java.base at 16.0.2/Thread.java:831)
>>
>>
>> Elliot Barlas
>> elliot.barlas at logmein.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211007/2d660b71/attachment-0001.htm>

From dfuchs at openjdk.java.net  Thu Oct  7 15:36:11 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 7 Oct 2021 15:36:11 GMT
Subject: RFR: 8274894: Use Optional.empty() instead of ofNullable(null) in
 HttpResponse.BodySubscribers.discarding
In-Reply-To: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
References: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
Message-ID: <brG0xIS_EhAQqi3DphbaQKk2I1jSa1YJXo2Z9q5uGko=.8d210f07-b138-4237-82c7-1631a0065edd@github.com>

On Wed, 18 Aug 2021 07:55:35 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of `Optional.ofNullable` is unnecessary when value is known. If it's `null` value Optional.empty() should be preferred, as it doesn't perform redundant `null` check.

hmm... looks like something went wrong. Maybe you should /integrate again?

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

PR: https://git.openjdk.java.net/jdk/pull/5159

From naoto at openjdk.java.net  Thu Oct  7 16:52:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Oct 2021 16:52:13 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

src/java.base/share/classes/java/lang/Character.java line 123:

> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
> 123:  * in the {@code String} and {@code StringBuilder} classes. In

Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 16:59:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 16:59:11 GMT
Subject: Integrated: 8273910: Redundant condition and assignment in
 java.net.URI
In-Reply-To: <Naw1o2EW4fiL28UiHRsTUA0gOH2G5N_ZY5XeOm-9ObE=.dee1b0fd-b8b0-4635-8581-c1e8912a2667@github.com>
References: <Naw1o2EW4fiL28UiHRsTUA0gOH2G5N_ZY5XeOm-9ObE=.dee1b0fd-b8b0-4635-8581-c1e8912a2667@github.com>
Message-ID: <ACjr_7-W878khXfiTrtAjV_RUHzPW11o55CBmiR2H5U=.41b91d92-50fe-4a2a-9795-b96a8b6f050c@github.com>

On Thu, 19 Aug 2021 19:08:59 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 1. Assignment `ru.host = child.host;` is duplicated and hence redundant.
> 2. Condition `q > p` is always `true`, because it just bellow inverse check
> 
>                 if (q <= p)
>                     break;

This pull request has now been integrated.

Changeset: 7de2cf85
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7de2cf852d75ea6eb039e69067d4e32421283de5
Stats:     11 lines in 1 file changed: 4 ins; 7 del; 0 mod

8273910: Redundant condition and assignment in java.net.URI

Reviewed-by: dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5190

From Elliot.Barlas at logmein.com  Thu Oct  7 17:09:00 2021
From: Elliot.Barlas at logmein.com (Elliot Barlas)
Date: Thu, 7 Oct 2021 17:09:00 +0000
Subject: HttpClient Send Method Guaranteed Completion
In-Reply-To: <d2d6f5b6-e9b7-c002-26ca-98b24123f696@oracle.com>
References: <BYAPR15MB26470FDE6A69778B7F91F969E8AF9@BYAPR15MB2647.namprd15.prod.outlook.com>
 <c2ea1dd9-213d-4865-516c-7bbb84abf891@oracle.com>
 <d2d6f5b6-e9b7-c002-26ca-98b24123f696@oracle.com>
Message-ID: <BYAPR15MB2647D65B459072AEFD023C7EE8B19@BYAPR15MB2647.namprd15.prod.outlook.com>

That would be great. There are many synchronous, threaded applications that want to ensure eventual completion and the work around is cumbersome and non-obvious.

It looks like there are already several related enhancement requests.

Thanks again for the help.
________________________________
From: Michael McMahon <michael.x.mcmahon at oracle.com>
Sent: Thursday, October 7, 2021 7:40 AM
To: Daniel Fuchs <daniel.fuchs at oracle.com>; Elliot Barlas <Elliot.Barlas at logmein.com>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: Re: HttpClient Send Method Guaranteed Completion


I think we should at least clarify the behavior of HttpRequest.Builder.timeout() ie. that it is specifically related to the response headers, and maybe consider adding a timeout variant that sets the timeout for the entire response, including the body.

- Michael.

On 06/10/2021 10:42, Daniel Fuchs wrote:
Hi Eliot,

Unless the server keeps the connection open, and fails to send all the
body bytes it has promised to send, the send operation should eventually
terminate. The behavior you describe looks indeed like a bug.

Could you please log a ticket with:
https://bugreport.java.com/bugreport/<https://urldefense.com/v3/__https://bugreport.java.com/bugreport/__;!!OA8L0MA-!qbgY3D4kbHdhzZj7vTjF-gwr4hN9lyHcUoBPZW_5vUCebofdPVe937JEa-sJwAZmBNg$>

That said - there is very little information here to work with.
It would be helpful to understand with which version of the protocol
this happened: HTTP or HTTPS? Version 1.1 or Version 2? Was it
with an upgrade request (h2c)?

If you manage to reproduce, it would be helpful if HTTP traces
could be enabled - I'd suggest:
`-Djdk.httpclient.HttpClient.log=headers,requests,errors`
(see https://docs.oracle.com/en/java/javase/17/core/java-networking.html<https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/17/core/java-networking.html__;!!OA8L0MA-!qbgY3D4kbHdhzZj7vTjF-gwr4hN9lyHcUoBPZW_5vUCebofdPVe937JEa-sJ67i7iPI$>)

Another issue here is that the request timeout set through
`HttpRequestBuilder::timeout` only runs until the response
headers are received. The reception of the body bytes is not
covered by this timeout. This is not well documented, and
we should probably do a better job there.

We have an enhancement request related to this:
https://bugs.openjdk.java.net/browse/JDK-8258397<https://urldefense.com/v3/__https://bugs.openjdk.java.net/browse/JDK-8258397__;!!OA8L0MA-!qbgY3D4kbHdhzZj7vTjF-gwr4hN9lyHcUoBPZW_5vUCebofdPVe937JEa-sJu5TSfSc$>

However - setting up a global timeout for the request
is already possible:

If you wish to set a timeout for the reception of the body
bytes you can do so by making use of the timeout facility
provided by CompletableFuture:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html#get(long,java.util.concurrent.TimeUnit)<https://urldefense.com/v3/__https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletableFuture.html*get(long,java.util.concurrent.TimeUnit)__;Iw!!OA8L0MA-!qbgY3D4kbHdhzZj7vTjF-gwr4hN9lyHcUoBPZW_5vUCebofdPVe937JEa-sJKoYa4r4$>

Instead of:

```
  String html = httpClient.send(request,
      HttpResponse.BodyHandlers.ofString()).body();
```

Use:

```
  long timeout = 5000; // ms
  String html;
  CompletableFuture<HttpResponse<String>> cf;
  try {
      cf = httpClient.sendAsync(request,
          HttpResponse.BodyHandlers.ofString());
      html = cf.get(timeout, TimedUnit.MILLISECONDS)
               .body();
  } catch (TimeoutException x) {
      // timeout: cancel request to free up
      //   any related resources
      cf.cancel();
  } catch (CancellationException x) {
      // cancelled
  } catch (InterruptedException x) {
      // interrupted
  } catch (ExecutionException x) {
      // IO etc..
      // unwrap to get exception and rethrow...
  }
```

This offers the possibility to set up a global timeout
You can also cancel the request asynchronously at any
time by calling cf.cancel() (since Java 15 IIRC).

best regards,

-- daniel


On 05/10/2021 23:05, Elliot Barlas wrote:
Hello net-dev!

I'm emailing about a surprising observation in the HttpClient send method related to guaranteed completion.

Despite explicit timeout configurations, a call to send can block indefinitely. The stacktrace below was obtained from a thread dump on a running OpenJDK 16.0.2 JVM. The thread was stuck in that state for over a week. An application restart was required to recover. The related Java source code is also included below.

My sense is that this is due to a missed notification from the async I/O subsystem. Unfortunately, I'm not an expert on HttpClient internals, and the asynchronous nature of the code makes it challenging to debug.

Is this the intended behavior? That is, are there scenarios in which send should never return? Did I miss a socket timeout option?

-----

HttpClient httpClient = HttpClient.newBuilder()
         .version(HttpClient.Version.HTTP_1_1)
         .connectTimeout(Duration.ofSeconds(5))
         .build();
...
HttpRequest request = HttpRequest.newBuilder()
         .timeout(Duration.ofSeconds(5))
         .uri(URI.create("http://"<https://urldefense.com/v3/__http://*22__;JQ!!OA8L0MA-!qbgY3D4kbHdhzZj7vTjF-gwr4hN9lyHcUoBPZW_5vUCebofdPVe937JEa-sJJqAshag$> + ip + ":" + port + "/frontend"))
         .build();
...
String html = httpClient.send(request, HttpResponse.BodyHandlers.ofString()).body();

-----

"pool-1-thread-70" #164 prio=5 os_prio=0 cpu=100038.29ms elapsed=1891832.58s tid=0x00007fe0211d4050 nid=0x29e waiting on condition  [0x00007fdf025ac000]
    java.lang.Thread.State: WAITING (parking)
         at jdk.internal.misc.Unsafe.park(java.base at 16.0.2/Native<mailto:java.base at 16.0.2/Native> Method)
         - parking to wait for  <0x00000000e7fc9be0> (a java.util.concurrent.CompletableFuture$Signaller)
         at java.util.concurrent.locks.LockSupport.park(java.base at 16.0.2/LockSupport.java:211<mailto:java.base at 16.0.2/LockSupport.java:211>)
         at java.util.concurrent.CompletableFuture$Signaller.block(java.base at 16.0.2/CompletableFuture.java:1860<mailto:java.base at 16.0.2/CompletableFuture.java:1860>)
         at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 16.0.2/ForkJoinPool.java:3137<mailto:java.base at 16.0.2/ForkJoinPool.java:3137>)
         at java.util.concurrent.CompletableFuture.waitingGet(java.base at 16.0.2/CompletableFuture.java:1894<mailto:java.base at 16.0.2/CompletableFuture.java:1894>)
         at java.util.concurrent.CompletableFuture.get(java.base at 16.0.2/CompletableFuture.java:2068<mailto:java.base at 16.0.2/CompletableFuture.java:2068>)
         at jdk.internal.net.http.HttpClientImpl.send(java.net.http at 16.0.2/HttpClientImpl.java:535<mailto:java.net.http at 16.0.2/HttpClientImpl.java:535>)
         at jdk.internal.net.http.HttpClientFacade.send(java.net.http at 16.0.2/HttpClientFacade.java:119<mailto:java.net.http at 16.0.2/HttpClientFacade.java:119>)
         at com.logmein.haproxy.ProxyFrontendConnectionCounter.countCurrentConnections(ProxyFrontendConnectionCounter.java:89)
         at com.logmein.haproxy.ProxyFrontendConnectionCounter.doRun(ProxyFrontendConnectionCounter.java:74)
         at com.logmein.haproxy.ProxyFrontendConnectionCounter.run(ProxyFrontendConnectionCounter.java:59)
         at com.logmein.haproxy.ProxyFrontendConnectionCounter$$Lambda$712/0x00000008010a0a88.run(Unknown Source)
         at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 16.0.2/Executors.java:515<mailto:java.base at 16.0.2/Executors.java:515>)
         at java.util.concurrent.FutureTask.runAndReset(java.base at 16.0.2/FutureTask.java:305<mailto:java.base at 16.0.2/FutureTask.java:305>)
         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base at 16.0.2/ScheduledThreadPoolExecutor.java:305<mailto:java.base at 16.0.2/ScheduledThreadPoolExecutor.java:305>)
         at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 16.0.2/ThreadPoolExecutor.java:1130<mailto:java.base at 16.0.2/ThreadPoolExecutor.java:1130>)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 16.0.2/ThreadPoolExecutor.java:630<mailto:java.base at 16.0.2/ThreadPoolExecutor.java:630>)
         at java.lang.Thread.run(java.base at 16.0.2/Thread.java:831<mailto:java.base at 16.0.2/Thread.java:831>)


Elliot Barlas
elliot.barlas at logmein.com<mailto:elliot.barlas at logmein.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211007/4c766dc5/attachment-0001.htm>

From weijun at openjdk.java.net  Fri Oct  8 07:29:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 8 Oct 2021 07:29:27 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <2wrfMoUmLw_xar7QqdTGlx3lRRn5ezXWZI3F6MIJoVo=.9e0d608d-6cf2-47ad-ae11-134f5d77bffe@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

security-related change looks fine.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5559

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 07:29:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 07:29:27 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf() in
 java.base
Message-ID: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>

String.contains was introduced in Java 5.
Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
I propose to migrate such usages. Makes code shorter and easier to read.

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

Commit messages:
 - [PATCH] Use String.contains() instead of String.indexOf() in java.base
 - [PATCH] Use String.contains() instead of String.indexOf() in java.base

Changes: https://git.openjdk.java.net/jdk/pull/5559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5559&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274949
  Stats: 40 lines in 17 files changed: 0 ins; 3 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5559/head:pull/5559

PR: https://git.openjdk.java.net/jdk/pull/5559

From dfuchs at openjdk.java.net  Fri Oct  8 09:38:04 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Oct 2021 09:38:04 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Changes to java.net look OK. Did you run tier1, tier2?

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5559

From vtewari at openjdk.java.net  Fri Oct  8 10:15:07 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 8 Oct 2021 10:15:07 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <IK_jmGQWQ0HohqSRE-kTgY-Xcjab4WNHUbkO3ITkDp4=.2c7d07c2-150b-4752-a429-f81da53621cb@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

java.net changes look OK to me.

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

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5559

From lancea at openjdk.java.net  Fri Oct  8 10:20:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 8 Oct 2021 10:20:09 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <w0KXXui1E0dtoghdpDHBut8BcBEesJdxM8-0O-DvEB4=.0ff06e02-50e2-4eb8-baa3-53d80db03e27@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5559

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 14:01:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 14:01:10 GMT
Subject: RFR: 8274949: Use String.contains() instead of String.indexOf()
 in java.base
In-Reply-To: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
 <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>
Message-ID: <w_TDnyfEJSM2qLXD2W0TGC5jlTDA1UFo3fyR2gySq5U=.b26a16ce-69f8-44b7-b1d8-069fd7c1ce31@github.com>

On Fri, 8 Oct 2021 09:35:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>Did you run tier1, tier2?

I did run tier2. (tier1 is automatically checked by GithubActions).
No new tests failed. Only _usual_ tests, which always fail on my machine, were failed.

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

PR: https://git.openjdk.java.net/jdk/pull/5559

From pconcannon at openjdk.java.net  Mon Oct 11 09:49:28 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 11 Oct 2021 09:49:28 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations
Message-ID: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>

Hi,

Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?

These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.

Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?

CSR: https://bugs.openjdk.java.net/browse/JDK-8274633

Kind regards,

Patrick

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

Commit messages:
 - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

Changes: https://git.openjdk.java.net/jdk/pull/5887/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5887&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260428
  Stats: 346 lines in 3 files changed: 258 ins; 74 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5887/head:pull/5887

PR: https://git.openjdk.java.net/jdk/pull/5887

From alanb at openjdk.java.net  Mon Oct 11 18:15:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 11 Oct 2021 18:15:47 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations
In-Reply-To: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
Message-ID: <Z9zeiMehE415CcoqjSMw03aKaSZTCP0bk4Cs1f5Zxdc=.d4e98391-ceda-4c62-9c84-4498b015662b@github.com>

On Mon, 11 Oct 2021 09:42:12 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
> 
> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
> 
> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
> 
> Kind regards,
> 
> Patrick

src/java.base/share/classes/java/net/DatagramSocketImpl.java line 105:

> 103:      *
> 104:      * @implSpec the default implementation of this method always throws {@code SocketException}
> 105:      *

The implementation change looks fine. For the implSpec then it might be simpler if you drop "always" from the sentence. Also minor nit is that you use "the default" in connect vs. "The default" in disconnect.

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From duke at openjdk.java.net  Mon Oct 11 20:47:14 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 20:47:14 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in java.net.http
Message-ID: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>

Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

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

Commit messages:
 - 8275079: Remove unnecessary conversion to String in java.net.http
 - [PATCH] Remove unnecessary conversion to String

Changes: https://git.openjdk.java.net/jdk/pull/5795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5795&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275079
  Stats: 34 lines in 13 files changed: 0 ins; 3 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5795/head:pull/5795

PR: https://git.openjdk.java.net/jdk/pull/5795

From weijun at openjdk.java.net  Mon Oct 11 20:47:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 11 Oct 2021 20:47:14 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
Message-ID: <87fb8y4-vNQNzTfuT7k29GdH0VHrOQsJEoCvec5TpCk=.d4dce725-fbd0-4661-b560-e3e90d251c4f@github.com>

On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

Some small comments.

src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 738:

> 736:             if (flowTag != null) {
> 737:                 dbgTag = tag = "Http1AsyncReceiver("+ flowTag + ")";
> 738:             } else {

If the only use of `flowTag` is `flow` in string, it looks like `flow` is enough. i.e.


if (flow != null) {
    dbgTag = tag = "Http1AsyncReceiver("+ flow + ")";
}

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 831:

> 829:         @Override
> 830:         public String toString() {
> 831:             return super.toString() + "/parser=" + parser;

Can we use `super` instead of `super.toString()`?

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

PR: https://git.openjdk.java.net/jdk/pull/5795

From duke at openjdk.java.net  Mon Oct 11 20:47:15 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 20:47:15 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <87fb8y4-vNQNzTfuT7k29GdH0VHrOQsJEoCvec5TpCk=.d4dce725-fbd0-4661-b560-e3e90d251c4f@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
 <87fb8y4-vNQNzTfuT7k29GdH0VHrOQsJEoCvec5TpCk=.d4dce725-fbd0-4661-b560-e3e90d251c4f@github.com>
Message-ID: <ZqH3n14HyD2YZrm3ybrPDseFPRZ19oE5pwx1rXOR07k=.7050978e-1b99-4a4b-b895-371c4ca6c132@github.com>

On Mon, 4 Oct 2021 13:39:00 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 738:
> 
>> 736:             if (flowTag != null) {
>> 737:                 dbgTag = tag = "Http1AsyncReceiver("+ flowTag + ")";
>> 738:             } else {
> 
> If the only use of `flowTag` is `flow` in string, it looks like `flow` is enough. i.e.
> 
> 
> if (flow != null) {
>     dbgTag = tag = "Http1AsyncReceiver("+ flow + ")";
> }

Good idea. Improved.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 831:
> 
>> 829:         @Override
>> 830:         public String toString() {
>> 831:             return super.toString() + "/parser=" + parser;
> 
> Can we use `super` instead of `super.toString()`?

Nope. `super` is not a valid java expression.

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

PR: https://git.openjdk.java.net/jdk/pull/5795

From duke at openjdk.java.net  Mon Oct 11 21:08:49 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 21:08:49 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes
In-Reply-To: <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
Message-ID: <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>

On Thu, 7 Oct 2021 16:48:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.
>
> src/java.base/share/classes/java/lang/Character.java line 123:
> 
>> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
> 
> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.

reverted changes in this spec.

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From vtewari at openjdk.java.net  Tue Oct 12 07:13:55 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Tue, 12 Oct 2021 07:13:55 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations
In-Reply-To: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
Message-ID: <4yKZIJQtusSJ3LAub2m2Dnu-VJdeyLJghZtmwxR6CIg=.4e684835-6dd8-4b3d-95f2-1ff125a24313@github.com>

On Mon, 11 Oct 2021 09:42:12 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
> 
> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
> 
> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
> 
> Kind regards,
> 
> Patrick

src/java.base/share/classes/java/net/NetMulticastSocket.java line 346:

> 344:                         // peek at the packet to see who it is from.
> 345:                         DatagramPacket peekPacket = new DatagramPacket(new byte[1], 1);
> 346:                         peekPort = getImpl().peekData(peekPacket);

Is it possible for you to combine the variable declaration and assignment as follows ?. This will increase the code readability little bit. 

 int peekPort = getImpl().peekData(peekPacket);
 String peekAd = peekPacket.getAddress().getHostAddress();

src/java.base/share/classes/java/net/NetMulticastSocket.java line 383:

> 381:                     // peek at the packet to see who it is from.
> 382:                     DatagramPacket peekPacket = new DatagramPacket(new byte[1], 1);
> 383:                     peekPort = getImpl().peekData(peekPacket);

same as previous comment.

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From jboes at openjdk.java.net  Tue Oct 12 10:40:15 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 12 Oct 2021 10:40:15 GMT
Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9]
In-Reply-To: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
References: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
Message-ID: <tSHlnK8VlshJiCHMBx0bff2c3k3hs6TjWA6U7LM8ouk=.a50bc1be-879d-426b-9ee6-a3f2ffb85d0f@github.com>

> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`.
> 
> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK.
> 
> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging.
> 
> Additionally, a small API is introduced for programmatic creation and customization.
> 
> Testing: tier1-3.

Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Minor rewording of bind address output
 - Merge branch 'master' into simpleserver
 - Merge branch 'master' into simpleserver
 - update output for all interfaces
 - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces
 - Merge branch 'master' into simpleserver
 - change default bind address from anylocal to loopback
 - address PR comments
 - Merge branch 'master' into simpleserver
 - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0

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

Changes: https://git.openjdk.java.net/jdk/pull/5505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=08
  Stats: 7181 lines in 42 files changed: 7146 ins; 15 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505

PR: https://git.openjdk.java.net/jdk/pull/5505

From dfuchs at openjdk.java.net  Tue Oct 12 11:07:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 12 Oct 2021 11:07:52 GMT
Subject: RFR: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
Message-ID: <5FSqzpEvZGf9ySa94vZxYUWWMUmzXNovK-IH_FAgYwY=.fe97f522-7a64-46a4-a673-bdf6378d8052@github.com>

On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

LGTM

Hi Andrey - I will sponsor this change.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5795

From duke at openjdk.java.net  Tue Oct 12 11:17:52 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 11:17:52 GMT
Subject: Integrated: 8274894: Use Optional.empty() instead of ofNullable(null)
 in HttpResponse.BodySubscribers.discarding
In-Reply-To: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
References: <Dl1qDT7fjPMp2RL94oLLSs5GfU7EM-1UT7kzMR3dhOg=.9fa13f89-2241-4b85-bfea-faab9fca33ee@github.com>
Message-ID: <EqZs7H1RyIOL2DTsiLF3vQFGxegdv4l1hleMTNGlcw8=.5c60e915-f2cd-4ba6-9f71-94233a444f51@github.com>

On Wed, 18 Aug 2021 07:55:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Usage of `Optional.ofNullable` is unnecessary when value is known. If it's `null` value Optional.empty() should be preferred, as it doesn't perform redundant `null` check.

This pull request has now been integrated.

Changeset: d04d4ee2
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d04d4ee2c193baf4339ee3025e3fbcd31d62f484
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8274894: Use Optional.empty() instead of ofNullable(null) in HttpResponse.BodySubscribers.discarding

Reviewed-by: dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5159

From dfuchs at openjdk.java.net  Tue Oct 12 11:26:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 12 Oct 2021 11:26:49 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations
In-Reply-To: <Z9zeiMehE415CcoqjSMw03aKaSZTCP0bk4Cs1f5Zxdc=.d4e98391-ceda-4c62-9c84-4498b015662b@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <Z9zeiMehE415CcoqjSMw03aKaSZTCP0bk4Cs1f5Zxdc=.d4e98391-ceda-4c62-9c84-4498b015662b@github.com>
Message-ID: <DGW4lOh2lx6XCSD6slgqR0zNROAEyBSXPgGZ0cbJ_KU=.4513e504-14db-4c5b-86e1-8dca290da858@github.com>

On Mon, 11 Oct 2021 18:12:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
>> 
>> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
>> 
>> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
>> 
>> Kind regards,
>> 
>> Patrick
>
> src/java.base/share/classes/java/net/DatagramSocketImpl.java line 105:
> 
>> 103:      *
>> 104:      * @implSpec the default implementation of this method always throws {@code SocketException}
>> 105:      *
> 
> The implementation change looks fine. For the implSpec then it might be simpler if you drop "always" from the sentence. Also minor nit is that you use "the default" in connect vs. "The default" in disconnect.

The preferred style would be to start the sentence with a capital letter and end it with a period (unlike `@param`)

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From dfuchs at openjdk.java.net  Tue Oct 12 11:26:50 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 12 Oct 2021 11:26:50 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations
In-Reply-To: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
Message-ID: <Khc30Mh4KZCamdDdD_6P3s6FAkMHlW12nBm92eI-d2g=.877cb282-253b-4718-8b2e-9d9096cde65d@github.com>

On Mon, 11 Oct 2021 09:42:12 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
> 
> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
> 
> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
> 
> Kind regards,
> 
> Patrick

test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java line 165:

> 163:     }
> 164: 
> 165:     private class OldDatagramSocketImplWithValidConnect extends DatagramSocketImpl implements AutoCloseable {

Maybe this class could extend the previous one, that would remove some of the boiler plate code where dummy stub method implementations are the same.

test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java line 231:

> 229:         }
> 230:     }
> 231: 

Maybe add a short one comment:


// Overriding connect() to make it public so that it can be called
// directly from the test code


(and do the same for disconnect below)

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From pconcannon at openjdk.java.net  Tue Oct 12 15:41:30 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 12 Oct 2021 15:41:30 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v2]
In-Reply-To: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
Message-ID: <gyOXBEpsl7evfj-qveYqxid_BjEjr1D_eGjEFB0HWtw=.a0cef6f6-75a2-44a5-9dbd-c794e898fb96@github.com>

> Hi,
> 
> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
> 
> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
> 
> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
> 
> Kind regards,
> 
> Patrick

Patrick Concannon 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:

 - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
 - Merge remote-tracking branch 'origin/master' into JDK-8260428
 - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5887/files
  - new: https://git.openjdk.java.net/jdk/pull/5887/files/e17a8d98..67265bd4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5887&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5887&range=00-01

  Stats: 1586 lines in 73 files changed: 699 ins; 594 del; 293 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5887/head:pull/5887

PR: https://git.openjdk.java.net/jdk/pull/5887

From pconcannon at openjdk.java.net  Tue Oct 12 15:41:33 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 12 Oct 2021 15:41:33 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v2]
In-Reply-To: <DGW4lOh2lx6XCSD6slgqR0zNROAEyBSXPgGZ0cbJ_KU=.4513e504-14db-4c5b-86e1-8dca290da858@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <Z9zeiMehE415CcoqjSMw03aKaSZTCP0bk4Cs1f5Zxdc=.d4e98391-ceda-4c62-9c84-4498b015662b@github.com>
 <DGW4lOh2lx6XCSD6slgqR0zNROAEyBSXPgGZ0cbJ_KU=.4513e504-14db-4c5b-86e1-8dca290da858@github.com>
Message-ID: <Ht4UBHKzwiXebirUjruO59QYb782z3aFViuTzfUqL08=.296643fc-e789-456e-85a3-a6930b50a362@github.com>

On Tue, 12 Oct 2021 11:15:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/DatagramSocketImpl.java line 105:
>> 
>>> 103:      *
>>> 104:      * @implSpec the default implementation of this method always throws {@code SocketException}
>>> 105:      *
>> 
>> The implementation change looks fine. For the implSpec then it might be simpler if you drop "always" from the sentence. Also minor nit is that you use "the default" in connect vs. "The default" in disconnect.
>
> The preferred style would be to start the sentence with a capital letter and end it with a period (unlike `@param`)

Javadoc updated as requested, see commit 67265bd

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From pconcannon at openjdk.java.net  Tue Oct 12 15:41:38 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 12 Oct 2021 15:41:38 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v2]
In-Reply-To: <4yKZIJQtusSJ3LAub2m2Dnu-VJdeyLJghZtmwxR6CIg=.4e684835-6dd8-4b3d-95f2-1ff125a24313@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <4yKZIJQtusSJ3LAub2m2Dnu-VJdeyLJghZtmwxR6CIg=.4e684835-6dd8-4b3d-95f2-1ff125a24313@github.com>
Message-ID: <2idW3gC6pw2pfVD14EcRhqccab-iY6AxkG9zjE4UASo=.1727864a-505e-4887-90af-fb6417a50f5f@github.com>

On Tue, 12 Oct 2021 07:10:56 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Patrick Concannon 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:
>> 
>>  - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
>>  - Merge remote-tracking branch 'origin/master' into JDK-8260428
>>  - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations
>
> src/java.base/share/classes/java/net/NetMulticastSocket.java line 346:
> 
>> 344:                         // peek at the packet to see who it is from.
>> 345:                         DatagramPacket peekPacket = new DatagramPacket(new byte[1], 1);
>> 346:                         peekPort = getImpl().peekData(peekPacket);
> 
> Is it possible for you to combine the variable declaration and assignment as follows ?. This will increase the code readability little bit. 
> 
>  int peekPort = getImpl().peekData(peekPacket);
>  String peekAd = peekPacket.getAddress().getHostAddress();

Good catch, Vyom! Thanks for that. Code updated as suggested - see commit 67265bd

> src/java.base/share/classes/java/net/NetMulticastSocket.java line 383:
> 
>> 381:                     // peek at the packet to see who it is from.
>> 382:                     DatagramPacket peekPacket = new DatagramPacket(new byte[1], 1);
>> 383:                     peekPort = getImpl().peekData(peekPacket);
> 
> same as previous comment.

Addressed as above

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From pconcannon at openjdk.java.net  Tue Oct 12 15:41:42 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 12 Oct 2021 15:41:42 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v2]
In-Reply-To: <Khc30Mh4KZCamdDdD_6P3s6FAkMHlW12nBm92eI-d2g=.877cb282-253b-4718-8b2e-9d9096cde65d@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <Khc30Mh4KZCamdDdD_6P3s6FAkMHlW12nBm92eI-d2g=.877cb282-253b-4718-8b2e-9d9096cde65d@github.com>
Message-ID: <XNMmvMGOT0Z_iyb_LcMikLGXf34LmuQinliXhHCvJWo=.ed274093-0321-4019-921d-9501fbfe0eca@github.com>

On Tue, 12 Oct 2021 11:20:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon 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:
>> 
>>  - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
>>  - Merge remote-tracking branch 'origin/master' into JDK-8260428
>>  - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations
>
> test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java line 165:
> 
>> 163:     }
>> 164: 
>> 165:     private class OldDatagramSocketImplWithValidConnect extends DatagramSocketImpl implements AutoCloseable {
> 
> Maybe this class could extend the previous one, that would remove some of the boiler plate code where dummy stub method implementations are the same.

Good idea. Updated as suggested, see commit 67265bd

> test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java line 231:
> 
>> 229:         }
>> 230:     }
>> 231: 
> 
> Maybe add a short one comment:
> 
> 
> // Overriding connect() to make it public so that it can be called
> // directly from the test code
> 
> 
> (and do the same for disconnect below)

Comment added. See commit 67265bd

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From aefimov at openjdk.java.net  Tue Oct 12 15:43:24 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 12 Oct 2021 15:43:24 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:

 - Add @since tags to new API classes
 - Add checks and test for empty stream resolver results

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/41717fc7..d302a49a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=01-02

  Stats: 150 lines in 6 files changed: 146 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Tue Oct 12 15:54:49 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 12 Oct 2021 15:54:49 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v2]
In-Reply-To: <gyOXBEpsl7evfj-qveYqxid_BjEjr1D_eGjEFB0HWtw=.a0cef6f6-75a2-44a5-9dbd-c794e898fb96@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <gyOXBEpsl7evfj-qveYqxid_BjEjr1D_eGjEFB0HWtw=.a0cef6f6-75a2-44a5-9dbd-c794e898fb96@github.com>
Message-ID: <wBfkdjLK80idGTVe-usPpx9SDfRaUz_CfdTcsIC5qko=.45d4b2e4-78bd-490e-baf7-cdf46a8128cb@github.com>

On Tue, 12 Oct 2021 15:41:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
>> 
>> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
>> 
>> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
>  - Merge remote-tracking branch 'origin/master' into JDK-8260428
>  - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

The spec and implementation change look good. I don't have time to study the test right but I see Daniel is looking at it.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5887

From naoto at openjdk.java.net  Tue Oct 12 20:39:14 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Oct 2021 20:39:14 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
 <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
Message-ID: <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>

On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 123:
>> 
>>> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
>>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
>> 
>> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.
>
> reverted changes in this spec.

Did you modify the PR? I am unable to locate the revert.

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From duke at openjdk.java.net  Tue Oct 12 20:39:13 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 20:39:13 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
  revert changes in spec to avoid CSR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5432/files
  - new: https://git.openjdk.java.net/jdk/pull/5432/files/14005d1d..c8d68c2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From duke at openjdk.java.net  Tue Oct 12 20:39:14 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 20:39:14 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
 <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
 <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>
Message-ID: <J1wtQXATnYkW26m1PpnmlmQyjMgzGRdP4OtATWagep0=.796bb462-c2c3-4bcb-ad4c-a0525681f470@github.com>

On Tue, 12 Oct 2021 20:33:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> reverted changes in this spec.
>
> Did you modify the PR? I am unable to locate the revert.

Oops. Forgot to push

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From naoto at openjdk.java.net  Tue Oct 12 20:46:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Oct 2021 20:46:50 GMT
Subject: RFR: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes [v2]
In-Reply-To: <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>
Message-ID: <R-tgDRJ5SKkQATM35Q4ApUdtppXYZQqEw0vhC96tvuM=.907d5018-af76-4a7d-add7-d79238d30741@github.com>

On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
>   revert changes in spec to avoid CSR

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From duke at openjdk.java.net  Wed Oct 13 22:13:19 2021
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Wed, 13 Oct 2021 22:13:19 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency on
 sun.net.www.MessageHeader and some other internal APIs
Message-ID: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>

?t.www.MessageHeader and some other internal APIs

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

Commit messages:
 - JDK-8061729 : Update java/net tests to eliminate dependency on sun.net.www.MessageHeader and some other internal APIs

Changes: https://git.openjdk.java.net/jdk/pull/5937/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8061729
  Stats: 167 lines in 10 files changed: 111 ins; 15 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

PR: https://git.openjdk.java.net/jdk/pull/5937

From dfuchs at openjdk.java.net  Thu Oct 14 09:42:50 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 14 Oct 2021 09:42:50 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <s67a3OybwQZo1EZtAorTo9-pkxCO9cJ9omwcNMdsLAE=.646bfac0-8c85-4448-9187-3c687efefed7@github.com>

On Wed, 13 Oct 2021 22:04:23 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

It may be that the new library HttpHeaderParser works for the small use cases in which it is used, but its parsing of header fields is approximative. I am a bit uncomfortable by replacing a well tested parser (MessageHeader) with something that obviously doesn't implement the spec correctly - even though it's possible that the cases where it would give back a wrong answer do not occur in the scenario where it is used.

What is the underlying rationale for wanting to stop using MessageHeader in tests?

test/jdk/sun/net/www/protocol/http/NTLMTest.java line 163:

> 161: 
> 162:             for (int i=start; i<end; i++) {
> 163:                 MessageHeader header = new MessageHeader (s.getInputStream());

This change introduces a subtle behaviour difference in the test that may result in spurious "Connection Reset" exception. I would prefer if the existing logic was kept - and the test continued parsing the request headers before writing to the output.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 47:

> 45:             while(true) {
> 46:                 headerString = br.readLine();
> 47:                 if(headerString == null || headerString.isBlank()) {

This is not completely correct, a blank line would be an error, I think, or possibly an empty continuation line. isBlank() should be replaced by isEmpty().

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 54:

> 52:                     List <String> values = new ArrayList<>();
> 53:                     String headerValue = headerString.substring(headerString.indexOf(": ") + 2);
> 54:                     String [] valueArray = headerValue.split(",");

This is not right either - at least that's not how MessageHeader (or the HttpClient or HttpServer header parsers work). Multi-valued header correspond to header fields whose name appear on several lines.


foo: bar, baz

   => single value "bar, baz"


foo: bar
foo: baz


multiple values => "bar", "baz"

Usually - analyzing the value - and possibly splitting it around `,` or `;` is done in the second step at a higher level.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 62:

> 60:                 } else {
> 61:                     requestDetails = headerString.trim();
> 62:                 }

This is not right: the request line - or status line - is the first line which is read - not just any line that doesn't contain `:`
FWIW, a request line may contain the full URL and therefore may contain `:`

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 63:

> 61:                     requestDetails = headerString.trim();
> 62:                 }
> 63:             }

You should also take into account continuation lines (lines that begin with a space) - and IIRC a continuation would be \r followed by a space - so I'm not 100% sure that using readline() is completely appropriate as it will consume \r, \n, or \r\n equally.

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

PR: https://git.openjdk.java.net/jdk/pull/5937

From duke at openjdk.java.net  Fri Oct 15 05:08:59 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 15 Oct 2021 05:08:59 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error instead
 of SocketException
Message-ID: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>

Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.

All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.

Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.

I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.

`tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.

I don't have write access to JBS. I could use some help with creating a ticket.

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

Commit messages:
 - Throw SocketExceptions instead of Errors in NetworkInterface

Changes: https://git.openjdk.java.net/jdk/pull/5956/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275319
  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5956.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5956/head:pull/5956

PR: https://git.openjdk.java.net/jdk/pull/5956

From jpai at openjdk.java.net  Fri Oct 15 05:08:59 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 15 Oct 2021 05:08:59 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <rNxRCZmmS7XwVty00u5YxfvlhR18DGqJsxiz0JeZK1w=.03ce84c3-eaaf-45b3-b3f9-e91db555f68c@github.com>

On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

Hello @djelinski, 

> I don't have write access to JBS. I could use some help with creating a ticket.

I have created https://bugs.openjdk.java.net/browse/JDK-8275319 to track this. For this PR to trigger the PR review process, you will now have to update the PR title to match the bug id and bug title (and I think even the commit message should refer to the same).

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From alanb at openjdk.java.net  Fri Oct 15 06:33:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Oct 2021 06:33:47 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <HpX6FPp6povluGUFe8t6vS_kKXsn27__b60AVBY-PtY=.22fd6b9b-9d23-49c9-9776-8b798d2ce38f@github.com>

On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

I suspect most of these cases need a closer look as there may be cases that can never happen, meaning Error or InternalError would be more appropriate, e.g. if MultiByteToWideChar fails with ERROR_INVALID_FLAGS or ERROR_INVALID_PARAMETER for example.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From dfuchs at openjdk.java.net  Fri Oct 15 08:56:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 08:56:53 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <cL3gML1V3xZr6AKkrX98M0ebm1rlQLe5CO8y5cc5Oss=.303b745e-0535-432a-af26-2068045b184c@github.com>

On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

I have to agree with Alan on this. Is there any concrete case where an Error was observed, or is this pure speculation?
If there are concrete cases then the proper fix would probably be to examine the error code or condition that triggered the Error - and investigate if the native source code  can be updated to take remediation actions in those cases.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From ewhelan at openjdk.java.net  Fri Oct 15 08:58:08 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Fri, 15 Oct 2021 08:58:08 GMT
Subject: RFR: 8274779: HttpClient and HttpsClient incorrectly check request
 method when set to POST
Message-ID: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>

Hi,

Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 

When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 

This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.

The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.

All CI testing is green for this fix.

Kind regards,
Evan

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

Commit messages:
 - 8274779: HttpClient and HttpsClient incorrectly check request method when set to POST

Changes: https://git.openjdk.java.net/jdk/pull/5964/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274779
  Stats: 143 lines in 3 files changed: 141 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5964.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5964/head:pull/5964

PR: https://git.openjdk.java.net/jdk/pull/5964

From dfuchs at openjdk.java.net  Fri Oct 15 09:46:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 09:46:53 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <y6DLuU-SNj6UquprpR8fO8w6TinZIxVhI3sVLlBB0bM=.0f121dd5-f68d-4eac-8538-109232910c9c@github.com>

On Fri, 15 Oct 2021 08:49:20 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

Code changes look good. I am a bit more suspicious of the test.

test/jdk/sun/net/www/http/KeepAliveCache/RequestMethodEquality.java line 32:

> 30:  * @modules java.base/sun.net.www.http:+open
> 31:  *          java.base/sun.net.www.protocol.http
> 32:  * @run testng RequestMethodEquality

This test modifies some static fields in HttpClient so should run in /othervm

test/jdk/sun/net/www/http/KeepAliveCache/RequestMethodEquality.java line 95:

> 93:             // Injecting a mock KeepAliveCache that the HttpClient can use
> 94:             KeepAliveCache kac = new KeepAliveCache();
> 95:             kac.put(url, null, freshClient);

Instead of injecting a new KeepAliveCache you could get the cache already present in HttpClient. One way to do this is to use reflection - another is to inject an accessor class in the sun.net.www.http package. You may not even need to have to create a "fresh" HttpClient - there should be one there corresponding to the connection you already created?

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From duke at openjdk.java.net  Fri Oct 15 10:03:47 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 15 Oct 2021 10:03:47 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <rNxRCZmmS7XwVty00u5YxfvlhR18DGqJsxiz0JeZK1w=.03ce84c3-eaaf-45b3-b3f9-e91db555f68c@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <rNxRCZmmS7XwVty00u5YxfvlhR18DGqJsxiz0JeZK1w=.03ce84c3-eaaf-45b3-b3f9-e91db555f68c@github.com>
Message-ID: <9YongxZqpODL2KYHUfXfkPZwcDrJrjt0IrETgIS5NX4=.e6f0d377-0ce5-436b-adac-a75a9d1d0dd2@github.com>

On Fri, 15 Oct 2021 03:30:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Hello @djelinski, 
> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
> 
> I have created https://bugs.openjdk.java.net/browse/JDK-8275319 to track this. For this PR to trigger the PR review process, you will now have to update the PR title to match the bug id and bug title (and I think even the commit message should refer to the same).

@jaikiran thanks for the JBS. Editing PR title was sufficient.

> Is there any concrete case where an Error was observed?

It happens occasionally, as evidenced by JDK-8217298, JDK-8046500 (fixed), JDK-8165665, JDK-8066931, JDK-8057900, JDK-8065559(closed), JDK-8040229, JDK-8065078(fixed), JDK-8068597(fixed), numerous reports on Google (search for "error IP Helper Library"), and an ancient note found in my company's codebase, possibly no longer relevant.

> if MultiByteToWideChar fails

I started checking how such failures are handled elsewhere in JDK codebase, and the results are pretty inconsistent: [ignore result](https://github.com/openjdk/jdk/blob/7f52c50ba32eecf5f379f8db30ac6a5cc50b3b66/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L722), [normal error handling](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/native/libzip/zip_util.c#L147), [native assert](https://github.com/openjdk/jdk/blob/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014/src/hotspot/os/windows/os_windows.cpp#L4435), and Java error in NetworkInterface. Some consistency here would be nice, but then, I don't know which option I would pick. Google couldn't find any cases of "Error Cannot get multibyte", so I guess that doesn't happen too often.

> Error or InternalError

There are only 2 places in Java codebase where Error is thrown, one is NetworkInterface, the other one is [here](https://github.com/openjdk/jdk/blob/bebfae48e3f1643f2456d680d170dcc22f7231bf/src/java.base/unix/native/libjava/java_props_md.c#L508). `JNU_ThrowInternalError` is definitely the more popular option.

Still, I'd argue that even if an unhandled error in IP helper library indicates a bug in JDK, throwing a checked exception is a better option here, because:
- these errors do not indicate that the JVM is broken / unusable, at least not any more than it was before the function was called. They do not affect global JVM state in any way
- a checked exception is less likely to go unnoticed (uncaught Error will usually terminate one thread, and let other threads continue; checked exception needs to be handled by user code)

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From dfuchs at openjdk.java.net  Fri Oct 15 11:25:50 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 11:25:50 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <9YongxZqpODL2KYHUfXfkPZwcDrJrjt0IrETgIS5NX4=.e6f0d377-0ce5-436b-adac-a75a9d1d0dd2@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <rNxRCZmmS7XwVty00u5YxfvlhR18DGqJsxiz0JeZK1w=.03ce84c3-eaaf-45b3-b3f9-e91db555f68c@github.com>
 <9YongxZqpODL2KYHUfXfkPZwcDrJrjt0IrETgIS5NX4=.e6f0d377-0ce5-436b-adac-a75a9d1d0dd2@github.com>
Message-ID: <dQKQDDDsWycA6IzvTZucI_8eMGjwP8Z6yaV3SAGO060=.b98e26e6-d263-4e87-bdee-4314839876d6@github.com>

On Fri, 15 Oct 2021 10:01:19 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> It happens occasionally, as evidenced by JDK-8217298, JDK-8046500 (fixed), JDK-8165665, JDK-8066931, JDK-8057900, JDK-8065559(closed), JDK-8040229, JDK-8065078(fixed), JDK-8068597(fixed), numerous reports on Google (search for "error IP Helper Library"), and an ancient note found in my company's codebase, possibly no longer relevant.

So these Errors do actually happen - thanks for the confirmation, and double thanks for the archeology research. This is very useful to this discussion.

I see that some of the issue you mentioned are suggesting some fixes - like - for instance JDK-8165665. 
It may be that we need to examine each of these on a case-by-case basis. It seems that `GetAdaptersAddresses`, for instance, has more error codes than those we specifically handle - and maybe we need more specific error handling for some of these. 
Maybe throwing `SocketException`, as you suggest, is appropriate for some of these cases. 
Maybe just skipping the interface would be the right choice for others?

If some conditions are not supposed to happen - then I still think that throwing `InternalError` is more appropriate.
I would be afraid that blindly changing all `Error` into `SocketException` would be hiding issues under the carpet, as they would appear as a regular failure...

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From alanb at openjdk.java.net  Fri Oct 15 11:42:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 15 Oct 2021 11:42:52 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <dQKQDDDsWycA6IzvTZucI_8eMGjwP8Z6yaV3SAGO060=.b98e26e6-d263-4e87-bdee-4314839876d6@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <rNxRCZmmS7XwVty00u5YxfvlhR18DGqJsxiz0JeZK1w=.03ce84c3-eaaf-45b3-b3f9-e91db555f68c@github.com>
 <9YongxZqpODL2KYHUfXfkPZwcDrJrjt0IrETgIS5NX4=.e6f0d377-0ce5-436b-adac-a75a9d1d0dd2@github.com>
 <dQKQDDDsWycA6IzvTZucI_8eMGjwP8Z6yaV3SAGO060=.b98e26e6-d263-4e87-bdee-4314839876d6@github.com>
Message-ID: <9Z-u9CrzDX80ibGOpCwlBCKfojkSvqUXGJ7umrhgqtA=.20da7b80-92fd-4e8f-b7f2-5487474adf8c@github.com>

On Fri, 15 Oct 2021 11:22:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It happens occasionally, as evidenced by JDK-8217298, JDK-8046500 (fixed), JDK-8165665, JDK-8066931, JDK-8057900, JDK-8065559(closed), JDK-8040229, JDK-8065078(fixed), JDK-8068597(fixed), numerous reports on Google (search for "error IP Helper Library"), and an ancient note found in my company's codebase, possibly no longer relevant.

There was churn in the Windows APIs and some of these issues may be historical. I think it would be useful if we can find any recent reports of issues and try to identify if they are issues in specific environments/configurations, JDK issues (not handling some cases), or something else. I'd prefer not rush in and change all these exceptions without going through them one by one.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From ewhelan at openjdk.java.net  Fri Oct 15 11:55:22 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Fri, 15 Oct 2021 11:55:22 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v2]
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <RXYx_wOWlftuekKivo2q_8Q8DoU4u0A27ihMutwwOnc=.f2b33abc-85c8-4d70-842e-e9025a3acc1e@github.com>

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:

  Test changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5964/files
  - new: https://git.openjdk.java.net/jdk/pull/5964/files/04a97fe2..a65e493d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=00-01

  Stats: 16 lines in 2 files changed: 10 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5964.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5964/head:pull/5964

PR: https://git.openjdk.java.net/jdk/pull/5964

From duke at openjdk.java.net  Fri Oct 15 12:38:14 2021
From: duke at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 15 Oct 2021 12:38:14 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v2]
In-Reply-To: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
Message-ID: <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>

> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
> JDK-8273142
> JDK-8268464
> JDK-8268133

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5937/files
  - new: https://git.openjdk.java.net/jdk/pull/5937/files/47f7ba24..6d9f17f4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5937&range=00-01

  Stats: 20 lines in 2 files changed: 12 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5937/head:pull/5937

PR: https://git.openjdk.java.net/jdk/pull/5937

From dfuchs at openjdk.java.net  Fri Oct 15 12:59:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 12:59:52 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v2]
In-Reply-To: <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
Message-ID: <SEyCfaQYUFfYJGsn2vGgq_g7SYyrJbE3yvh2wpTqNik=.a3ba5970-05db-4369-9cd9-73c3da9298ea@github.com>

On Fri, 15 Oct 2021 12:38:14 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
>> JDK-8273142
>> JDK-8268464
>> JDK-8268133
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 45:

> 43:         String headerString = "";
> 44:             BufferedReader br = new BufferedReader(new InputStreamReader(this.is));
> 45:             //First line is either request line or status line

Alignment issue? Could you fix the formatting?

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 46:

> 44:             BufferedReader br = new BufferedReader(new InputStreamReader(this.is));
> 45:             //First line is either request line or status line
> 46:             requestOrStatusLine = br.readLine().strip();

Stripping the line could hide errors, as a status/request line is not supposed to start with a whitespace, for instance

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 62:

> 60:                     }
> 61:                     if(!headerMap.containsKey(key.strip())) {
> 62:                         headerMap.put(key.strip(), values);

It may not be a good idea to remove whitespace in a header key as it should not contain any whitespace. Doing so could hide protocol errors.

test/lib/jdk/test/lib/net/HttpHeaderParser.java line 69:

> 67:                 }
> 68:             }
> 69:     }

Still missing code to handle continuation lines.

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

PR: https://git.openjdk.java.net/jdk/pull/5937

From dfuchs at openjdk.java.net  Fri Oct 15 13:11:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 13:11:48 GMT
Subject: RFR: JDK-8061729 : Update java/net tests to eliminate dependency
 on sun.net.www.MessageHeader and some other internal APIs [v2]
In-Reply-To: <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
References: <4tKaoxFush9cULj1K3MZKg-lplg6_ockGrb9x31y598=.b802e871-4c6f-41ea-8763-1ea0e64c87a1@github.com>
 <z0l8anMFT4dN9nQSYhWWn9HFdx5fuNM1v5a2NVxyipc=.3e46cffb-77c6-4537-baa3-dd2bb69781bd@github.com>
Message-ID: <NDae6WRlrhKA6fcUt0WrKIVCsKIH1iSx_Ew9fzhP5bs=.7fd04dc0-e86c-48ae-a898-8c91f906f94f@github.com>

On Fri, 15 Oct 2021 12:38:14 GMT, Mahendra Chhipa <duke at openjdk.java.net> wrote:

>> There are some regression tests depending on sun.net.www.MessageHeader, the internal API dependency should be removed. Some of other internal API dependancies are removed in following issues :
>> JDK-8273142
>> JDK-8268464
>> JDK-8268133
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

It would be good to have a separate test to test the behavior of the new library `HttpHeaderParser` class.
As an example, here [1] is the test we have written for the HttpClient Http1HeaderParser. You will see that it defines a numbers of test cases (response headers) - both positive and negative - and verifies that `sun.net.www.MessageHeader` and `Http1HeaderParser` give the same results in the positive case. It would be good to have something similar for `HttpHeaderParser` as it would give more confidence that the parsing is correct. You would need of course to add in your test new test cases that contain a request line - the Http1HeaderParser only parses status line since it's only used on the client side.

[1] https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/Http1HeaderParserTest.java

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

PR: https://git.openjdk.java.net/jdk/pull/5937

From ewhelan at openjdk.java.net  Fri Oct 15 14:47:18 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Fri, 15 Oct 2021 14:47:18 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:

 - Extracted both connectTimeouts to variables and added copyright header to accessor
 - Removed reflection in favour of injected accessor for KeepAliveCache

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5964/files
  - new: https://git.openjdk.java.net/jdk/pull/5964/files/a65e493d..90ab8587

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=01-02

  Stats: 46 lines in 3 files changed: 35 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5964.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5964/head:pull/5964

PR: https://git.openjdk.java.net/jdk/pull/5964

From ewhelan at openjdk.java.net  Fri Oct 15 14:47:23 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Fri, 15 Oct 2021 14:47:23 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <y6DLuU-SNj6UquprpR8fO8w6TinZIxVhI3sVLlBB0bM=.0f121dd5-f68d-4eac-8538-109232910c9c@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <y6DLuU-SNj6UquprpR8fO8w6TinZIxVhI3sVLlBB0bM=.0f121dd5-f68d-4eac-8538-109232910c9c@github.com>
Message-ID: <ScG_3twZxfsGw9C6ZoptZSx4M79TaYSfF-ot4npPuW0=.78e81851-36ca-4223-b779-7846d6c96e86@github.com>

On Fri, 15 Oct 2021 09:36:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Extracted both connectTimeouts to variables and added copyright header to accessor
>>  - Removed reflection in favour of injected accessor for KeepAliveCache
>
> test/jdk/sun/net/www/http/KeepAliveCache/RequestMethodEquality.java line 32:
> 
>> 30:  * @modules java.base/sun.net.www.http:+open
>> 31:  *          java.base/sun.net.www.protocol.http
>> 32:  * @run testng RequestMethodEquality
> 
> This test modifies some static fields in HttpClient so should run in /othervm

Fixed thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From ewhelan at openjdk.java.net  Fri Oct 15 14:54:49 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Fri, 15 Oct 2021 14:54:49 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <y6DLuU-SNj6UquprpR8fO8w6TinZIxVhI3sVLlBB0bM=.0f121dd5-f68d-4eac-8538-109232910c9c@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <y6DLuU-SNj6UquprpR8fO8w6TinZIxVhI3sVLlBB0bM=.0f121dd5-f68d-4eac-8538-109232910c9c@github.com>
Message-ID: <0-pf65EteraXfglr2lzFSyS9lL1p_HKIosUsSFcKWak=.f7cc693f-dba1-4e5d-a886-c2ac2e95e4c0@github.com>

On Fri, 15 Oct 2021 09:38:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Extracted both connectTimeouts to variables and added copyright header to accessor
>>  - Removed reflection in favour of injected accessor for KeepAliveCache
>
> test/jdk/sun/net/www/http/KeepAliveCache/RequestMethodEquality.java line 95:
> 
>> 93:             // Injecting a mock KeepAliveCache that the HttpClient can use
>> 94:             KeepAliveCache kac = new KeepAliveCache();
>> 95:             kac.put(url, null, freshClient);
> 
> Instead of injecting a new KeepAliveCache you could get the cache already present in HttpClient. One way to do this is to use reflection - another is to inject an accessor class in the sun.net.www.http package. You may not even need to have to create a "fresh" HttpClient - there should be one there corresponding to the connection you already created?

Thanks Daniel! I've used an injected accessor instead like you've suggested.

In regards to creating a "fresh" client. From looking at the implementation of HttpURLConnection, the internal HttpClient (namely, `http`) is not actually initialised during this test. There are various methods in which it gets initialised (`setNewClient`, `proxiedConnect`, `plainConnect0`). With the way I've written this test, none of these methods are called and the internal `http` object remains null throughout.

This is why I am explicitly creating a fresh and cached client. By setting the differing `connectTimeout` values and comparing them, I feel it nicely demonstrates whether or not the same client is being used, while trying to minimise the amount of actual network communication that gets carried out.

I verified the test behaviour before and after the source fix and before, the `cachedClient` was always being initialised with the broken client we manually inserted into the cache

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From coffeys at openjdk.java.net  Fri Oct 15 14:58:51 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Fri, 15 Oct 2021 14:58:51 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
Message-ID: <dQt7Pr2e5u99zwk9bTRm4b-x_icu6nb4iTM0O4KGE-M=.ecc72b2d-aa24-4ab5-b4dd-ee766d954cbb@github.com>

On Fri, 15 Oct 2021 14:47:18 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Extracted both connectTimeouts to variables and added copyright header to accessor
>  - Removed reflection in favour of injected accessor for KeepAliveCache

Marked as reviewed by coffeys (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From michaelm at openjdk.java.net  Fri Oct 15 15:13:48 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 15 Oct 2021 15:13:48 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
Message-ID: <npNjsrw6sVIHQOAEF8k_t0vvoUWdKo2Hr5Z8ECsewXQ=.e28fcd05-f999-459c-a29b-be1e65863d38@github.com>

On Fri, 15 Oct 2021 14:47:18 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Extracted both connectTimeouts to variables and added copyright header to accessor
>  - Removed reflection in favour of injected accessor for KeepAliveCache

Just wondering what actually happens if you encounter this bug? I guess that the post will fail somehow because it has been given a closed connection. If so, would it be possible to write the test to simulate that behavior?

So, say you initially do a HTTP request that succeeds (creating a cached connection). Then, somehow close the connection independent of the keep alive cache. Then attempt the streaming post which will either succeed or fail depending whether the bug is fixed or not.

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From dfuchs at openjdk.java.net  Fri Oct 15 15:28:50 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 15:28:50 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
Message-ID: <f_XioE2M9Wa0KzO-Zp95SultSMdpWXm_DtmZcqKkEAc=.4f68fb5e-3d99-469c-9f66-f6ca5d130873@github.com>

On Fri, 15 Oct 2021 14:47:18 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Extracted both connectTimeouts to variables and added copyright header to accessor
>  - Removed reflection in favour of injected accessor for KeepAliveCache

test/jdk/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java line 96:

> 94:             Field inCache = HttpClient.class.getDeclaredField("inCache");
> 95:             inCache.setAccessible(true);
> 96:             inCache.setBoolean(freshClient, true); // allows the assertion in HttpClient.New to pass

You can use the HttpClientAccess to get and set this field too, since the field is protected in HttpClient.
Just add a method:

public void setInCache(HttpClient client, boolean inCache) { client.inCache = inCache; } 

to HttpClientAccess.

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From dfuchs at openjdk.java.net  Fri Oct 15 15:31:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 15:31:53 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

src/java.base/share/classes/java/net/InetAddress.java line 231:

> 229:  *      The first provider found will be used to instantiate the {@link InetAddressResolver InetAddressResolver}
> 230:  *      by invoking the {@link InetAddressResolverProvider#get(InetAddressResolverProvider.Configuration)}
> 231:  *      method. The instantiated {@code InetAddressResolver} will be installed as the system-wide

Maybe "... method. The **returned** {@code InetAddressResolver} will be installed ..."

src/java.base/share/classes/java/net/InetAddress.java line 486:

> 484:                 return cns;
> 485:             } finally {
> 486:                 bootstrapResolver = null;

This is incorrect. This will set bootstrapResolver to null in the case where you return it at line 468 - which means that a second call will then find it null. I believe you want to set it to null in the finally clause only if you reached line 470. You could achieve this by declaring a local variable - e.g `InetAddressResolver tempResolver = null;` before entering the try-finally then set that variable at line 470 `return tempResolver = bootstrapResolver;` and in finally do `if (tempResolver == null) bootsrapResolver = null;`

To test this you could try to call e.g. `InetAddress.getByName` twice in succession in your test: I believe it will fail with the code as it stands, but will succeed with my proposed changes...

src/java.base/share/classes/java/net/InetAddress.java line 860:

> 858:                 return host;
> 859:             }
> 860:         } catch (RuntimeException | UnknownHostException e) {

This may deserve a comment: resolver.lookUpHostName and InetAddress.getAllbyName0 delegate to the system-wide resolver, which could be custom, and we treat any unexpected RuntimeException thrown by the provider at that point as we would treat an UnknownHostException or an unmatched host name.

src/java.base/share/classes/java/net/InetAddress.java line 1063:

> 1061:         public Stream<InetAddress> lookupAddresses(String host, LookupPolicy policy)
> 1062:                 throws UnknownHostException {
> 1063:             Objects.requireNonNull(host);

Should we also double check that `policy` is not null? Or maybe assert it?

src/java.base/share/classes/java/net/InetAddress.java line 1203:

> 1201:                         + " as hosts file " + hostsFile + " not found ");
> 1202:             }
> 1203:             // Check number of found addresses:

I wonder if the logic here could be simplified by first checking whether only IPv4 addresses are requested, and then if only IPv6 addresses are requested. 

That is - evacuate the simple cases first and then only deal with the more complex case where you have to combine the two lists...

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From duke at openjdk.java.net  Fri Oct 15 16:16:49 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 15 Oct 2021 16:16:49 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <dQKQDDDsWycA6IzvTZucI_8eMGjwP8Z6yaV3SAGO060=.b98e26e6-d263-4e87-bdee-4314839876d6@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <rNxRCZmmS7XwVty00u5YxfvlhR18DGqJsxiz0JeZK1w=.03ce84c3-eaaf-45b3-b3f9-e91db555f68c@github.com>
 <9YongxZqpODL2KYHUfXfkPZwcDrJrjt0IrETgIS5NX4=.e6f0d377-0ce5-436b-adac-a75a9d1d0dd2@github.com>
 <dQKQDDDsWycA6IzvTZucI_8eMGjwP8Z6yaV3SAGO060=.b98e26e6-d263-4e87-bdee-4314839876d6@github.com>
Message-ID: <nnyPMyrD7srCXAzc4zn0WVKNG-Jsddja9u4bMucNzRU=.f932f4e9-5b0f-4dc3-873a-9879256fb343@github.com>

On Fri, 15 Oct 2021 11:22:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> we need to examine each of these on a case-by-case basis

Makes sense. 
1. `MultiByteToWideChar` case: we can change this to `InternalError`, as it's not supposed to happen and apparently not happening
2. [GetIfTable](https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getiftable) case: 
- as JDK-8165665 states, our handling of `ERROR_INSUFFICIENT_BUFFER` leaves something to be desired. We could keep allocating larger buffers a few more times, similar to what we have [here](https://github.com/openjdk/jdk/blob/2322f15d4c5bf1efbdc65eb4ec30662b30bf2d5e/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L92).
- `ERROR_INVALID_PARAMETER` qualifies as `InternalError` to me,
- `ERROR_NOT_SUPPORTED` is either a `SocketException` or an empty list.
- I'm a bit concerned about the "Other" catch-all qualifier on MSDN page, but I'd use `SocketException` for these, possibly with error code / name embedded in exception message. Since they are not explicitly enumerated by Microsoft, I don't see how they could qualify as Java bugs.
3. [GetIpAddrTable](https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getipaddrtable) case: documentation specifies exactly the same list of errors as above, so we could handle them in the same way
4. [GetAdaptersAddresses](https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersaddresses) case (winxp only - is the file really used only on WinXP?):
- `ERROR_ADDRESS_NOT_ASSOCIATED`: either return no data or throw `SocketException` to make it different from `ERROR_NO_DATA`
- `ERROR_BUFFER_OVERFLOW`: our handling looks fine here
- `ERROR_INVALID_PARAMETER`: `InternalError`
- `ERROR_NOT_ENOUGH_MEMORY`: OOME?
- `ERROR_NO_DATA`: return no data
- other: JDK-8217298 reports `ERROR_ACCESS_DENIED` (5), JDK-8231811 reports `ERROR_NOT_FOUND` (1168); I'd use `SocketException` for error codes in this category.

What do you think?

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From dfuchs at openjdk.java.net  Fri Oct 15 17:24:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 15 Oct 2021 17:24:53 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38:

> 36:         String localHostName;
> 37:         try {
> 38:             localHostName = InetAddress.getLocalHost().getHostName();

Try to call InetAddress.getLocalHost().getHostName(); twice here.

test/lib/jdk/test/lib/net/IPSupport.java line 88:

> 86:             } catch (SocketException se2) {
> 87:                 return false;
> 88:             }

The implementation of this method now conflicts with its name. Maybe we should pass a `Class<? extends InetAddress>`  as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Sat Oct 16 08:06:48 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 16 Oct 2021 08:06:48 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <FUxR7zhS-qTYYiWELF2w9FHtbWOxwxHNevm2KZMnvz4=.6724bf52-c058-40c5-940f-6ef745ca5a3b@github.com>

On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

JDK-8217298 hints that one scenario where an exception is thrown is when there are no network adapters configured. I don't know how easy it would be to create that scenario and to see how current JDK releases behave.

MultiByteToWideChar - yes, makes sense.

GetIfTable -yes, I agree this needs to cleaned up. I don't see ERROR_BUFFER_OVERFLOW listed as a possible error.

GetAdaptersAddresses. It would be nice if this NetworkInterface_winXP.c could be removed but it is still used for the  -Djava.net.preferIPv4Stack=true case. A more useful exercise may be to see if we could move to one implementation that works with preferIPv4Stack set to true or false.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From msheppar at openjdk.java.net  Sat Oct 16 10:51:48 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sat, 16 Oct 2021 10:51:48 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

What?s in a name?
I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space
one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup
to resolve an IP address to a hostname (or names) associated with it.

For the method names lookupHostname, and lookupAddresses,
and the semantics conveyed in those names, 
I would expect lookupHostname to resolve a hostname, that is, take a hostname as parameter and
the return value the addresses, while lookupAddresses I would expect to resolve an address to its hostname,
that is, take an address and return a hostname.
However, the current pair of methods names convey the opposite, lookupHostname resolves an address and
lookupAddresses resolves a hostname.

I would proffer a method name change to use lookup and reverseLookup
OR to use resolvesHostname and resolveAddress, to resolve a hostname and address
respectively.

Thus, lookupHostname should be renamed to reverseLookup and
lookupAddresses to lookup OR
lookupHostname renamed to resolveAddress and lookupAddresses renamed to resolveHostname.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From msheppar at openjdk.java.net  Sat Oct 16 12:33:52 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sat, 16 Oct 2021 12:33:52 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
Message-ID: <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>

On Tue, 12 Oct 2021 15:43:24 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add @since tags to new API classes
>  - Add checks and test for empty stream resolver results

Refactor remove Configuration and simplify interface:

In the InetAddressResolver a Configuration abstraction is defined, and this is supplied to
a get method of the InetAddressResolverProvider.

The objective is to ?inject? some platform configuration into an InetAddressResolver. This
consistents of two pieces of platform configuration detail, a builtin resolver reference and the hostname.
Why not provide them as parameters to the provider get method and dispense with the Configuration
abstraction? Thus simplifying the interface. The hostname is being supplied by the getLocalHostName
of an InetAddressImpl. This is essentially a wrapper to the library call gethostname. This
could be provided as a static method in InetAddressImpl, called once during loadResolver to 
provide the hostname parameter String. The hostname is a static piece of system configuration, which
requires a system restart if it were to be changed - so need to provide a lambda.

So Suggestion is refector remove Configuration to simplify the interface and provide the
BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Sun Oct 17 15:58:54 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Sun, 17 Oct 2021 15:58:54 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
Message-ID: <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>

On Sat, 16 Oct 2021 12:30:44 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method

During work on this JEP we've examined the approach suggested above, and there are few issues with it:
- `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items.
- local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`.

It's been also discussed in the CSR comments [here](https://bugs.openjdk.java.net/browse/JDK-8274558)

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Sun Oct 17 16:36:51 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Sun, 17 Oct 2021 16:36:51 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
Message-ID: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>

On Sat, 16 Oct 2021 10:48:32 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it.

I'm not sure that I see an ambiguity here:
Interface has two methods, both are for lookup operations. That is why `lookup` word is used in both names. Then we put a description of a returned result after operation name: `Addresses` and `HostName` are the results. In cases when we want to highlight a parameter type in a method name we can use ?by?/?with? prepositions: for instance, `InetAddress.getByName` `InetAddress.getByAddress` `ScheduledExecutorService.scheduleWithFixedDelay`.

We can try and apply this approach to the description of DNS operations above:
> lookup to resolve a hostname to its associated addresses 

operation: `lookup` result: `addresses` -> methodName: `lookupAddresses`

> reverse lookup to resolve an IP address to a hostname

operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName`

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Sun Oct 17 18:35:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 17 Oct 2021 18:35:57 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
 <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
Message-ID: <qqJiU7O4rdC9vMWsbNXI5GTsa8BOgKvAxlJ_OS3tD9Y=.5f235e7a-4736-458a-b0a8-5cabcd7b7577@github.com>

On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> * `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items.
> * local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`.

Right, I think we've ended up with a good model here that supports the common case, stacking, and can be extended in the future to add new configuration if required. Also if good use-cases come up when Configuration can be changed to be non-sealed.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From msheppar at openjdk.java.net  Sun Oct 17 21:06:51 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sun, 17 Oct 2021 21:06:51 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
 <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>
Message-ID: <ChUmaIjYE61OE80QGJyqes8hnzErFw9IlgrSUlRtnNo=.a34cd6da-cc08-4e84-8fa2-c8f93f258268@github.com>

On Sun, 17 Oct 2021 16:33:57 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> > What?s in a name? I find the method names of the InetAddressResolver interface a bit ambiguous. Typically in this DNS problem space one speaks of lookup to resolve a hostname to its associated addresses and reverse lookup to resolve an IP address to a hostname (or names) associated with it.
> 
> I'm not sure that I see an ambiguity here: Interface has two methods, both are for lookup operations. That is why `lookup` word is used in both names. Then we put a description of a returned result after operation name: `Addresses` and `HostName` are the results. In cases when we want to highlight a parameter type in a method name we can use ?by?/?with? prepositions: for instance, `InetAddress.getByName` `InetAddress.getByAddress` `ScheduledExecutorService.scheduleWithFixedDelay`.
> 
> We can try and apply this approach to the description of DNS operations above:
> 
> > lookup to resolve a hostname to its associated addresses
> 
> operation: `lookup` result: `addresses` -> methodName: `lookupAddresses`
> 
> > reverse lookup to resolve an IP address to a hostname
> 
> operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName`

Yes, ambiguity wasn?t quite the word I was looking for. Maybe contradictory or oxymoron might do !!
Let me try and clarify the rational behind the suggestion.

To re-iterate, the parlance of the DNS domain in context of address resolution is lookup for hostname to IP address resolution and reverse lookup for address to hostname mapping. For me, the natural verb to method translation is lookup and **reverseLookup OR resolveHostname and resolveAddress. The latter names are pretty definitive and unambiguous. It clear and obvious without the need to pursue the full signature of the method, what the semantics of the methods should be.

At the java InetAddress API level there is getByName(String host) and getByAddress(byte[] addr).
At the native OS level there is gethostbyname, gethostbyaddr and the evolved api getnameinfo and getaddrinfo.

getByName requires a hostname lookup and getByAdress requires (eventually - I know the docs says there?s no reverse lookup) an address reverse lookup. Thus, a logical mapping is getByName ?> lookupHostname, and getByAddr ?> lookupAddress, but the opposite will occur getByName --> lookupAddresses and getByAddress --> lookupHostname.  Therfore  I proffer maps neatly to rename methods to resolveHostname and resolveAddress such that the mapping are getByName --> resolveHostname and getByAddress --> resolveAddress.

I will concede that it can be reasonable argued that the native library functions getnameinfo and getaddrinfo may better abstract to lookupHostname and lookupAddresses respectively. But, I have always found these two library calls a bit contorted and the legacy gethostbyname and gethostbyaddress were more logical.

In you proposition above:

> operation: `lookup` result: `addresses` -> methodName: `lookupAddresses`

> operation: `lookup` (we've dropped reverse word here) result: `hostname` -> methodName: `lookupHostName`

You are generating the name from the result of the action. I?m arguing that it should be based on the operation on the subject i.e. the parameter being passed.
If this was hashmap lookup, then it is an operation of mapping hostname to addresses mapHostnameToAddresses, i.e. looking up a hostname, and mapping an address to a hostname mapAddressToHostname i.e. looking up an address.

Of course, it is possible to just **overload**  a lookup method, one taking Sting and t?other taking byte adder in the method?s parameters, respectively. Then, you don?t have to concede too much in this argument.
But, for me as an ordinary developer, resolveAddress and resolveHostname are crystal clear and unambiguous.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From msheppar at openjdk.java.net  Sun Oct 17 21:41:49 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sun, 17 Oct 2021 21:41:49 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
 <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
Message-ID: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com>

On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> > So Suggestion is refector remove Configuration to simplify the interface and provide the BULITIN_RESOLVER and hostname as parameters to the InetAddressResolverProvider::get method
> 
> During work on this JEP we've examined the approach suggested above, and there are few issues with it:
> 
>     * `InetAddressResolverProvider.Configuration` interface API might evolve, e.g. there might be a need to pass additional configuration items.
> 
>     * local hostname is a dynamic information, therefore it cannot be passed as string parameter to `InetAddressResolverProvider::get`.
> 
> 
> It's been also discussed in the CSR comments [here](https://bugs.openjdk.java.net/browse/JDK-8274558)

OK grand ... I didn't see the CSR discussion :-(

WRT hostname being dynamic and requires a lambda ... is it really dynamic?
 I know it can be changed, but IIRC most (unix and windows) if not all systems require a restart for such a change change to take effect, and usually requires a dns cache flush also, in which case an application will be restarting also.

 In the case of working over VPN, VPN software usually changes the hostname dynamically, but that name change is only valid for the duration of the VPN session, and when you exit the VPN, it reverts back to the original hostname. In such cases an application will need to be restarted. There's no seemless working from VPN to non VPN.

I think that a hostname is constant while a host is up, but  it can be changed, and when changed a host restart is required. I don't think it is quite as dynamic as has been suggested, but I open to correction.

 It is something that can be investigated.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From myano at openjdk.java.net  Mon Oct 18 09:57:53 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Mon, 18 Oct 2021 09:57:53 GMT
Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some
 process is holding the file
In-Reply-To: <xkcgN5DpOSCTgGmCabH18sC_rb-TIBl8ne5X0_b5od4=.6fb5d572-36dd-4533-9e5e-41fe435fb33b@github.com>
References: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
 <rQGOuFbIBvsxF3B1KaJYdUv9k_771Eyd5dcjNwC4n-4=.399f8d64-0014-4ca5-98b1-1bec1e7c9b37@github.com>
 <xkcgN5DpOSCTgGmCabH18sC_rb-TIBl8ne5X0_b5od4=.6fb5d572-36dd-4533-9e5e-41fe435fb33b@github.com>
Message-ID: <jeJnibk0VJXwnfaqcGPRN097R57jc7JH5lef5AATkbM=.c51dc2b1-4a39-4c0f-92b5-6180fd3db144@github.com>

On Mon, 27 Sep 2021 08:04:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it?
>> 
>> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS.
>
>> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it?
>> 
>> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS.
> 
> I think we need to find out if the issue you are working around is a bug/issue with the virus checker or that Microsoft recommends that all applications should put a retry to work around these issues. As regards the patch then it is incomplete. If we are forced to put a workaround into the JDK code then I think it will have to do everywhere, not just for zip/JAR files.

@AlanBateman Could you reply to the above comment?

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

PR: https://git.openjdk.java.net/jdk/pull/5460

From alanb at openjdk.java.net  Mon Oct 18 10:24:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 18 Oct 2021 10:24:59 GMT
Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some
 process is holding the file
In-Reply-To: <xkcgN5DpOSCTgGmCabH18sC_rb-TIBl8ne5X0_b5od4=.6fb5d572-36dd-4533-9e5e-41fe435fb33b@github.com>
References: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
 <rQGOuFbIBvsxF3B1KaJYdUv9k_771Eyd5dcjNwC4n-4=.399f8d64-0014-4ca5-98b1-1bec1e7c9b37@github.com>
 <xkcgN5DpOSCTgGmCabH18sC_rb-TIBl8ne5X0_b5od4=.6fb5d572-36dd-4533-9e5e-41fe435fb33b@github.com>
Message-ID: <NSMjNiqpRVpFwkw9fDcdIjZPwqXtlMCkRnKJOrWe3Qo=.56ad6097-5139-41d1-a333-c521c1f1ceec@github.com>

On Mon, 27 Sep 2021 08:04:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it?
>> 
>> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS.
>
>> It?s a good idea to ask the Microsoft folks about that, but I don't know the way to ask. Could you tell me how to do it?
>> 
>> As you say, CreateFile function is used in other parts of the JDK, but it have a significant impact to fix all of that. Therefore, I fixed the problem about opening zip files and jar files which is reported in the JBS.
> 
> I think we need to find out if the issue you are working around is a bug/issue with the virus checker or that Microsoft recommends that all applications should put a retry to work around these issues. As regards the patch then it is incomplete. If we are forced to put a workaround into the JDK code then I think it will have to do everywhere, not just for zip/JAR files.

> @AlanBateman Could you reply to the above comment?

I view this issue as something for the anti-virus vendor to fix. It would be very disappointing to force the JDK to put in a workaround for this. A workaround would be very intrusive and require changes in many areas of the JDK.

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

PR: https://git.openjdk.java.net/jdk/pull/5460

From michaelm at openjdk.java.net  Mon Oct 18 11:43:52 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 18 Oct 2021 11:43:52 GMT
Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9]
In-Reply-To: <tSHlnK8VlshJiCHMBx0bff2c3k3hs6TjWA6U7LM8ouk=.a50bc1be-879d-426b-9ee6-a3f2ffb85d0f@github.com>
References: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
 <tSHlnK8VlshJiCHMBx0bff2c3k3hs6TjWA6U7LM8ouk=.a50bc1be-879d-426b-9ee6-a3f2ffb85d0f@github.com>
Message-ID: <iaIc_ErAj8PZ6jakNwNsnFrMG7PC1MAFtSFxf5TLpoU=.ea3d2a7f-302b-4e3f-8ff9-a47f9cd87f81@github.com>

On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Minor rewording of bind address output
>  - Merge branch 'master' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - update output for all interfaces
>  - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces
>  - Merge branch 'master' into simpleserver
>  - change default bind address from anylocal to loopback
>  - address PR comments
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0

test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java line 200:

> 198:      */
> 199: //    @Test(dataProvider = "commonExtensions")
> 200:     public static void testCommonExtensions(String extension) {

Is this test and the one below supposed to be commented out?

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

PR: https://git.openjdk.java.net/jdk/pull/5505

From jboes at openjdk.java.net  Mon Oct 18 12:21:59 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 18 Oct 2021 12:21:59 GMT
Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9]
In-Reply-To: <iaIc_ErAj8PZ6jakNwNsnFrMG7PC1MAFtSFxf5TLpoU=.ea3d2a7f-302b-4e3f-8ff9-a47f9cd87f81@github.com>
References: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
 <tSHlnK8VlshJiCHMBx0bff2c3k3hs6TjWA6U7LM8ouk=.a50bc1be-879d-426b-9ee6-a3f2ffb85d0f@github.com>
 <iaIc_ErAj8PZ6jakNwNsnFrMG7PC1MAFtSFxf5TLpoU=.ea3d2a7f-302b-4e3f-8ff9-a47f9cd87f81@github.com>
Message-ID: <Sebo3_9IAq_uU9-dsU8CfRhC7QeCxEotodDZxY_5gTU=.ce5c5df1-a93f-41ac-82f2-2ca3fbc04b27@github.com>

On Mon, 18 Oct 2021 11:38:22 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Minor rewording of bind address output
>>  - Merge branch 'master' into simpleserver
>>  - Merge branch 'master' into simpleserver
>>  - update output for all interfaces
>>  - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces
>>  - Merge branch 'master' into simpleserver
>>  - change default bind address from anylocal to loopback
>>  - address PR comments
>>  - Merge branch 'master' into simpleserver
>>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0
>
> test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java line 200:
> 
>> 198:      */
>> 199: //    @Test(dataProvider = "commonExtensions")
>> 200:     public static void testCommonExtensions(String extension) {
> 
> Is this test and the one below supposed to be commented out?

Yes, `testCommonExtensions` is a manual test to find common mime types that are currently not supported, `printUnsupportedFileExtensions` prints the list of types found.

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

PR: https://git.openjdk.java.net/jdk/pull/5505

From michaelm at openjdk.java.net  Mon Oct 18 13:58:55 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 18 Oct 2021 13:58:55 GMT
Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9]
In-Reply-To: <tSHlnK8VlshJiCHMBx0bff2c3k3hs6TjWA6U7LM8ouk=.a50bc1be-879d-426b-9ee6-a3f2ffb85d0f@github.com>
References: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
 <tSHlnK8VlshJiCHMBx0bff2c3k3hs6TjWA6U7LM8ouk=.a50bc1be-879d-426b-9ee6-a3f2ffb85d0f@github.com>
Message-ID: <2Fk3re4SLz7A9vMEvJItkQfB7BCLhzAuQRoD5KXfUoc=.66a62f2d-36e0-4d53-bbb0-cca2f9cd110e@github.com>

On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Minor rewording of bind address output
>  - Merge branch 'master' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - update output for all interfaces
>  - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces
>  - Merge branch 'master' into simpleserver
>  - change default bind address from anylocal to loopback
>  - address PR comments
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0

Marked as reviewed by michaelm (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5505

From dfuchs at openjdk.java.net  Mon Oct 18 16:01:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 18 Oct 2021 16:01:52 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v2]
In-Reply-To: <gyOXBEpsl7evfj-qveYqxid_BjEjr1D_eGjEFB0HWtw=.a0cef6f6-75a2-44a5-9dbd-c794e898fb96@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <gyOXBEpsl7evfj-qveYqxid_BjEjr1D_eGjEFB0HWtw=.a0cef6f6-75a2-44a5-9dbd-c794e898fb96@github.com>
Message-ID: <7Lxt6qESYcDyWREDHB-7frSzeNTdM5sj-wSPpJI2JTk=.fa632ca6-06cd-4134-888e-8d748d0367ce@github.com>

On Tue, 12 Oct 2021 15:41:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
>> 
>> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
>> 
>> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
>  - Merge remote-tracking branch 'origin/master' into JDK-8260428
>  - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From duke at openjdk.java.net  Mon Oct 18 16:03:35 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Oct 2021 16:03:35 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v2]
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <VHvS1_bR9MOF2Mk1YwtUdL9NEDBWDXv9BJPL5gp8_is=.5e9f9d1f-de56-4251-84d2-106508572049@github.com>

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Throw more specific exceptions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5956/files
  - new: https://git.openjdk.java.net/jdk/pull/5956/files/2322f15d..79c74b81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=00-01

  Stats: 66 lines in 2 files changed: 16 ins; 10 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5956.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5956/head:pull/5956

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Mon Oct 18 16:17:48 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Oct 2021 16:17:48 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v2]
In-Reply-To: <VHvS1_bR9MOF2Mk1YwtUdL9NEDBWDXv9BJPL5gp8_is=.5e9f9d1f-de56-4251-84d2-106508572049@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <VHvS1_bR9MOF2Mk1YwtUdL9NEDBWDXv9BJPL5gp8_is=.5e9f9d1f-de56-4251-84d2-106508572049@github.com>
Message-ID: <9-tWCObM-lf2NME7qVKcX7NbJgFJ5Bj-XS031UGm7ZM=.7732069d-aad4-4c98-8e33-4340e1028b59@github.com>

On Mon, 18 Oct 2021 16:03:35 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw more specific exceptions

Updated the PR with more specific exception types. I'm still doing some printf-based testing / debugging. Observations so far:
- My assumption that WinXP file contained some ancient code was incorrect. The WinXP functions are used when NOT in `java.net.preferIPv4Stack` mode, and are the preferred / more modern way. Cost me a few sanity points when I first realized.
- `GetAdaptersAddresses` failures are generating correct exception types, but error message generated by `JNU_ThrowByNameWithMessageAndLastError` is not what I expected. Example:

java.net.SocketException: An address has not yet been associated with the network endpoint (IP Helper Library GetAdaptersAddresses function failed)

I expected the Windows error code to appear after my message, not before.
- `GetIpAddrTable` failures are working correctly in `java.net.preferIPv4Stack` mode; in default mode they crash the JVM (access violation in net.dll). Apparently some of the callers attempt to access result pointer even when `lookupIPAddrTable` fails.

I'll update when I know more.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Mon Oct 18 16:57:10 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Oct 2021 16:57:10 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Fix crash on GetIpAddrTable error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5956/files
  - new: https://git.openjdk.java.net/jdk/pull/5956/files/79c74b81..a6c89e23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Mon Oct 18 17:02:55 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Oct 2021 17:02:55 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
Message-ID: <hWMO15mqV5TmTUcM4A6nTTooeJOFQFW5PZTr1U8paIk=.133b7efa-108c-45a4-92e4-b9db431b5f85@github.com>

On Mon, 18 Oct 2021 16:57:10 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix crash on GetIpAddrTable error

The crash reason was a bit more mundane. We assigned the (int) result of `lookupIPAddrTable` to a (DWORD / unsigned int) variable, then checked if the variable value is negative (which it cannot be).
Wonder why the compiler didn't warn about this.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Mon Oct 18 19:10:50 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Oct 2021 19:10:50 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
Message-ID: <b8KES1Bl42D9hORPt-AmKv0p3BywmfTscxgMIqFVCik=.839129ff-5a80-4efd-b1c9-753c118994a6@github.com>

On Mon, 18 Oct 2021 16:57:10 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix crash on GetIpAddrTable error

`GetIfTable` failures are handled somewhat correctly; in IPv4 mode the exception is propagated as expected.

In default mode the exception is swallowed [here](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L250), and then SocketException ("No network interfaces configured") is thrown in Java code.
The code that swallows exception appears incorrect; when exception is swallowed, `netifPP` is null, `last` is null and the code that could [add an IPv6 interface](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L383) would crash.

Should I clean that up here or leave it for future PRs?

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Mon Oct 18 19:33:02 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 18 Oct 2021 19:33:02 GMT
Subject: RFR: 8262442 (windows) use all proxy configuration sources when
 java.net.useSystemProxies=true
Message-ID: <LYXzqyYxDU2OLZ1YyyvWnvsH2OJDkRqNv4Pp2UPQgr4=.37b73580-1c60-4177-b89f-664d6efe6436@github.com>

With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available.
If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available)
If both the above options fail, selector uses the configured proxy.

Verified on Windows 10 that:
- when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used
- when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method
- when `lpszAutoConfigUrl` is set and usable, the proxy returned is used
- when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method
- when `lpszProxy` is configured, that proxy is used
- otherwise selector uses direct connection

The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate.

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

Commit messages:
 - Use all proxy configs

Changes: https://git.openjdk.java.net/jdk/pull/5995/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5995&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262442
  Stats: 14 lines in 1 file changed: 7 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5995.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5995/head:pull/5995

PR: https://git.openjdk.java.net/jdk/pull/5995

From alanb at openjdk.java.net  Tue Oct 19 06:45:51 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Oct 2021 06:45:51 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
Message-ID: <rb8AN-Xqs22KCAVr2OWr-KYKtz7NB3-H232L1LC9Eho=.5a73dcb4-8b8e-4c38-bf23-6788faf25a32@github.com>

On Mon, 18 Oct 2021 16:57:10 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix crash on GetIpAddrTable error

src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 123:

> 121:                 // not an error
> 122:                 *adapters = NULL;
> 123:                 return ERROR_SUCCESS;

Mapping ERROR_NO_DATA to ERROR_SUCCESS is probably correct here. Could this explain bug reports that seem to be from configurations with no IP addresses plumbed?

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From alanb at openjdk.java.net  Tue Oct 19 06:50:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Oct 2021 06:50:52 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
Message-ID: <0fqm4XErugdpmK2lfPZVtZy7lPSyL0cEPtRs6AlM2gY=.c72bcfab-7a00-4d90-9ebf-31d46ef35775@github.com>

On Mon, 18 Oct 2021 16:57:10 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix crash on GetIpAddrTable error

I think you've got this to a good place. It would be helpful if you could trim down some of the really long lines to keep to consistent with the existing code if possible. It's clear that there is a lot of cleanup needed in this area but that can be done in future PRs as needed.

src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 232:

> 230: int getAllInterfacesAndAddresses (JNIEnv *env, netif **netifPP)
> 231: {
> 232:     int ret, flags;

This looks right but I can't relate this to your comment about the crash.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Tue Oct 19 07:26:57 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Oct 2021 07:26:57 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <0fqm4XErugdpmK2lfPZVtZy7lPSyL0cEPtRs6AlM2gY=.c72bcfab-7a00-4d90-9ebf-31d46ef35775@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
 <0fqm4XErugdpmK2lfPZVtZy7lPSyL0cEPtRs6AlM2gY=.c72bcfab-7a00-4d90-9ebf-31d46ef35775@github.com>
Message-ID: <D-qoC8_r3oHa_3xeFVp9Umy9sEvK441ldPHs7q5MLrk=.06507872-61db-4b38-8db3-04c8bc254942@github.com>

On Tue, 19 Oct 2021 06:45:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix crash on GetIpAddrTable error
>
> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 232:
> 
>> 230: int getAllInterfacesAndAddresses (JNIEnv *env, netif **netifPP)
>> 231: {
>> 232:     int ret, flags;
> 
> This looks right but I can't relate this to your comment about the crash.

let me try to explain this clang-style:
- `tableP` contains [random garbage](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L233)
- [lookupIPAddrTable](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L266) returns error, does not touch `tableP`
- `ret` is unsigned, so [this is never true](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L267)
- uninitialized `tableP` is passed to [enumAddresses_win_ipaddrtable](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L272)
- `enumAddresses_win_ipaddrtable` [dereferences](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface.c#L440) `tableP` and crashes

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Tue Oct 19 07:56:53 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Oct 2021 07:56:53 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <rb8AN-Xqs22KCAVr2OWr-KYKtz7NB3-H232L1LC9Eho=.5a73dcb4-8b8e-4c38-bf23-6788faf25a32@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
 <rb8AN-Xqs22KCAVr2OWr-KYKtz7NB3-H232L1LC9Eho=.5a73dcb4-8b8e-4c38-bf23-6788faf25a32@github.com>
Message-ID: <Qss6jLGKUutvgp00La4Yzvu2MPx-XQ0vnaqOcejU0D8=.fa96d719-9e29-4d0c-83d0-29aeb62a5c64@github.com>

On Tue, 19 Oct 2021 06:42:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix crash on GetIpAddrTable error
>
> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 123:
> 
>> 121:                 // not an error
>> 122:                 *adapters = NULL;
>> 123:                 return ERROR_SUCCESS;
> 
> Mapping ERROR_NO_DATA to ERROR_SUCCESS is probably correct here. Could this explain bug reports that seem to be from configurations with no IP addresses plumbed?

I suppose it could. But in order to get ERROR_NO_DATA here one would need to disable loopback interface. I couldn't find how to do that.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Tue Oct 19 09:32:19 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 19 Oct 2021 09:32:19 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Adapt line length to 80 column display

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5956/files
  - new: https://git.openjdk.java.net/jdk/pull/5956/files/a6c89e23..9e9ea0a2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5956&range=02-03

  Stats: 32 lines in 2 files changed: 17 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5956.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5956/head:pull/5956

PR: https://git.openjdk.java.net/jdk/pull/5956

From jboes at openjdk.java.net  Tue Oct 19 10:22:00 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 19 Oct 2021 10:22:00 GMT
Subject: Integrated: 8245095: Implementation of JEP 408: Simple Web Server
In-Reply-To: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
References: <ziyoJKP08co1jAqFytSiBKuKv6CeEXajLZNrYlp1lzQ=.aeb8e3ea-09f6-4efb-92f4-8b4b7026ba0d@github.com>
Message-ID: <ZutIaoVXYltJbuzXrgDd20CHQ6rSmC3xtyIwpfg1Q44=.0420e618-15cc-4884-b1e9-040a615951fe@github.com>

On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes <jboes at openjdk.org> wrote:

> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`.
> 
> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK.
> 
> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging.
> 
> Additionally, a small API is introduced for programmatic creation and customization.
> 
> Testing: tier1-3.

This pull request has now been integrated.

Changeset: 9d191fce
Author:    Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde
Stats:     7181 lines in 42 files changed: 7146 ins; 15 del; 20 mod

8245095: Implementation of JEP 408: Simple Web Server

Co-authored-by: Julia Boes <jboes at openjdk.org>
Co-authored-by: Chris Hegarty <chegar at openjdk.org>
Co-authored-by: Michael McMahon <michaelm at openjdk.org>
Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Ivan ?ipka <isipka at openjdk.org>
Reviewed-by: ihse, jlaskey, michaelm, chegar, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5505

From alanb at openjdk.java.net  Tue Oct 19 10:29:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 19 Oct 2021 10:29:52 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v3]
In-Reply-To: <Qss6jLGKUutvgp00La4Yzvu2MPx-XQ0vnaqOcejU0D8=.fa96d719-9e29-4d0c-83d0-29aeb62a5c64@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <AKCf5bp9h5uUb_A9LhXGHnAK5uKa8FXHipDOfwyp33E=.7a2d36da-dd40-45cf-8d0a-b7d24301e65e@github.com>
 <rb8AN-Xqs22KCAVr2OWr-KYKtz7NB3-H232L1LC9Eho=.5a73dcb4-8b8e-4c38-bf23-6788faf25a32@github.com>
 <Qss6jLGKUutvgp00La4Yzvu2MPx-XQ0vnaqOcejU0D8=.fa96d719-9e29-4d0c-83d0-29aeb62a5c64@github.com>
Message-ID: <ug6tfKH-CjJi8R6V93KQUBS-oZ-9dTdEucu8OaoK-_A=.84917bf2-21c3-4125-a06f-968a25c2b031@github.com>

On Tue, 19 Oct 2021 07:53:47 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 123:
>> 
>>> 121:                 // not an error
>>> 122:                 *adapters = NULL;
>>> 123:                 return ERROR_SUCCESS;
>> 
>> Mapping ERROR_NO_DATA to ERROR_SUCCESS is probably correct here. Could this explain bug reports that seem to be from configurations with no IP addresses plumbed?
>
> I suppose it could. But in order to get ERROR_NO_DATA here one would need to disable loopback interface. I couldn't find how to do that.

There has been one or two reports from configurations that appear to have no interface or no IP addresses. I don't think we've been able to create those configurations to duplicate. In any case, treat NO_DATA as SUCCESS seems correct here.

>> src/java.base/windows/native/libnet/NetworkInterface_winXP.c line 232:
>> 
>>> 230: int getAllInterfacesAndAddresses (JNIEnv *env, netif **netifPP)
>>> 231: {
>>> 232:     int ret, flags;
>> 
>> This looks right but I can't relate this to your comment about the crash.
>
> let me try to explain this clang-style:
> - `tableP` contains [random garbage](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L233)
> - [lookupIPAddrTable](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L266) returns error, does not touch `tableP`
> - `ret` is unsigned, so [this is never true](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L267)
> - uninitialized `tableP` is passed to [enumAddresses_win_ipaddrtable](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L272)
> - `enumAddresses_win_ipaddrtable` [dereferences](https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface.c#L440) `tableP` and crashes

Thanks for this, I hadn't spotted the broken code that tests if loopupIPAddrTable  fails.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From dfuchs at openjdk.java.net  Tue Oct 19 10:46:56 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 19 Oct 2021 10:46:56 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
Message-ID: <kX7zBzKnXtGOiVAU0gIk8vCMEPu1ksaLBqooPoqkZbs=.d3158577-cd51-4d60-adfd-181b271935ba@github.com>

On Tue, 19 Oct 2021 09:32:19 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt line length to 80 column display

Hi Daniel, thanks for persisting with this. I had a look at your changes and I believe you have hit the right balance. I also like the fact plain `java.lang.Error` has been transformed into `java.lang.InternalError`. Also thanks for sanitizing the error code checks to match what `GetIfTable` and `GetAdaptersAddresses` are documented to return. I believe we are ending in a much better place. Please give me some time to import your patch and give it a round of testing.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From aefimov at openjdk.java.net  Tue Oct 19 13:28:26 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:28:26 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v4]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <oQyboiYcm8oe4KHke029DGp4VCYD3ac00ymAECoW3aE=.6e97bcc6-444f-41ae-9f34-cdb60f0b3b03@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with four additional commits since the last revision:

 - Remove no longer used import from IPSupport
 - Rename IPSupport.hasAddress and update it to use SocketChannel.open
 - Address review comments: javadoc + code cleanup
 - Address resolver bootstraping issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/d302a49a..ac0d2184

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=02-03

  Stats: 245 lines in 5 files changed: 180 ins; 35 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 19 13:28:36 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:28:36 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <-JuSgJLSkme6YraHYehOdUah6GSER-EUo3Mq4TVjXKU=.f700cbe6-021a-43c4-a5ae-c0dc7b42d313@github.com>
Message-ID: <Jqvh-luZdcfIXQOjD6xTwmC5XQpHY0MbwSfzjO_HVR4=.92574438-a305-4835-9222-f42397b43aa2@github.com>

On Fri, 15 Oct 2021 14:25:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @since tags to new API classes
>>  - Add checks and test for empty stream resolver results
>
> src/java.base/share/classes/java/net/InetAddress.java line 231:
> 
>> 229:  *      The first provider found will be used to instantiate the {@link InetAddressResolver InetAddressResolver}
>> 230:  *      by invoking the {@link InetAddressResolverProvider#get(InetAddressResolverProvider.Configuration)}
>> 231:  *      method. The instantiated {@code InetAddressResolver} will be installed as the system-wide
> 
> Maybe "... method. The **returned** {@code InetAddressResolver} will be installed ..."

Changed as suggested in 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe.

> src/java.base/share/classes/java/net/InetAddress.java line 486:
> 
>> 484:                 return cns;
>> 485:             } finally {
>> 486:                 bootstrapResolver = null;
> 
> This is incorrect. This will set bootstrapResolver to null in the case where you return it at line 468 - which means that a second call will then find it null. I believe you want to set it to null in the finally clause only if you reached line 470. You could achieve this by declaring a local variable - e.g `InetAddressResolver tempResolver = null;` before entering the try-finally then set that variable at line 470 `return tempResolver = bootstrapResolver;` and in finally do `if (tempResolver == null) bootsrapResolver = null;`
> 
> To test this you could try to call e.g. `InetAddress.getByName` twice in succession in your test: I believe it will fail with the code as it stands, but will succeed with my proposed changes...

Good catch, thank you Daniel. Added a test for that and fixed it in cd19ecd63838d3c2b713ed66d41107fe01a2d3e6. Now the `bootstrapResolver` field is set back to `null` in finally block only if a call to `InetAddress.resolver()` entered a resolver initialization part.

> src/java.base/share/classes/java/net/InetAddress.java line 860:
> 
>> 858:                 return host;
>> 859:             }
>> 860:         } catch (RuntimeException | UnknownHostException e) {
> 
> This may deserve a comment: resolver.lookUpHostName and InetAddress.getAllbyName0 delegate to the system-wide resolver, which could be custom, and we treat any unexpected RuntimeException thrown by the provider at that point as we would treat an UnknownHostException or an unmatched host name.

Agree - comment added as part of 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe.

> src/java.base/share/classes/java/net/InetAddress.java line 1063:
> 
>> 1061:         public Stream<InetAddress> lookupAddresses(String host, LookupPolicy policy)
>> 1062:                 throws UnknownHostException {
>> 1063:             Objects.requireNonNull(host);
> 
> Should we also double check that `policy` is not null? Or maybe assert it?

Yes, we should since custom resolvers might call the built-in one with `null` - added non-null check in 648e65b .

> src/java.base/share/classes/java/net/InetAddress.java line 1203:
> 
>> 1201:                         + " as hosts file " + hostsFile + " not found ");
>> 1202:             }
>> 1203:             // Check number of found addresses:
> 
> I wonder if the logic here could be simplified by first checking whether only IPv4 addresses are requested, and then if only IPv6 addresses are requested. 
> 
> That is - evacuate the simple cases first and then only deal with the more complex case where you have to combine the two lists...

Tried to simplify it in 648e65b8e6ae9687f7164ea3e81c51ab2b5e2dfe

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 19 13:31:09 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:31:09 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
Message-ID: <peA62oveRsjHAOX2g6suheZBJUGhSvtCZBvaBI86tJ0=.b03e4ae1-497e-472a-8e42-1dca6f171aca@github.com>

On Fri, 15 Oct 2021 17:09:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @since tags to new API classes
>>  - Add checks and test for empty stream resolver results
>
> test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java line 38:
> 
>> 36:         String localHostName;
>> 37:         try {
>> 38:             localHostName = InetAddress.getLocalHost().getHostName();
> 
> Try to call InetAddress.getLocalHost().getHostName(); twice here.

New `BootstrapResolverUsageTest` test is added to trigger the bootstrap resolver problem. `InetAddress.getByName` calls with unique names are used instead of `InetAddress.getLocalHost()` to avoid caching of LHN resolution results. Added in cd19ecd63838d3c2b713ed66d41107fe01a2d3e6.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 19 13:34:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:34:50 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <kPmVQm1zPuftiOVPPEEOu5I5rvUS8B0XB5rT44lBAuc=.309a401a-035f-43e5-961b-2daf9dbee2c9@github.com>
Message-ID: <JqjubOFCvCAg1FTnnN1ihgTbW53CXr0nlQ2E-2vhl0U=.44cfdf67-ed8d-41ce-8c2c-d725f5b07f38@github.com>

On Fri, 15 Oct 2021 17:19:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add @since tags to new API classes
>>  - Add checks and test for empty stream resolver results
>
> test/lib/jdk/test/lib/net/IPSupport.java line 88:
> 
>> 86:             } catch (SocketException se2) {
>> 87:                 return false;
>> 88:             }
> 
> The implementation of this method now conflicts with its name. Maybe we should pass a `Class<? extends InetAddress>`  as parameter, and construct the loopback address from there. IIRC the issue with the original implementation was that it would say that IPv6 was not supported if IPv6 had only been disabled on the loopback interface - and that caused trouble because the native implementation of the built-in resolver had a different view of the situation - and saw that an IPv6 stack was available on the machine. Maybe this would deserve a comment too - so that future maintainers can figure out what we are trying to do here.

Thanks for a good suggestion: renamed to `isSupported`, changed parameter type to `Class<? extends InetAddress> addressType` and updated it to use `SocketChannel.open(ProtocolFamily pf)` [API](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/channels/SocketChannel.html#open(java.net.ProtocolFamily)) added in `15` to check if the plafrom supports addresses of specified address type. Pushed as 95a21e57fbe8be147d23e6a6901ae307e8237cbb.
All new tests (especially `LookupPolicyMappingTest`) pass in environment with `IPv6` addresses disabled.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From ewhelan at openjdk.java.net  Tue Oct 19 13:48:24 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Tue, 19 Oct 2021 13:48:24 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v4]
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:

  Added setInCache to HttpClientAccess to replace reflection

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5964/files
  - new: https://git.openjdk.java.net/jdk/pull/5964/files/90ab8587..e5de4b6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=02-03

  Stats: 8 lines in 2 files changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5964.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5964/head:pull/5964

PR: https://git.openjdk.java.net/jdk/pull/5964

From ewhelan at openjdk.java.net  Tue Oct 19 13:48:28 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Tue, 19 Oct 2021 13:48:28 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <f_XioE2M9Wa0KzO-Zp95SultSMdpWXm_DtmZcqKkEAc=.4f68fb5e-3d99-469c-9f66-f6ca5d130873@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
 <f_XioE2M9Wa0KzO-Zp95SultSMdpWXm_DtmZcqKkEAc=.4f68fb5e-3d99-469c-9f66-f6ca5d130873@github.com>
Message-ID: <SChMfuXPZejkzwRBfQZHFGz7vREYRlAlIgDtqNtmkmE=.8345ccf1-f6e1-40b9-88c0-084741b0410c@github.com>

On Fri, 15 Oct 2021 15:25:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Evan Whelan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Extracted both connectTimeouts to variables and added copyright header to accessor
>>  - Removed reflection in favour of injected accessor for KeepAliveCache
>
> test/jdk/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java line 96:
> 
>> 94:             Field inCache = HttpClient.class.getDeclaredField("inCache");
>> 95:             inCache.setAccessible(true);
>> 96:             inCache.setBoolean(freshClient, true); // allows the assertion in HttpClient.New to pass
> 
> You can use the HttpClientAccess to get and set this field too, since the field is protected in HttpClient.
> Just add a method:
> 
> public void setInCache(HttpClient client, boolean inCache) { client.inCache = inCache; } 
> 
> to HttpClientAccess.

You're right, made that change! Thanks

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From aefimov at openjdk.java.net  Tue Oct 19 13:56:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 19 Oct 2021 13:56:50 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <Q5BlnozxOn1zQDENOIgMe9hoCJwPwIxCpJeMlopsE-E=.3e885e6f-cc96-4da9-bc72-2c198ae7c983@github.com>
 <QIPcuWxhpuptMIUjcXnMbAHYJ7SvN8OWhLrFA5Uw2Ak=.e729dc8f-3747-4ea2-9654-8c1cdae84faa@github.com>
 <-8BcYWYlwGxmsmAY7JBT2h_Ahae3fONnwgGJxfedrJY=.8826d18f-4e00-496e-b06c-96d44e0eeb6c@github.com>
Message-ID: <gqmwg7-KzqmaxKnLxgFTmvOzQQZai6mh4IIJNtCUbug=.db07e7f7-79a8-4338-b5d7-d46fbd8ae884@github.com>

On Sun, 17 Oct 2021 21:39:06 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> I think that a hostname is constant while a host is up, but it can be changed, and when changed a host restart is required. I don't think it is quite as dynamic as has been suggested, but I open to correction.

It is possible to change a host name without host restart. What has been tested:
- Checked O/S type - Linux
- `hostnamectl` cmd was used to change a host name
- In output below there is only one `jshell` instance running.


jshell> InetAddress.getLocalHost()
$1 ==> test-host-name/192.168.0.155

$ hostnamectl set-hostname 'test-host-name-changed'

# Need to sleep for 5 seconds since local host
# is cached for 5 seconds since last resolution
$ sleep 5

jshell> InetAddress.getLocalHost()
$2 ==> test-host-name-changed/192.168.0.155


I believe it proves that we need to treat a host name as dynamically changing information.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Tue Oct 19 17:05:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 19 Oct 2021 17:05:49 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v4]
In-Reply-To: <oQyboiYcm8oe4KHke029DGp4VCYD3ac00ymAECoW3aE=.6e97bcc6-444f-41ae-9f34-cdb60f0b3b03@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <oQyboiYcm8oe4KHke029DGp4VCYD3ac00ymAECoW3aE=.6e97bcc6-444f-41ae-9f34-cdb60f0b3b03@github.com>
Message-ID: <YvnQpNAUaE2NBs0QQfFAoCk8_I8lnUq2GF8j9SD8sn0=.20d76870-6faf-4eb4-94d6-179717118428@github.com>

On Tue, 19 Oct 2021 13:28:26 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove no longer used import from IPSupport
>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>  - Address review comments: javadoc + code cleanup
>  - Address resolver bootstraping issue

Changes look good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Tue Oct 19 17:22:53 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 19 Oct 2021 17:22:53 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v4]
In-Reply-To: <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
Message-ID: <_rsZCFaZAUzeaPzJvWaoQMZO_-OvlUP_9vnUE4UBtBM=.d9dcd139-4119-48a6-9819-a1255c585eaf@github.com>

On Tue, 19 Oct 2021 13:48:24 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added setInCache to HttpClientAccess to replace reflection

test/jdk/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java line 30:

> 28:  * @bug 8274779
> 29:  * @library /test/lib
> 30:  * @modules java.base/sun.net.www.http:+open

I think that now you can probably remove `:+open` - since you're no longer using reflection.

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From vtewari at openjdk.java.net  Wed Oct 20 08:40:10 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Wed, 20 Oct 2021 08:40:10 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v4]
In-Reply-To: <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
Message-ID: <ddILTaJGoNkRXwqrUG9bOD0HlhUrxtwusn6fzfQU3RY=.6f397765-7625-49e8-8343-fb2d79407b54@github.com>

On Tue, 19 Oct 2021 13:48:24 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added setInCache to HttpClientAccess to replace reflection

Looks good to me.

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

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5964

From dfuchs at openjdk.java.net  Wed Oct 20 11:25:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 11:25:08 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
Message-ID: <3qnLVfLEpYxj15nTzZI_wFKy11FHMIauGia3BOyWCoY=.59df2d1f-024f-4736-95c9-21a5d4d03ef4@github.com>

On Tue, 19 Oct 2021 09:32:19 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt line length to 80 column display

Hi - I have run your current patch through our CI and the good news is that we got no failure.
However - we should probably go the extra mile and fix the case where -2 is returned.

>In default mode the exception is swallowed here, and then SocketException ("No network interfaces configured") is thrown in Java code.
> The code that swallows exception appears incorrect; when exception is swallowed, netifPP is null, last is null and the code that could add an IPv6 interface would crash.

I believe you are correct and there are still some issues in that case. In particular I also see -that  if netaddrCount == -2 there:
https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface_winXP.c#L573
we're going to try and allocate arrays of size -2 a few lines below. That doesn't sound right.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From aefimov at openjdk.java.net  Wed Oct 20 11:52:38 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 20 Oct 2021 11:52:38 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Change InetAddressResolver method names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/ac0d2184..30226481

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=03-04

  Stats: 33 lines in 9 files changed: 0 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Wed Oct 20 11:52:40 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 20 Oct 2021 11:52:40 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v3]
In-Reply-To: <ChUmaIjYE61OE80QGJyqes8hnzErFw9IlgrSUlRtnNo=.a34cd6da-cc08-4e84-8fa2-c8f93f258268@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <BMFmfGZcJlmRkv21A_Ur-BgKBwy6E3s3Ea6wk8VCzok=.24667ddf-7882-4d00-80cb-79ca18a7442c@github.com>
 <S8Cd1f2SjiyvwbZ5ZgUuxmJshB3WrbV1HiM0ppOJTKQ=.379aa775-b62b-45e1-a627-aa77bee71ea8@github.com>
 <0Xvj7H_JyjEfXTUr1GI3ooLL1cGBuWLDAtrP83WuQV0=.7e172d30-620d-4ce1-9bac-62db6dc19e52@github.com>
 <ChUmaIjYE61OE80QGJyqes8hnzErFw9IlgrSUlRtnNo=.a34cd6da-cc08-4e84-8fa2-c8f93f258268@github.com>
Message-ID: <e2Z23CSIonfZiKjcUrjv5dy6GkQDF_3eiqICSvXFWV0=.12146e99-a82e-4426-87a5-e871809ec907@github.com>

On Sun, 17 Oct 2021 21:03:56 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> getByName requires a hostname lookup and getByAdress requires (eventually - I know the docs says there?s no reverse lookup) an address reverse lookup. Thus, a logical mapping is getByName ?> lookupHostname, and getByAddr ?> lookupAddress, but the opposite will occur getByName --> lookupAddresses and getByAddress --> lookupHostname. Therfore I proffer maps neatly to rename methods to resolveHostname and resolveAddress such that the mapping are getByName --> resolveHostname and getByAddress --> resolveAddress.

Thank you, Mark, for highlighting the naming contradiction in the `InetAddressResolver` interface method names. It can be solved by making these names symmetrical to `InetAddress` API.
In 302264810725f86a4569161754f7b052c78fd826 `InetAddressResolver` method names have been updated to stress input parameters type, which brings them in sync with `InetAddress` API:
- `InetAddressResolver.lookupAddresses` is renamed to `InetAddressResolver.lookupByName`
- `InetAddressResolver.lookupHostName` is renamed to `InetAddressResolver.lookupByAddress`

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Wed Oct 20 12:15:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 12:15:10 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
Message-ID: <989TOmZMjaWuBKBwzKcJAzYrF16a_A92Ai5rJUTeOWo=.28288722-dab9-4aff-954f-aff1d53295d2@github.com>

On Tue, 19 Oct 2021 09:32:19 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt line length to 80 column display

Hmm... JDK-8225239 might have introduced a bug. 
I see that with the current code neither `enumAddresses_win` nor `enumAddresses_win_ipaddrtable` will return -2 - so there appears to be some dead code. I suspect that this line here is wrong:
 https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface.c#L516
 it should be returning `ret` not `NULL`

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From alanb at openjdk.java.net  Wed Oct 20 13:00:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Oct 2021 13:00:13 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
Message-ID: <BJ9CAU2rEdn9rp3LnPVGZMUqFtGLmFd4lFBqbXTghtI=.cfad70d6-f3ef-4e98-9e12-a51aa16556ef@github.com>

On Tue, 19 Oct 2021 09:32:19 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt line length to 80 column display

The current patch looks good and it's good to have caught the DWORD->int issue. We should add information about this to the JBS issue.
I don't mind if you want to iterate further with Daniel's suggestion, okay if it's a separate PR too. In general I think there is quite a bit of cleanup to do in this code.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Wed Oct 20 13:41:06 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Oct 2021 13:41:06 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <989TOmZMjaWuBKBwzKcJAzYrF16a_A92Ai5rJUTeOWo=.28288722-dab9-4aff-954f-aff1d53295d2@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
 <989TOmZMjaWuBKBwzKcJAzYrF16a_A92Ai5rJUTeOWo=.28288722-dab9-4aff-954f-aff1d53295d2@github.com>
Message-ID: <8rFhPOauGR0KgCcv5yOiwwxNlArWWQi5ItGPSnYxlHI=.fbc824c8-9124-4169-af7a-8d6bda501bbf@github.com>

On Wed, 20 Oct 2021 12:12:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adapt line length to 80 column display
>
> Hmm... JDK-8225239 might have introduced a bug. 
> I see that with the current code neither `enumAddresses_win` nor `enumAddresses_win_ipaddrtable` will return -2 - so there appears to be some dead code. I suspect that this line here is wrong:
>  https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface.c#L516
>  it should be returning `ret` not `NULL`

Thanks @dfuch and @AlanBateman for the review and all your help.

@dfuch I'd rather follow up on the remaining issues in a separate PR. This one is already doing more than the PR title advertises.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From dfuchs at openjdk.java.net  Wed Oct 20 13:58:06 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 13:58:06 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
Message-ID: <f49ecgDTMPwNZkp9Mr723E5ycPoY3Zd3zaVs7Q3Rg4U=.399de9b6-2f3b-4aaa-8e81-bd1471d2be9a@github.com>

On Tue, 19 Oct 2021 09:32:19 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
>> 
>> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
>> 
>> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
>> 
>> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
>> 
>> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
>> 
>> I don't have write access to JBS. I could use some help with creating a ticket.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt line length to 80 column display

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From dfuchs at openjdk.java.net  Wed Oct 20 13:58:06 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 13:58:06 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <8rFhPOauGR0KgCcv5yOiwwxNlArWWQi5ItGPSnYxlHI=.fbc824c8-9124-4169-af7a-8d6bda501bbf@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
 <989TOmZMjaWuBKBwzKcJAzYrF16a_A92Ai5rJUTeOWo=.28288722-dab9-4aff-954f-aff1d53295d2@github.com>
 <8rFhPOauGR0KgCcv5yOiwwxNlArWWQi5ItGPSnYxlHI=.fbc824c8-9124-4169-af7a-8d6bda501bbf@github.com>
Message-ID: <3J1mPCVIfEvWkHfKxbofAw4RwS9dbGXry9L6pBa9sZA=.14afc945-a21d-4628-aafb-cf395b20d6b5@github.com>

On Wed, 20 Oct 2021 13:38:17 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Hmm... JDK-8225239 might have introduced a bug. 
>> I see that with the current code neither `enumAddresses_win` nor `enumAddresses_win_ipaddrtable` will return -2 - so there appears to be some dead code. I suspect that this line here is wrong:
>>  https://github.com/openjdk/jdk/blob/a6c89e231872e7fab236ed87b5ccf44a189d6786/src/java.base/windows/native/libnet/NetworkInterface.c#L516
>>  it should be returning `ret` not `NULL`
>
> Thanks @dfuch and @AlanBateman for the review and all your help.
> 
> @dfuch I'd rather follow up on the remaining issues in a separate PR. This one is already doing more than the PR title advertises.

@djelinski I have no objection in handling that in a followup PR.
I have logged https://bugs.openjdk.java.net/browse/JDK-8275640.
Would you be willing to continue with that?

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Wed Oct 20 14:09:11 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Oct 2021 14:09:11 GMT
Subject: Integrated: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException
In-Reply-To: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
Message-ID: <0P8ZMygvaSaaB71q_ix5HzJldADf_7KY0GnXxjaX0hQ=.79f76a79-c292-4454-a057-c1f3b0529498@github.com>

On Thu, 14 Oct 2021 17:29:16 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Per Java documentation, "[Error](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Error.java#L30) [..] indicates serious problems that a reasonable application should not try to catch". Failure to enumerate network interfaces or addresses is not a serious enough situation; many applications can recover from this pretty easily.
> 
> All native methods (except `init()`) in [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/NetworkInterface.java#L436) are declared with `throws SocketException`, so throwing SocketExceptions instead of Errors will match the declared interface.
> 
> Unix version of [NetworkInterface](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libnet/NetworkInterface.c#L1189) already throws `SocketException`s in similar situations, and does not throw `Error` under any circumstances.
> 
> I searched the bug database and mail archives, but could not find any discussion on the topic; if there's a reason to keep throwing `Error`s, I couldn't find it.
> 
> `tier1` tests pass, `java.net` tests pass. No new regression tests as I couldn't find any list of steps to reproduce the problem.
> 
> I don't have write access to JBS. I could use some help with creating a ticket.

This pull request has now been integrated.

Changeset: 043cde22
Author:    Daniel Jelinski <djelinski1 at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/043cde22d4d6bd975e75daa9ad52770cf79df934
Stats:     74 lines in 2 files changed: 23 ins; 0 del; 51 mod

8275319: java.net.NetworkInterface throws java.lang.Error instead of SocketException

Reviewed-by: alanb, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From duke at openjdk.java.net  Wed Oct 20 14:13:12 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 20 Oct 2021 14:13:12 GMT
Subject: RFR: 8275319 java.net.NetworkInterface throws java.lang.Error
 instead of SocketException [v4]
In-Reply-To: <3J1mPCVIfEvWkHfKxbofAw4RwS9dbGXry9L6pBa9sZA=.14afc945-a21d-4628-aafb-cf395b20d6b5@github.com>
References: <9F8ixX5fMEEOh86D1L1teMAfArQqzf7ls5xm-wgQR8w=.a4f0c951-25c8-44d1-b123-0aa6e14f43ed@github.com>
 <wsJxAkw9ma_3GstoVFIDgq2qFxrTRKJLdwBBqoKYTHw=.59b84696-8b34-49ee-afe1-71f8983726c1@github.com>
 <989TOmZMjaWuBKBwzKcJAzYrF16a_A92Ai5rJUTeOWo=.28288722-dab9-4aff-954f-aff1d53295d2@github.com>
 <8rFhPOauGR0KgCcv5yOiwwxNlArWWQi5ItGPSnYxlHI=.fbc824c8-9124-4169-af7a-8d6bda501bbf@github.com>
 <3J1mPCVIfEvWkHfKxbofAw4RwS9dbGXry9L6pBa9sZA=.14afc945-a21d-4628-aafb-cf395b20d6b5@github.com>
Message-ID: <9dBlL8UvFBBHPB32nqT5Bgkd5WAqTVKWKD8l3w3Fhq8=.3621c384-f14f-41f3-a876-8aa952132c0d@github.com>

On Wed, 20 Oct 2021 13:53:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Thanks @dfuch and @AlanBateman for the review and all your help.
>> 
>> @dfuch I'd rather follow up on the remaining issues in a separate PR. This one is already doing more than the PR title advertises.
>
> @djelinski I have no objection in handling that in a followup PR.
> I have logged https://bugs.openjdk.java.net/browse/JDK-8275640.
> Would you be willing to continue with that?

@dfuch yessir. I'll continue the cleanup, should have something for review later this week.

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

PR: https://git.openjdk.java.net/jdk/pull/5956

From ewhelan at openjdk.java.net  Wed Oct 20 14:52:45 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Wed, 20 Oct 2021 14:52:45 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v5]
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <nBSe0GrqFmgJLy6vlBpCWQwbLMaBz5-R3ehyf000WMw=.b35091f4-0f17-4b24-a345-a077edac00c5@github.com>

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:

  Removed +open from @modules

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5964/files
  - new: https://git.openjdk.java.net/jdk/pull/5964/files/e5de4b6f..f5b0d2d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From michaelm at openjdk.java.net  Wed Oct 20 14:52:49 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 20 Oct 2021 14:52:49 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v4]
In-Reply-To: <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
Message-ID: <lekUFthJOB8qN1MxktKLL_SuAAJEkUJEhgdxODDqK00=.913c88a3-635d-42bb-b491-3f31e90efeba@github.com>

On Tue, 19 Oct 2021 13:48:24 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added setInCache to HttpClientAccess to replace reflection

Marked as reviewed by michaelm (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From michaelm at openjdk.java.net  Wed Oct 20 14:52:50 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 20 Oct 2021 14:52:50 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v3]
In-Reply-To: <npNjsrw6sVIHQOAEF8k_t0vvoUWdKo2Hr5Z8ECsewXQ=.e28fcd05-f999-459c-a29b-be1e65863d38@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <sT11KeI7QmVEsGebqgYWG5ZpXpvOTzWkYttyLRyNKZ4=.352b50ca-3668-43ce-a420-920a46cdf720@github.com>
 <npNjsrw6sVIHQOAEF8k_t0vvoUWdKo2Hr5Z8ECsewXQ=.e28fcd05-f999-459c-a29b-be1e65863d38@github.com>
Message-ID: <x3kK1KXRXSruo6LMQM3Yxgp7OXCTHK840lDDxyYFEe0=.2cfd712d-d129-46dc-91fe-62c9a3e29389@github.com>

On Fri, 15 Oct 2021 15:11:06 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Just wondering what actually happens if you encounter this bug? I guess that the post will fail somehow because it has been given a closed connection. If so, would it be possible to write the test to simulate that behavior?
> 
> So, say you initially do a HTTP request that succeeds (creating a cached connection). Then, somehow close the connection independent of the keep alive cache. Then attempt the streaming post which will either succeed or fail depending whether the bug is fixed or not.

We discussed this off line, and it doesn't seem to be feasible. I'm happy with the fix as is

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From ewhelan at openjdk.java.net  Wed Oct 20 14:52:53 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Wed, 20 Oct 2021 14:52:53 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v4]
In-Reply-To: <_rsZCFaZAUzeaPzJvWaoQMZO_-OvlUP_9vnUE4UBtBM=.d9dcd139-4119-48a6-9819-a1255c585eaf@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <Fzelk10aGaNhzba_QtksqWVXqNUlP3iS2HGtGl_KF0s=.42773b44-4d09-4181-84f2-37faef7c34ae@github.com>
 <_rsZCFaZAUzeaPzJvWaoQMZO_-OvlUP_9vnUE4UBtBM=.d9dcd139-4119-48a6-9819-a1255c585eaf@github.com>
Message-ID: <DNga1FtZGMXKwjpgfQ3AUX2QqoTGZTswN0DN3pbTV28=.969b70b7-5139-412c-8903-d4699f761a1f@github.com>

On Tue, 19 Oct 2021 17:19:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added setInCache to HttpClientAccess to replace reflection
>
> test/jdk/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java line 30:
> 
>> 28:  * @bug 8274779
>> 29:  * @library /test/lib
>> 30:  * @modules java.base/sun.net.www.http:+open
> 
> I think that now you can probably remove `:+open` - since you're no longer using reflection.

Done, thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From dfuchs at openjdk.java.net  Wed Oct 20 14:58:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 14:58:10 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v5]
In-Reply-To: <nBSe0GrqFmgJLy6vlBpCWQwbLMaBz5-R3ehyf000WMw=.b35091f4-0f17-4b24-a345-a077edac00c5@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <nBSe0GrqFmgJLy6vlBpCWQwbLMaBz5-R3ehyf000WMw=.b35091f4-0f17-4b24-a345-a077edac00c5@github.com>
Message-ID: <IJClf7vxkvNvaNvyk7AWP4-8P4cMN88LZByJbQawF3w=.b1a16fd8-dec6-478c-be42-c7f7d3fcb81c@github.com>

On Wed, 20 Oct 2021 14:52:45 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed +open from @modules

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From ewhelan at openjdk.java.net  Wed Oct 20 15:14:06 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Wed, 20 Oct 2021 15:14:06 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v6]
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <YrPqRK4-2x3OeqVsG-ow0kPJ1C4mjspRgqXGDjf0wxE=.93e062fc-33bb-4dff-9eae-9e8e699cc51c@github.com>

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

Evan Whelan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Removed +open from jtreg modules

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5964/files
  - new: https://git.openjdk.java.net/jdk/pull/5964/files/f5b0d2d8..13257929

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5964&range=04-05

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5964.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5964/head:pull/5964

PR: https://git.openjdk.java.net/jdk/pull/5964

From ewhelan at openjdk.java.net  Wed Oct 20 15:14:08 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Wed, 20 Oct 2021 15:14:08 GMT
Subject: RFR: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST [v5]
In-Reply-To: <nBSe0GrqFmgJLy6vlBpCWQwbLMaBz5-R3ehyf000WMw=.b35091f4-0f17-4b24-a345-a077edac00c5@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
 <nBSe0GrqFmgJLy6vlBpCWQwbLMaBz5-R3ehyf000WMw=.b35091f4-0f17-4b24-a345-a077edac00c5@github.com>
Message-ID: <dnofYXqpOge8naXKmxNR-LbjKV3ng4HXi30S7OGt5Mg=.b196fd84-188a-40a5-b70d-d89516b44dae@github.com>

On Wed, 20 Oct 2021 14:52:45 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

>> Hi,
>> 
>> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
>> 
>> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
>> 
>> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
>> 
>> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
>> 
>> All CI testing is green for this fix.
>> 
>> Kind regards,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed +open from @modules

The force push was just modifying the previous git commit message. Including an ampersand accidentally tagged a github user with the username "modules"

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From dfuchs at openjdk.java.net  Wed Oct 20 15:45:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 20 Oct 2021 15:45:08 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
Message-ID: <ivcy8D5adbsN4lpF33q7d8XpBP39fLGfgaajkerWvwA=.e0cb8f51-3de9-4698-977e-387fba7c5c31@github.com>

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change InetAddressResolver method names

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Wed Oct 20 18:36:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Oct 2021 18:36:20 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
Message-ID: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change InetAddressResolver method names

src/java.base/share/classes/java/net/InetAddress.java line 340:

> 338: 
> 339:     /* Used to store the system-wide resolver */
> 340:     private static volatile InetAddressResolver resolver;

Can this be @Stable?

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 34:

> 32: 
> 33: /**
> 34:  * This interface defines operations for looking-up host names and IP addresses.

I think change "looking-up" to "looking up".

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 102:

> 100: 
> 101:         /**
> 102:          * Specifies if IPv4 addresses need to be queried during lookup.

It might be better to change this to "Characteristic value signifying ..." rather than "Specifies".

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 186:

> 184: 
> 185:         /**
> 186:          * Returns an integer value which specifies lookup operation characteristics.

I think I'd change the first line here to something like "Returns a set of characteristics of this lookup policy".

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 35:

> 33: /**
> 34:  * A resolver provider class is a factory for custom implementations of {@linkplain
> 35:  * InetAddressResolver resolvers} which define operations for looking-up (resolving) host names

This reads "custom implementations of resolvers". It might be better to start with "Service-provider class for InetAddress resolvers".

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52:

> 50:     /**
> 51:      * Initialise and return the {@link InetAddressResolver} provided by
> 52:      * this provider. This method is called by {@link InetAddress} when

"the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that.

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 88:

> 86:      *                           {@code RuntimePermission("inetAddressResolverProvider")}.
> 87:      * @implNote It is recommended that an {@code InetAddressResolverProvider} service
> 88:      * implementation does not perform any heavy initialization in its

"heavy initialization" is probably not the best phrase here. Maybe it should say that the initialisation should be as simple as possible to avoid recursive initialisation issues.

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 110:

> 108:     /**
> 109:      * A {@code Configuration} interface is supplied to the
> 110:      * {@link InetAddressResolverProvider#get(Configuration)} method when installing a

I think this should be "Configuration object" rather than "interface" here.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Wed Oct 20 18:50:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 20 Oct 2021 18:50:08 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
Message-ID: <BicXXxHGQ2J_totNOUWmj1GvaMVxtJSV8TfbWQ07vFI=.d1058765-a518-4495-b089-4deafc123970@github.com>

On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change InetAddressResolver method names

src/java.base/share/classes/java/net/InetAddress.java line 244:

> 242:  * @implNote
> 243:  * For any lookup operation that might occur before the VM is fully booted the <i>built-in
> 244:  * resolver</i> will be used.

I think we will need decide if InetAddress class description is the right place for this or whether some/most of it should move to InetAddressResolverProvider. It might be that we update the existing "Host Name Resolution" section with some basic/readable text to make the reader aware that there is a provider mechanism with a link to InetAddressResolverProvider with the details.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From ewhelan at openjdk.java.net  Thu Oct 21 13:37:22 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Thu, 21 Oct 2021 13:37:22 GMT
Subject: Integrated: 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
In-Reply-To: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
References: <0aJ2h8RMavoFWce3nPf_aWSTm3VSNsGJ9EHzT4Uivaw=.50a5a71a-d58a-4173-af0f-7cc9edf4b76b@github.com>
Message-ID: <dlY9aJCKxK4amoJ2GfgAUI5aEuTQhrWWwxHOBEKqJK0=.aadaa5c7-ee0c-4f87-9db3-878af2bf451a@github.com>

On Fri, 15 Oct 2021 08:49:20 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

> Hi,
> 
> Please review my fix for JDK-8274779 which changes how HttpClient and HttpsClient  checks for equality when comparing request methods. 
> 
> When `HttpURLConnection.setRequestMethod` is passed `new String("POST")` rather than the "POST" String literal, the old behaviour resulted in broken HttpClients being reused from the `KeepAliveCache`. 
> 
> This is because a call to `HttpClient.available()` was never reachable due to identity equality being used instead of logical equality.
> 
> The test case uses an injected KeepAliveCache, to which we put a HttpClient that is unavailable. By comparing the initial HttpClient's `connectTimeout` value to the "cached" client's connectTimeout (1234 vs 4321 respectively) we can assert that these values should never be equal as a new HttpClient should be created in cases where we can no longer use the cached one.
> 
> All CI testing is green for this fix.
> 
> Kind regards,
> Evan

This pull request has now been integrated.

Changeset: 45ce06c9
Author:    Evan Whelan <ewhelan at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db
Stats:     177 lines in 4 files changed: 175 ins; 0 del; 2 mod

8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST

Reviewed-by: dfuchs, coffeys, vtewari, michaelm

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

PR: https://git.openjdk.java.net/jdk/pull/5964

From pconcannon at openjdk.java.net  Thu Oct 21 16:47:44 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 21 Oct 2021 16:47:44 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v3]
In-Reply-To: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
Message-ID: <Tu-AoPHobwCgZHXMO8VsZMc1UosbCNWWB7_0xzrCz6A=.1e17963d-a305-4642-8683-c071c55d75c3@github.com>

> Hi,
> 
> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
> 
> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
> 
> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
> 
> Kind regards,
> 
> Patrick

Patrick Concannon 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 four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8260428
 - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
 - Merge remote-tracking branch 'origin/master' into JDK-8260428
 - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5887/files
  - new: https://git.openjdk.java.net/jdk/pull/5887/files/67265bd4..0a920f65

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5887&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5887&range=01-02

  Stats: 24453 lines in 567 files changed: 18562 ins; 3958 del; 1933 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5887/head:pull/5887

PR: https://git.openjdk.java.net/jdk/pull/5887

From aefimov at openjdk.java.net  Thu Oct 21 18:21:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 21 Oct 2021 18:21:50 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v6]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <ekUjsgNgasoSOg0fh0GhZEEokmjT-Kq7PVS6PaqNOZg=.6de99e55-07ed-4b44-ba7f-68a1907ba283@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Review updates + move resolver docs to the provider class (CSR update to follow)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/30226481..2a554c91

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=04-05

  Stats: 123 lines in 3 files changed: 49 ins; 40 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Thu Oct 21 18:21:54 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 21 Oct 2021 18:21:54 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <BicXXxHGQ2J_totNOUWmj1GvaMVxtJSV8TfbWQ07vFI=.d1058765-a518-4495-b089-4deafc123970@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <BicXXxHGQ2J_totNOUWmj1GvaMVxtJSV8TfbWQ07vFI=.d1058765-a518-4495-b089-4deafc123970@github.com>
Message-ID: <htKsbP2LazIbd6Qd_a8ddQANeGoIFSVMXWHmir4MI2M=.a2e97aa1-d9a3-4eb1-b96e-c78f70d4877a@github.com>

On Wed, 20 Oct 2021 18:47:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change InetAddressResolver method names
>
> src/java.base/share/classes/java/net/InetAddress.java line 244:
> 
>> 242:  * @implNote
>> 243:  * For any lookup operation that might occur before the VM is fully booted the <i>built-in
>> 244:  * resolver</i> will be used.
> 
> I think we will need decide if InetAddress class description is the right place for this or whether some/most of it should move to InetAddressResolverProvider. It might be that we update the existing "Host Name Resolution" section with some basic/readable text to make the reader aware that there is a provider mechanism with a link to InetAddressResolverProvider with the details.

Thanks for a good suggestion, Alan. It looks better now (2a554c91864e3b42a0ea315b0a671782fe341927) with some basic text for provider mechanism added to `Host Name Resolution`, and `InetAddress Resolver Providers` section moved to `InetAddressResolverProvider`.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Thu Oct 21 19:12:09 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 21 Oct 2021 19:12:09 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v6]
In-Reply-To: <ekUjsgNgasoSOg0fh0GhZEEokmjT-Kq7PVS6PaqNOZg=.6de99e55-07ed-4b44-ba7f-68a1907ba283@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <ekUjsgNgasoSOg0fh0GhZEEokmjT-Kq7PVS6PaqNOZg=.6de99e55-07ed-4b44-ba7f-68a1907ba283@github.com>
Message-ID: <CQL8ZrmzUieC0CyTq3sH8RPwj-ImDhp-kdz40dHEDkQ=.9ef4adfd-69d2-4c6f-971f-e5a0e8c9ba78@github.com>

On Thu, 21 Oct 2021 18:21:50 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review updates + move resolver docs to the provider class (CSR update to follow)

src/java.base/share/classes/java/net/InetAddress.java line 152:

> 150:  *
> 151:  * <h3> Host Name Resolution </h3>
> 152:  * Host name-to-IP address <i>resolution</i> is accomplished through the use

maybe you need a `<p> ` there even though it's the first paragaph under the header.

src/java.base/share/classes/java/net/InetAddress.java line 159:

> 157:  * by <a href="spi/InetAddressResolverProvider.html#system-wide-resolver">
> 158:  * deploying</a> an {@link InetAddressResolverProvider}.
> 159:  * <p id="built-in-resolver">The built-in resolver implementation is used by

did you double check that anchors defined with `<p id="xxx">` actually work in the generated API doc?
Also maybe leave a blank line before any opening `<p`, that makes it easier to see where the paragraphs are. 
And the convention is to leave a white space after the `<p>` tag...

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 36:

> 34:  * This interface defines operations for looking-up host names and IP addresses.
> 35:  * An instance of {@code InetAddressResolver} is
> 36:  * <a href="InetAddressResolverProvider.html#system-wide-resolver">installed</a> as a

Maybe it would be more appropriate to link _system-wide-resolver_ instead (on the next line in the same sentence).

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 37:

> 35:  *
> 36:  * <p>A resolver provider is a factory for custom implementations of {@linkplain
> 37:  * InetAddressResolver resolvers}. A resolver define operations for looking up

... a resolver define**s** ...

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From vtewari at openjdk.java.net  Fri Oct 22 06:50:07 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 22 Oct 2021 06:50:07 GMT
Subject: RFR: 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl
 implementations [v3]
In-Reply-To: <Tu-AoPHobwCgZHXMO8VsZMc1UosbCNWWB7_0xzrCz6A=.1e17963d-a305-4642-8683-c071c55d75c3@github.com>
References: <bkkRUK72PtHONQXmOl0BJoZfaIeqtzOnRawigNL5vFg=.00380add-a266-4d40-8f4e-f01be54d3972@github.com>
 <Tu-AoPHobwCgZHXMO8VsZMc1UosbCNWWB7_0xzrCz6A=.1e17963d-a305-4642-8683-c071c55d75c3@github.com>
Message-ID: <MROo9MprniL4Ajsf29gfsF2x2_XfnjgZD3rrJOOZop0=.ae2e1e23-d975-400f-8deb-697bb666c8ce@github.com>

On Thu, 21 Oct 2021 16:47:44 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my changes (and CSR) to drop support for pre JDK 1.4 `DatagramSocketImpl` implementations?
>> 
>> These changes propose to drop support for `DatagramSocketImpls` that were compiled with JDK 1.3 or older, which do not have support for connected sockets, for peeking at received datagrams, and for joining and leaving a group at a specific interface. This support is legacy, and should be relatively safe to remove as such implementations do not compile with JDK 1.4 or newer.
>> 
>> Finally, with this set of proposed changes, if you have an `oldImpl`, and don?t use connect, then the methods `joinGroup` and `leaveGroup` will throw?`NoSuchMethodError`.  However, the current behaviour in `DatagramSocketImpl` is to throw an?`UnsupportedOperationsException` for a method not implemented. Should this set of changes update the `joinGroup` and `leaveGroup` methods?in order to preserve this behaviour?
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8274633
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8260428
>  - 8260428: Corrected javadoc typos; combined declaration and initialization of variables in DSI; refactored dummy impls in test
>  - Merge remote-tracking branch 'origin/master' into JDK-8260428
>  - 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations

Marked as reviewed by vtewari (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/5887

From aefimov at openjdk.java.net  Fri Oct 22 14:27:41 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 22 Oct 2021 14:27:41 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  More javadoc updates to API classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/2a554c91..fa655be2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=05-06

  Stats: 88 lines in 3 files changed: 22 ins; 8 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Fri Oct 22 15:17:04 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 22 Oct 2021 15:17:04 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <ivcy8D5adbsN4lpF33q7d8XpBP39fLGfgaajkerWvwA=.e0cb8f51-3de9-4698-977e-387fba7c5c31@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <ivcy8D5adbsN4lpF33q7d8XpBP39fLGfgaajkerWvwA=.e0cb8f51-3de9-4698-977e-387fba7c5c31@github.com>
Message-ID: <j5HoGEu1-EE1wpgY-BuplYr3WYWlduMDa-_q49c0S1A=.3ec67b6c-f959-43ff-a969-c07f0eebfc1e@github.com>

On Wed, 20 Oct 2021 15:41:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change InetAddressResolver method names
>
> Marked as reviewed by dfuchs (Reviewer).

@dfuch @AlanBateman

fa655be2bb0a402b70916567d34cc29a7898f938 and 2a554c91864e3b42a0ea315b0a671782fe341927 contain reworked `InetAddress`/`InetAddressResolverProvider`/`InetAddressResolver` specs with the following changes:
- `InetAddress Resolver Providers` InetAddress section was modified and moved to `InetAddressResolverProvider`.
- `Host Name Resolution` InetAddress section was updated to reference new InetAddress resolver SPI.
- Changes for previous review comments.
- javadoc formatting clean-up

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Sat Oct 23 07:04:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Oct 2021 07:04:05 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
Message-ID: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>

On Fri, 22 Oct 2021 14:27:41 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More javadoc updates to API classes

I've done another pass over the API. Overall it's looking very good and my comments are just to improve the javadoc in a few places to make it clearer.

src/java.base/share/classes/java/net/InetAddress.java line 169:

> 167:  * Access Protocol (LDAP).
> 168:  * The particular naming services that the built-in resolver uses by default
> 169:  * depend on the configuration of the local machine.

depend -> depends

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 38:

> 36:  * deployed as a <a href="InetAddressResolverProvider.html#system-wide-resolver">
> 37:  * system-wide resolver</a>. {@link InetAddress} delegates all lookup requests to
> 38:  * the deployed <i>system-wide resolver</i> instance.

I think the class description would be a bit clearer if we drop sentence 2 because it overlaps with paragraph 2. I think we can adjust sentence 3 to "InetAddress delegates all lookup operations to the system-wide resolver" and it will all flow nicely.

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 88:

> 86:      *                                  to a valid IP address length
> 87:      */
> 88:     String lookupByAddress(byte[] addr) throws UnknownHostException;

I assume this throws NPE if addr is null.

src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 137:

> 135:         /**
> 136:          * This factory method creates {@link LookupPolicy LookupPolicy} instance with a provided
> 137:          * {@code characteristics} value.

This should be "This factory method creates a LookupPolicy ...".

src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45:

> 43:  * system-wide resolver instance, which is used by
> 44:  * <a href="{@docRoot}/java.base/java/net/InetAddress.html#host-name-resolution">
> 45:  * InetAddress</a>.

I think we should prune some some of the text from the class description to avoid repetition.  Here's a suggestion:

1. Add the following immediately after the sentence "A given innovation ..."
"It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 

2. Replace the text in L47-65 with:
"A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows:

3. Replace the remaining three usages of "install" with "set".

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From alanb at openjdk.java.net  Sat Oct 23 07:04:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 23 Oct 2021 07:04:06 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>
Message-ID: <XmR0-Viqe4WDCUYoa2pI-LTLkXlrHXUbHYIBWXXRm8o=.b000002f-94b0-466a-b605-8d6952df7f25@github.com>

On Wed, 20 Oct 2021 18:25:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change InetAddressResolver method names
>
> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52:
> 
>> 50:     /**
>> 51:      * Initialise and return the {@link InetAddressResolver} provided by
>> 52:      * this provider. This method is called by {@link InetAddress} when
> 
> "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that.

Initialise -> Initialize to be consistent with other usages that use US spelling.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From duke at openjdk.java.net  Sat Oct 23 10:34:18 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 23 Oct 2021 10:34:18 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments
Message-ID: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>

Clean up of various issues related to error handling and memory management

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

Commit messages:
 - Fix memory leak
 - Fixup getAllInterfacesAndAddresses
 - Fixup getAddrsFromAdapter
 - Fixup enumAddresses_win
 - Fixup enumAddresses_win_ipaddrtable
 - Remove special handling for GetIfTable failure

Changes: https://git.openjdk.java.net/jdk/pull/6090/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275640
  Stats: 26 lines in 2 files changed: 11 ins; 10 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6090.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090

PR: https://git.openjdk.java.net/jdk/pull/6090

From duke at openjdk.java.net  Mon Oct 25 22:23:32 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Mon, 25 Oct 2021 22:23:32 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
Message-ID: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>

Single-row table was being used as a hack here, a description list
seems more appropriate

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

Commit messages:
 - Improve documentation accessibility

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

PR: https://git.openjdk.java.net/jdk/pull/6010

From ihse at openjdk.java.net  Tue Oct 26 12:39:12 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 26 Oct 2021 12:39:12 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <KlDr0Sv5MRhrWKOHgwpQ_X-YQx23XD3ul-fe0ki5dI4=.0f125fc4-5b39-4678-9f8d-1d4da3b496f2@github.com>

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Single-row table was being used as a hack here, a description list
> seems more appropriate

Looks good to me.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6010

From prappo at openjdk.java.net  Tue Oct 26 12:47:12 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 26 Oct 2021 12:47:12 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <5l0jMLxwbAvV6drZyFLUhWk4NP73wc_lXZZbrhhesHo=.6895d29d-bcd3-41a2-9969-782a48220e1b@github.com>

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Single-row table was being used as a hack here, a description list
> seems more appropriate

Would it be possible to build documentation for that page to see how it looks?

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

PR: https://git.openjdk.java.net/jdk/pull/6010

From aefimov at openjdk.java.net  Tue Oct 26 12:52:58 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:52:58 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov 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 14 additional commits since the last revision:

 - Changes to address review comments
 - Update tests to address SM deprecation
 - Merge branch 'master' into JDK-8244202_JEP418_impl
 - More javadoc updates to API classes
 - Review updates + move resolver docs to the provider class (CSR update to follow)
 - Change InetAddressResolver method names
 - Remove no longer used import from IPSupport
 - Rename IPSupport.hasAddress and update it to use SocketChannel.open
 - Address review comments: javadoc + code cleanup
 - Address resolver bootstraping issue
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a8495826...1378686b

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/fa655be2..1378686b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=06-07

  Stats: 32082 lines in 838 files changed: 22928 ins; 6060 del; 3094 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 12:53:06 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:53:06 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
 <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>
Message-ID: <bNzeqx8yPjqgV-AjHArisAGsQvRloLHSR-InzxCZqn8=.c06b5c23-6ae7-4acd-8813-1bc68325f5d5@github.com>

On Sat, 23 Oct 2021 06:19:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More javadoc updates to API classes
>
> src/java.base/share/classes/java/net/InetAddress.java line 169:
> 
>> 167:  * Access Protocol (LDAP).
>> 168:  * The particular naming services that the built-in resolver uses by default
>> 169:  * depend on the configuration of the local machine.
> 
> depend -> depends

Thanks, changed in 1378686becfcbf18793556de8381b5ebcd79698d

> src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 38:
> 
>> 36:  * deployed as a <a href="InetAddressResolverProvider.html#system-wide-resolver">
>> 37:  * system-wide resolver</a>. {@link InetAddress} delegates all lookup requests to
>> 38:  * the deployed <i>system-wide resolver</i> instance.
> 
> I think the class description would be a bit clearer if we drop sentence 2 because it overlaps with paragraph 2. I think we can adjust sentence 3 to "InetAddress delegates all lookup operations to the system-wide resolver" and it will all flow nicely.

Thanks, changed as suggested in 1378686becfcbf18793556de8381b5ebcd79698d

> src/java.base/share/classes/java/net/spi/InetAddressResolver.java line 88:
> 
>> 86:      *                                  to a valid IP address length
>> 87:      */
>> 88:     String lookupByAddress(byte[] addr) throws UnknownHostException;
> 
> I assume this throws NPE if addr is null.

1378686becfcbf18793556de8381b5ebcd79698d: added @ throws NPE javadoc, also added additional checks for `null` parameter values into the built-in and hosts file resolver implementations.

> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45:
> 
>> 43:  * system-wide resolver instance, which is used by
>> 44:  * <a href="{@docRoot}/java.base/java/net/InetAddress.html#host-name-resolution">
>> 45:  * InetAddress</a>.
> 
> I think we should prune some some of the text from the class description to avoid repetition.  Here's a suggestion:
> 
> 1. Add the following immediately after the sentence "A given innovation ..."
> "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 
> 
> 2. Replace the text in L47-65 with:
> "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows:
> 
> 3. Replace the remaining three usages of "install" with "set".

Thanks, changed as suggested: 1378686becfcbf18793556de8381b5ebcd79698d

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 12:53:09 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:53:09 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v5]
In-Reply-To: <XmR0-Viqe4WDCUYoa2pI-LTLkXlrHXUbHYIBWXXRm8o=.b000002f-94b0-466a-b605-8d6952df7f25@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <XeIIcS-2hjoJhT3lLNH5lS8E1lDWRT1FE_wu40oRXZE=.8d87f4f7-8207-4789-9775-d929db962afd@github.com>
 <1v6OpqkyZp6XBq9lXQfahKEEgtBIdPjNWydqJ9Cwipc=.959e01c2-1e2d-4540-8ed5-41198dd71c2b@github.com>
 <XmR0-Viqe4WDCUYoa2pI-LTLkXlrHXUbHYIBWXXRm8o=.b000002f-94b0-466a-b605-8d6952df7f25@github.com>
Message-ID: <zZkne_nXwraiVo-ilhze4X1t8LJD8jRDsQFOvbu-blA=.fd1c3686-0d41-422e-8d19-9b065465cc13@github.com>

On Sat, 23 Oct 2021 06:33:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 52:
>> 
>>> 50:     /**
>>> 51:      * Initialise and return the {@link InetAddressResolver} provided by
>>> 52:      * this provider. This method is called by {@link InetAddress} when
>> 
>> "the InetAddressResolver" suggests there is just one instance. That is probably the case but I don't think you want to be restricted to that.
>
> Initialise -> Initialize to be consistent with other usages that use US spelling.

Thanks, changed in 1378686becfcbf18793556de8381b5ebcd79698d

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 12:55:11 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 12:55:11 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v7]
In-Reply-To: <bNzeqx8yPjqgV-AjHArisAGsQvRloLHSR-InzxCZqn8=.c06b5c23-6ae7-4acd-8813-1bc68325f5d5@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <IhKLtNMUJZ4hzl912N_SQ53Eg8egidnRfEM2gQ8B3NQ=.36c9b69d-48e7-4128-9095-cfc49a08bd84@github.com>
 <8edQIj95FsYJ3_gmv98KEIVAwFvNxduvXIgrkY96vSk=.6d3f216f-c956-4906-8b81-5f57a79d00d9@github.com>
 <bNzeqx8yPjqgV-AjHArisAGsQvRloLHSR-InzxCZqn8=.c06b5c23-6ae7-4acd-8813-1bc68325f5d5@github.com>
Message-ID: <ABI76QQbjlVkXxRAGpRdIeTHjbdJQshI7AqHC3Tc3KQ=.4219703b-cd16-4bb0-a1df-744ab421a560@github.com>

On Tue, 26 Oct 2021 12:49:30 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java line 45:
>> 
>>> 43:  * system-wide resolver instance, which is used by
>>> 44:  * <a href="{@docRoot}/java.base/java/net/InetAddress.html#host-name-resolution">
>>> 45:  * InetAddress</a>.
>> 
>> I think we should prune some some of the text from the class description to avoid repetition.  Here's a suggestion:
>> 
>> 1. Add the following immediately after the sentence "A given innovation ..."
>> "It is set after the VM is fully initialized and when an invocation of a method in InetAddress class triggers the first lookup operation. 
>> 
>> 2. Replace the text in L47-65 with:
>> "A resolver provider is located and loaded by InetAddress to create the systwm-wide resolver as follows:
>> 
>> 3. Replace the remaining three usages of "install" with "set".
>
> Thanks, changed as suggested: 1378686becfcbf18793556de8381b5ebcd79698d

Pruned `InetAddressResolverProvider` class-level doc as suggested: 1378686becfcbf18793556de8381b5ebcd79698d

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From jboes at openjdk.java.net  Tue Oct 26 13:02:37 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 26 Oct 2021 13:02:37 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should check
 whether "realm" is a quoted string
Message-ID: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>

This change ensures that the realm string passed to the BasicAuthenticator constructor is a quoted-string, as per RFC7230 [1]. A Utils class is added to jdk.httpserver/sun.net.httpserver that holds the new isQuotedString() method and the pre-existing isValidName() method (previously in ServerImpl.) 
Two tests are included:
- BasicAuthenticatorRealm.java to check that Latin-1 chars in the realm string are transported correctly,
- BasicAuthenticatorExceptionCheck.java to check realm strings with escaped quotes.

Testing: tier 1-3.

[1] https://datatracker.ietf.org/doc/html/rfc7230

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6117/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6117&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275534
  Stats: 338 lines in 6 files changed: 304 ins; 22 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6117/head:pull/6117

PR: https://git.openjdk.java.net/jdk/pull/6117

From alanb at openjdk.java.net  Tue Oct 26 13:11:21 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 26 Oct 2021 13:11:21 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
Message-ID: <1ocUc2kRrpqHA-uWpjWrTtByfCvRoXWV-tbDJCEjmbs=.1149b134-96fc-45c3-81e3-1cee89b8d3aa@github.com>

On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov 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 14 additional commits since the last revision:
> 
>  - Changes to address review comments
>  - Update tests to address SM deprecation
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - More javadoc updates to API classes
>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>  - Change InetAddressResolver method names
>  - Remove no longer used import from IPSupport
>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>  - Address review comments: javadoc + code cleanup
>  - Address resolver bootstraping issue
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/c2db4e04...1378686b

Thanks for the updates to the API docs, you've addressed all my comments.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Tue Oct 26 13:27:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Oct 2021 13:27:16 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <cuSxMc9D8_R1pP3RE3TsPDKg7aOjrr4D8mXRJqFl68I=.5ef4dec4-9327-49c2-8380-117213cb8803@github.com>

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Single-row table was being used as a hack here, a description list
> seems more appropriate

Hi Ludwik, it's the first time I see `<dl>`, `<dt>`, and `<dd>` being used in API documentation so I'd like to see some confirmation from the javadoc team that the proposed changes are OK WRT to accessibility. I have added the `javadoc` label to that purpose...

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

PR: https://git.openjdk.java.net/jdk/pull/6010

From duke at openjdk.java.net  Tue Oct 26 13:38:13 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Tue, 26 Oct 2021 13:38:13 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <5l0jMLxwbAvV6drZyFLUhWk4NP73wc_lXZZbrhhesHo=.6895d29d-bcd3-41a2-9969-782a48220e1b@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
 <5l0jMLxwbAvV6drZyFLUhWk4NP73wc_lXZZbrhhesHo=.6895d29d-bcd3-41a2-9969-782a48220e1b@github.com>
Message-ID: <aNDkZvUm3HYQvsRFAeHedCttoAHYe5q6QZS9dx164WQ=.dec7ff50-3ff7-4e78-b3d3-b1d4c2042608@github.com>

On Tue, 26 Oct 2021 12:44:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Single-row table was being used as a hack here, a description list
>> seems more appropriate
>
> Would it be possible to build documentation for that page to see how it looks?

@pavelrappo here's a screengrab from my local build. It doesn't look exactly as before, but I think the message is the same. Idiomatically, the <dl> element is ideal for this kind of thing:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dl

![image](https://user-images.githubusercontent.com/6298393/138889310-7a75a762-ae70-4f5f-969f-65df570e2bac.png)

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

PR: https://git.openjdk.java.net/jdk/pull/6010

From dfuchs at openjdk.java.net  Tue Oct 26 15:10:24 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Oct 2021 15:10:24 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
Message-ID: <tb8g4zT745Ybk1uHQnmAIwoKPK7cPh_nJU3WljpNYT0=.243257e0-fdd0-4bb1-a646-59608fb56319@github.com>

On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov 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 14 additional commits since the last revision:
> 
>  - Changes to address review comments
>  - Update tests to address SM deprecation
>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>  - More javadoc updates to API classes
>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>  - Change InetAddressResolver method names
>  - Remove no longer used import from IPSupport
>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>  - Address review comments: javadoc + code cleanup
>  - Address resolver bootstraping issue
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/10094444...1378686b

Marked as reviewed by dfuchs (Reviewer).

src/java.base/share/classes/java/net/InetAddress.java line 1151:

> 1149: 
> 1150:             Objects.requireNonNull(host);
> 1151:             Objects.requireNonNull(lookupPolicy);

for consistency we could add `@throws NullPointerException` to the API doc of that method - since it seems to have everything else...

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 16:24:48 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 16:24:48 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Add @ throws NPE to hosts file resolver javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/1378686b..2ca78ba9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Tue Oct 26 16:24:55 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 26 Oct 2021 16:24:55 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v8]
In-Reply-To: <tb8g4zT745Ybk1uHQnmAIwoKPK7cPh_nJU3WljpNYT0=.243257e0-fdd0-4bb1-a646-59608fb56319@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <OY6XSP-scqTid36ieqZATpNo445ZqfAu0dqd_UEmx_M=.53ccab35-d57d-496d-92db-7a9584b70d2d@github.com>
 <tb8g4zT745Ybk1uHQnmAIwoKPK7cPh_nJU3WljpNYT0=.243257e0-fdd0-4bb1-a646-59608fb56319@github.com>
Message-ID: <beYMyXv9niQPO5dbrBpGnDzjEHhawwEHFew5ZqKiQX0=.e532cee4-162e-44c1-ba36-869c99d1c73b@github.com>

On Tue, 26 Oct 2021 15:04:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov 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 14 additional commits since the last revision:
>> 
>>  - Changes to address review comments
>>  - Update tests to address SM deprecation
>>  - Merge branch 'master' into JDK-8244202_JEP418_impl
>>  - More javadoc updates to API classes
>>  - Review updates + move resolver docs to the provider class (CSR update to follow)
>>  - Change InetAddressResolver method names
>>  - Remove no longer used import from IPSupport
>>  - Rename IPSupport.hasAddress and update it to use SocketChannel.open
>>  - Address review comments: javadoc + code cleanup
>>  - Address resolver bootstraping issue
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/1bbecc93...1378686b
>
> src/java.base/share/classes/java/net/InetAddress.java line 1151:
> 
>> 1149: 
>> 1150:             Objects.requireNonNull(host);
>> 1151:             Objects.requireNonNull(lookupPolicy);
> 
> for consistency we could add `@throws NullPointerException` to the API doc of that method - since it seems to have everything else...

Added `@throws NullPointerException` to the hosts file resolver API docs: 2ca78ba98dc81cd6cc44b53dc7d56a6ae42c2736

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Tue Oct 26 16:30:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 26 Oct 2021 16:30:16 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
Message-ID: <0mvmoo3ws7YZ_Wf_9bZmvjDHZZ5PQFaOCBhpn4x-q30=.08ef6e7a-f8b1-4b3f-9a1f-2d91e44d2598@github.com>

On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ throws NPE to hosts file resolver javadoc

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From duke at openjdk.java.net  Tue Oct 26 16:45:21 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 26 Oct 2021 16:45:21 GMT
Subject: Integrated: 8275079: Remove unnecessary conversion to String in
 java.net.http
In-Reply-To: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
References: <REXYKZxDrFGwnouJolxPJBl0bu8AxfBqDsXdfDQ0wa0=.9188a2d3-2831-46e3-a9b4-0be7e0c8d0e6@github.com>
Message-ID: <44HAVmWJFcyu-AdhRRsJeF7mOszcfse1fl27XS0hiFM=.ba08b56a-8d4c-41f3-9370-2821310ca088@github.com>

On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cleanup unnecessary String.valueOf calls (and similar) when conversion will happen implicitly anyway

This pull request has now been integrated.

Changeset: 19f76c21
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19f76c215dbe9528dde10acd744be54618ea5e4c
Stats:     34 lines in 13 files changed: 0 ins; 3 del; 31 mod

8275079: Remove unnecessary conversion to String in java.net.http

Reviewed-by: dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/5795

From michaelm at openjdk.java.net  Wed Oct 27 08:23:12 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 27 Oct 2021 08:23:12 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
Message-ID: <3BfUI8L9b1txsAcqvyMud8DVhedxAi5WmNI_mjCYrmo=.6dd31b99-feed-410e-88ed-d4aef1728cf2@github.com>

On Tue, 26 Oct 2021 12:46:31 GMT, Julia Boes <jboes at openjdk.org> wrote:

> This change ensures that the realm string passed to the BasicAuthenticator constructor is a quoted-string, as per RFC7230 [1]. A Utils class is added to jdk.httpserver/sun.net.httpserver that holds the new isQuotedString() method and the pre-existing isValidName() method (previously in ServerImpl.) 
> Two tests are included:
> - BasicAuthenticatorRealm.java to check that Latin-1 chars in the realm string are transported correctly,
> - BasicAuthenticatorExceptionCheck.java to check realm strings with escaped quotes.
> 
> Testing: tier 1-3.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc7230

Changes requested by michaelm (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java line 56:

> 54:      * realm string, it must be escaped by two preceding backslashes, for example
> 55:      * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.
> 56:      *

I'm not sure the point really warrants an API note like this. I think the specification is clear enough from the @throws clause.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java line 77:

> 75:      * <p>Where a backslash ("\") is used as quoting mechanism within the realm
> 76:      * string, it must be escaped by two preceding backslashes, for example
> 77:      * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.

Same point as above

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From dfuchs at openjdk.java.net  Wed Oct 27 11:23:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 27 Oct 2021 11:23:10 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments
In-Reply-To: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
Message-ID: <eNCy3exJH4a5U7uX_f1L5lR8-Ppy6LClnC31SNS3Atg=.aff79101-c7ed-41df-a781-d00b4b492d68@github.com>

On Sat, 23 Oct 2021 10:26:34 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Clean up of various issues related to error handling and memory management

Hi Daniel - it looks like your changeset is reverting all the changes that were made by [JDK-8046500](https://bugs.openjdk.java.net/browse/JDK-8046500), to fix an issue where no interfaces were returned on machines that had only IPv6 interfaces (and no IPv4). See https://mail.openjdk.java.net/pipermail/net-dev/2018-November/011931.html ; 

Were you able to test that `NetworkInterface.getNetworkInterfaces()` will not fail on a machine where IPv4 has been disabled with `netsh interface ipv4 uninstall` ?

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From duke at openjdk.java.net  Wed Oct 27 12:53:12 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 27 Oct 2021 12:53:12 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments
In-Reply-To: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
Message-ID: <9vznL_98pqJ0Fgl6um_9ttSWb0_7RKe5KAZo7g59zXE=.a0cf12d1-011b-4003-8498-bda220ddcaf2@github.com>

On Sat, 23 Oct 2021 10:26:34 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Clean up of various issues related to error handling and memory management

Hi, I wasn't able to run the test yet; need to find a machine where I could run this test without worrying about restoring it to a working state.
However, looking at the code, I think it's broken already. JDK-8046500 says GetIpAddrTable fails on IPv6-only machines. This method is only called in `lookupIPAddrTable`, and `getAllInterfacesAndAddresses` ignores -2 result since 7f1f9a50ae87e745e552ed8a3b7028cd49638441.
Still, `enumAddresses_win` probably needs more love. I'll look into it.

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From jjg at openjdk.java.net  Wed Oct 27 16:10:13 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 27 Oct 2021 16:10:13 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <AcUjQhBUOYVTVgBU2jIVoxWWxRfWNnW3JFVGzW2pY10=.d14d8091-9e08-4e42-8959-f3b44cf5f29f@github.com>

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Single-row table was being used for visual effect, but a description list seems more appropriate.

OK, but ...

While the basic translation from a single-row table to a definition list looks good, it's not clear you still need the `style` attribute. Also, explicit use of `<b>` and `<i>` is discouraged for accessibility reasons; if you need any tags to adjust the font here, it's better to use semantic equivalents like `<strong>` and `<em>` (emphasis). But even better to reduce unnecessary stylistic changes and rely on the default settings (in this case for `<dl>`) in the stylesheet.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6010

From duke at openjdk.java.net  Wed Oct 27 16:21:20 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 27 Oct 2021 16:21:20 GMT
Subject: Integrated: 8274879: Replace uses of StringBuffer with StringBuilder
 within java.base classes
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <9BGa0d9dkCjuAJV2PJrCCMDAMGjW6WSkDGeuWSn3Xh8=.6eacd128-16e4-4d80-a9a4-310e9107f6af@github.com>

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

This pull request has now been integrated.

Changeset: 9a3e9542
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a3e9542997860de79d07a4411b1007e9cd5c348
Stats:     31 lines in 11 files changed: 0 ins; 0 del; 31 mod

8274879: Replace uses of StringBuffer with StringBuilder within java.base classes

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk/pull/5432

From michaelm at openjdk.java.net  Wed Oct 27 17:23:17 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 27 Oct 2021 17:23:17 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
Message-ID: <fw2tN1vI4v7XDWUcwDWuCEkMPd9gHszwarIjIi2pNMI=.5d28a2b6-838c-409b-8a2a-377269e75568@github.com>

On Tue, 26 Oct 2021 16:24:48 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @ throws NPE to hosts file resolver javadoc

src/java.base/share/classes/java/net/InetAddress.java line 841:

> 839:         // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0' delegate to the system-wide resolver,
> 840:         // which could be a custom one. At that point we treat any unexpected RuntimeException thrown by
> 841:         // the resolver as we would treat an UnknownHostException or an unmatched host name.

indentation issue in comment above

src/java.base/share/classes/java/net/InetAddress.java line 1308:

> 1306:      * Creates an InetAddress based on the provided host name and IP address.
> 1307:      * System {@linkplain InetAddressResolver resolver} is not used to check
> 1308:      * the validity of the address.

Is this term "system resolver" defined somewhere? I think it means the configured resolver for the current VM. Previously, it really was the system resolver. So, I think it's potentially confusing, as there is also reference to the java.net.preferIPv6Addresses system property as having a possible value "system" which refers to the operating system. Since the CSR is approved, I'm happy to discuss this point post integration.

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From duke at openjdk.java.net  Thu Oct 28 07:20:38 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 28 Oct 2021 07:20:38 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v2]
In-Reply-To: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
Message-ID: <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>

> Clean up of various issues related to error handling and memory management

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Restore support for IPv6-only operation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6090/files
  - new: https://git.openjdk.java.net/jdk/pull/6090/files/712c97cc..f440a6e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6090&range=00-01

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6090.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6090/head:pull/6090

PR: https://git.openjdk.java.net/jdk/pull/6090

From duke at openjdk.java.net  Thu Oct 28 07:40:15 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 28 Oct 2021 07:40:15 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v2]
In-Reply-To: <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
Message-ID: <SReG6sbX4FbT1mW6Zw8XUa3g_y1aCiK4Tzx3PQMwR6w=.202e8e19-98b2-4514-8119-8045af75f3d4@github.com>

On Thu, 28 Oct 2021 07:20:38 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore support for IPv6-only operation

I was able to find and fix the problems with IPv6-only operation; all of the following:
`NetworkInterface.getNetworkInterfaces()`
`NetworkInterface.getByName`
`NetworkInterface.getByIndex`
`NetworkInterface.getByInetAddress`
`NetworkInterface#isUp`
succeeded and returned correct data on a machine with IPv4 after f440a6e0f79179469ffa36cc35863efd3301a494 was applied.
While working on this I noticed that:
- building on IPv6-only machine doesn't work; I got an error message mentioning Sjavac and `No port file values materialized.` I guess I'll revisit this later.
- JTreg tests on IPv6-only machine don't work; I only get a cryptic TEST FAILURE message (but if the tests successfully passed earlier when IPv4 was enabled, I get TEST SUCCESS, probably cached somewhere). I don't even know how to start troubleshooting this.

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From myano at openjdk.java.net  Thu Oct 28 09:41:17 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 28 Oct 2021 09:41:17 GMT
Subject: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some
 process is holding the file
In-Reply-To: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
References: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
Message-ID: <eGUbjjYwF5j_pGEHlR93YVat-poNf2NDxOndYyKAajk=.c21d784c-d89b-4635-b8be-0fbcb0c8216f@github.com>

On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8233674 bug fixes?
> This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried.

Thank you for your reply.
I understand we have no need to fix the JDK. I will close this pull request.

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

PR: https://git.openjdk.java.net/jdk/pull/5460

From myano at openjdk.java.net  Thu Oct 28 09:41:17 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Thu, 28 Oct 2021 09:41:17 GMT
Subject: Withdrawn: 8233674: JarURLConnection.getJarFile throws Exception if
 some process is holding the file
In-Reply-To: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
References: <vciidDSmgseoyiUZHUCGQcQwB_fbf-uRYlz_UpyM3sQ=.499bfe62-dd57-4110-b69a-aa2638d09ad3@github.com>
Message-ID: <_Ke99GmwxSN9hJbO1BGbSGwIE2J0ZcszsZkwPawkSXQ=.8b7f91dd-5fbb-4532-b201-8e0f4d3ebddb@github.com>

On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Could you please review the 8233674 bug fixes?
> This problem is caused by the antivirus software opening the file for a short time, so CreateFile() should be retried.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5460

From dfuchs at openjdk.java.net  Thu Oct 28 10:57:09 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 28 Oct 2021 10:57:09 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v2]
In-Reply-To: <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
Message-ID: <-t9DycFPXSTJmz-IzMkuWm-wM4TydLqXdxeUsLOfvLk=.b04cb576-fe6f-4fa0-ba8d-0ace7fdd7f81@github.com>

On Thu, 28 Oct 2021 07:20:38 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore support for IPv6-only operation

Hi Daniel, thanks for the update - I will have a look.

Concerning IPv6-only environment - it's a bit of a whack a mole game at the moment. We have updated many tests to not assume that IPv4 was available, but unfortunately I suspect that we still have many tests that do depend on IPv4 - and that don't have the logic to either pick IPv6 or skip...

We had an openjdk contributor at one time who were interested in moving this forward but I believe they have moved to other interests...
Still - we are trying to make sure that new code (especially in networking area) doesn't make any assumption on the availability of either stack.

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From duke at openjdk.java.net  Thu Oct 28 11:18:14 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 28 Oct 2021 11:18:14 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v2]
In-Reply-To: <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
Message-ID: <vgAhXKcXegr7Pqk57ggcfp7keoTWNHlttD-GxXiqSi4=.7cc7e8e5-0338-4c84-a331-2d292c7b7566@github.com>

On Thu, 28 Oct 2021 07:20:38 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

>> Clean up of various issues related to error handling and memory management
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore support for IPv6-only operation

Just to clarify, no tests were run. The failure was reported by JTReg itself. As of now building Java on Windows requires IPv4.

On a side note, Microsoft created a completely new set of network interface-related APIs in Windows Vista. It looks like they could simplify our getByXXX methods, and possibly we could also use the same method to extract both IPv4 and IPv6 addresses. Do you think we could replace the pre-Vista code and start using the new functions?

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From duke at openjdk.java.net  Thu Oct 28 12:11:33 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 28 Oct 2021 12:11:33 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs [v2]
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <xvXdk_0n_4o2olvueRlnoQxnLwHRIoz2qGxcBdrYIBI=.d3bcc528-4dc0-4ed0-a345-eda909cfaefb@github.com>

> Single-row table was being used for visual effect, but a description list seems more appropriate.

Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:

  Removed html fluff

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6010/files
  - new: https://git.openjdk.java.net/jdk/pull/6010/files/dc2ff1a7..7c2413b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6010&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6010&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6010.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6010/head:pull/6010

PR: https://git.openjdk.java.net/jdk/pull/6010

From duke at openjdk.java.net  Thu Oct 28 12:11:33 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 28 Oct 2021 12:11:33 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <Td11r4WZFV8wTbuyBuJE5JAc1Iirt451M0Auc5GZ2fg=.4aae3991-cc0c-476a-b675-708852e85398@github.com>

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Single-row table was being used for visual effect, but a description list seems more appropriate.

Done. I'm happy to drop them, I was just trying to keep the visuals as close to the original as possible.
![image](https://user-images.githubusercontent.com/6298393/139252397-24325ac7-0347-4d5a-95a7-78aca6ee5c16.png)

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

PR: https://git.openjdk.java.net/jdk/pull/6010

From dfuchs at openjdk.java.net  Thu Oct 28 14:30:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 28 Oct 2021 14:30:10 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v2]
In-Reply-To: <vgAhXKcXegr7Pqk57ggcfp7keoTWNHlttD-GxXiqSi4=.7cc7e8e5-0338-4c84-a331-2d292c7b7566@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
 <vgAhXKcXegr7Pqk57ggcfp7keoTWNHlttD-GxXiqSi4=.7cc7e8e5-0338-4c84-a331-2d292c7b7566@github.com>
Message-ID: <4ihuTpeqUX2R3pwVnHEEGAwikda88BJ0LlIZTq0Nu3c=.1b68215c-4e26-4657-b058-03ad64d9a91f@github.com>

On Thu, 28 Oct 2021 11:15:16 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> Just to clarify, no tests were run. The failure was reported by JTReg itself. As of now building Java on Windows requires IPv4.

Understood. I'm satisfied that you manually tested the results on your machine - and if that change passes the tier1, tier2 in our CI I believe I'd be happy (I still need to review it though).

> On a side note, Microsoft created a completely new set of network interface-related APIs in Windows Vista. It looks like they could simplify our getByXXX methods, and possibly we could also use the same method to extract both IPv4 and IPv6 addresses. Do you think we could replace the pre-Vista code and start using the new functions?

Yes - I saw that there were newer versions of some of these APIs - I was wondering too if using them would simplify our code. On the one hand it would be very good to simplify the code and use more modern API. On the other hand that would probably deserve more testing - possibly setting up some machines with special configurations to make sure we're not introducing new regressions. Let me think on it and seek other's opinions...

I assume we're talking about using [GetIfTable2](https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-getiftable2) and `GetIfEntry2` or are there  even newer APIs? But that wouldn't dispense us of calling `GetAdaptersAddresses` too - would it?

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From jjg at openjdk.java.net  Thu Oct 28 14:35:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 28 Oct 2021 14:35:10 GMT
Subject: RFR: JDK-8275518: accessibility issue in Inet6Address docs [v2]
In-Reply-To: <xvXdk_0n_4o2olvueRlnoQxnLwHRIoz2qGxcBdrYIBI=.d3bcc528-4dc0-4ed0-a345-eda909cfaefb@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
 <xvXdk_0n_4o2olvueRlnoQxnLwHRIoz2qGxcBdrYIBI=.d3bcc528-4dc0-4ed0-a345-eda909cfaefb@github.com>
Message-ID: <47IevuuwQFlg1TpQJhzYZ2oyNuWWKNfEvEmFo2TSv4Y=.a43a531f-c871-4200-9770-d79d56862e4d@github.com>

On Thu, 28 Oct 2021 12:11:33 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

>> Single-row table was being used for visual effect, but a description list seems more appropriate.
>
> Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed html fluff

Latest version, with latest modifications, approved.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6010

From duke at openjdk.java.net  Thu Oct 28 14:44:19 2021
From: duke at openjdk.java.net (Ludvig Janiuk)
Date: Thu, 28 Oct 2021 14:44:19 GMT
Subject: Integrated: JDK-8275518: accessibility issue in Inet6Address docs
In-Reply-To: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
References: <c9yMJzFzzD4GuaRtf-zlvpBEfcnJOoVSxGMYHksQuKg=.3eb31b9e-82d6-4039-9409-cd464731862e@github.com>
Message-ID: <XMIrm7MqvHzkm8hfZzG8ORb8WoMvsEfzvV9BacoS7gs=.4e050b45-b448-42b1-8913-f0c80b4d2569@github.com>

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk <duke at openjdk.java.net> wrote:

> Single-row table was being used for visual effect, but a description list seems more appropriate.

This pull request has now been integrated.

Changeset: abe52aea
Author:    Ludvig Janiuk <ludvig.j.janiuk at oracle.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/abe52aea23d6025737666dfc2b265fdf1aae14bb
Stats:     8 lines in 1 file changed: 1 ins; 1 del; 6 mod

8275518: accessibility issue in Inet6Address docs

Reviewed-by: ihse, jjg

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

PR: https://git.openjdk.java.net/jdk/pull/6010

From duke at openjdk.java.net  Thu Oct 28 17:25:16 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 28 Oct 2021 17:25:16 GMT
Subject: RFR: 8275640 (win) java.net.NetworkInterface issues with IPv6-only
 environments [v2]
In-Reply-To: <4ihuTpeqUX2R3pwVnHEEGAwikda88BJ0LlIZTq0Nu3c=.1b68215c-4e26-4657-b058-03ad64d9a91f@github.com>
References: <m-MZI29Qrn00mfWHBXMqd5U0EMhYaZGW0ISIlLaJbYM=.4267287a-1fca-48a1-bf75-60c1965a90ef@github.com>
 <E_gnMt1FkRMAM-RKB4f5KlWn8gW-IyI8LWDTVyDy8dA=.483bdfa8-f7c7-4ec3-9745-1481a75f15a6@github.com>
 <vgAhXKcXegr7Pqk57ggcfp7keoTWNHlttD-GxXiqSi4=.7cc7e8e5-0338-4c84-a331-2d292c7b7566@github.com>
 <4ihuTpeqUX2R3pwVnHEEGAwikda88BJ0LlIZTq0Nu3c=.1b68215c-4e26-4657-b058-03ad64d9a91f@github.com>
Message-ID: <Zq59tvi0Qv0uzqXASr6z6CE9kRtA6G8ZfP7Uzvhveoc=.a7b5a93c-2d5b-4f08-837b-769ccf19a505@github.com>

On Thu, 28 Oct 2021 14:27:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I still need to review it though

Each commit tries to fix one function (memory allocation / deallocation / return values); it may be easier to review them one by one.

> I assume we're talking about using `GetIfTable2` and `GetIfEntry2`

Yes, that's what I was talking about.
And yes, looks like `GetAdaptersAddresses` is still the best method to retrieve adapter-to-address mapping. For a moment I thought [GetUnicastIpAddressEntry](https://docs.microsoft.com/en-us/windows/win32/api/Netioapi/nf-netioapi-getunicastipaddressentry) might be able to find adapter by IP address, but apparently that is not the case.

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

PR: https://git.openjdk.java.net/jdk/pull/6090

From dfuchs at openjdk.java.net  Fri Oct 29 09:33:19 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Oct 2021 09:33:19 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
Message-ID: <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>

On Tue, 26 Oct 2021 12:46:31 GMT, Julia Boes <jboes at openjdk.org> wrote:

> This change ensures that the realm string passed to the BasicAuthenticator constructor is a quoted-string, as per RFC7230 [1]. A Utils class is added to jdk.httpserver/sun.net.httpserver that holds the new isQuotedString() method and the pre-existing isValidName() method (previously in ServerImpl.) 
> Two tests are included:
> - BasicAuthenticatorRealm.java to check that Latin-1 chars in the realm string are transported correctly,
> - BasicAuthenticatorExceptionCheck.java to check realm strings with escaped quotes.
> 
> Testing: tier 1-3.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc7230

src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java line 77:

> 75:      * <p>Where a backslash ("\") is used as quoting mechanism within the realm
> 76:      * string, it must be escaped by two preceding backslashes, for example
> 77:      * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.

I would drop this sentence as I find it confusing - even though I understand what you are trying to say.

I would replace it with something like:


The value of the {@code realm} parameter will be embedded in a quoted string. Any quote it contains must be escaped by the caller.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java line 90:

> 88:         if (realm.isEmpty()) // implicit NPE check
> 89:             throw new IllegalArgumentException("realm must not be empty");
> 90:         if (!isQuotedString(realm))

A better name for the method would be `isQuotedStringContent()`?

src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java line 76:

> 74:      * Validates an RFC 7230 quoted-string.
> 75:      */
> 76:     public static boolean isQuotedString(String token) {

See my comment about the method name above

src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java line 78:

> 76:     public static boolean isQuotedString(String token) {
> 77:         for (int i = 0; i < token.length(); i++) {
> 78:             char c = token.charAt(i);

For the value it would probably be more correct to work with the bytes returned by `getBytes(StandardCharsets.ISO_8859_1)` rather than with Java UTF-16 chars - I don't think UTF-16 is a super set of ISO-8859-1

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From michaelm at openjdk.java.net  Fri Oct 29 10:10:21 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 29 Oct 2021 10:10:21 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
 <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
Message-ID: <5wcbXWPYPXXzvDPrUJmhHGYD4v8IVQrCTlT4P1LVjJA=.6f22fce4-750a-47bc-aa7f-d19fdd871aab@github.com>

On Tue, 26 Oct 2021 13:31:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This change ensures that the realm string passed to the BasicAuthenticator constructor is a quoted-string, as per RFC7230 [1]. A Utils class is added to jdk.httpserver/sun.net.httpserver that holds the new isQuotedString() method and the pre-existing isValidName() method (previously in ServerImpl.) 
>> Two tests are included:
>> - BasicAuthenticatorRealm.java to check that Latin-1 chars in the realm string are transported correctly,
>> - BasicAuthenticatorExceptionCheck.java to check realm strings with escaped quotes.
>> 
>> Testing: tier 1-3.
>> 
>> [1] https://datatracker.ietf.org/doc/html/rfc7230
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java line 77:
> 
>> 75:      * <p>Where a backslash ("\") is used as quoting mechanism within the realm
>> 76:      * string, it must be escaped by two preceding backslashes, for example
>> 77:      * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.
> 
> I would drop this sentence as I find it confusing - even though I understand what you are trying to say.
> 
> I would replace it with something like:
> 
> 
> The value of the {@code realm} parameter will be embedded in a quoted string. Any quote it contains must be escaped by the caller.

I still think it is too much of a corner case to impose on the API doc so much. How about changing the @throws to


      * @throws IllegalArgumentException if realm is an empty string or is not correctly
      *         escaped, as specified in <a href="https://tools.ietf.org/html/rfc7230#section-3.2">
      *         RFC 7230 section-3.2</a>.
 ```

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From dfuchs at openjdk.java.net  Fri Oct 29 10:15:17 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Oct 2021 10:15:17 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <5wcbXWPYPXXzvDPrUJmhHGYD4v8IVQrCTlT4P1LVjJA=.6f22fce4-750a-47bc-aa7f-d19fdd871aab@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
 <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
 <5wcbXWPYPXXzvDPrUJmhHGYD4v8IVQrCTlT4P1LVjJA=.6f22fce4-750a-47bc-aa7f-d19fdd871aab@github.com>
Message-ID: <mAu79Kvwe-cq2ciKSLmEUoCSXE9siLBCR9-vIyBn0WU=.21479330-6959-45a3-aac0-c3a38faaf3a2@github.com>

On Fri, 29 Oct 2021 10:07:45 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java line 77:
>> 
>>> 75:      * <p>Where a backslash ("\") is used as quoting mechanism within the realm
>>> 76:      * string, it must be escaped by two preceding backslashes, for example
>>> 77:      * {@code "foo\\\"bar\\\""} will be embedded as {@code "foo\"bar\""}.
>> 
>> I would drop this sentence as I find it confusing - even though I understand what you are trying to say.
>> 
>> I would replace it with something like:
>> 
>> 
>> The value of the {@code realm} parameter will be embedded in a quoted string. Any quote it contains must be escaped by the caller.
>
> I still think it is too much of a corner case to impose on the API doc so much. How about changing the @throws to
> 
> 
>       * @throws IllegalArgumentException if realm is an empty string or is not correctly
>       *         escaped, as specified in <a href="https://tools.ietf.org/html/rfc7230#section-3.2">
>       *         RFC 7230 section-3.2</a>.
>  ```

OK - but then I'd still say: `The value of the {@code realm} parameter will be embedded in a quoted string.`
Otherwise the caller might think they need to provide a quoted string such as: "\\"realm\\"" which would end up as realm=""realm"" over the wire, with double double quotes.

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From michaelm at openjdk.java.net  Fri Oct 29 10:31:22 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 29 Oct 2021 10:31:22 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <mAu79Kvwe-cq2ciKSLmEUoCSXE9siLBCR9-vIyBn0WU=.21479330-6959-45a3-aac0-c3a38faaf3a2@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
 <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
 <5wcbXWPYPXXzvDPrUJmhHGYD4v8IVQrCTlT4P1LVjJA=.6f22fce4-750a-47bc-aa7f-d19fdd871aab@github.com>
 <mAu79Kvwe-cq2ciKSLmEUoCSXE9siLBCR9-vIyBn0WU=.21479330-6959-45a3-aac0-c3a38faaf3a2@github.com>
Message-ID: <IdQ-RDSGJ6DjXeG9vAUP9T-1vePcqVESD6Y6kfCCv3A=.5e294e7f-23e3-42fa-a475-fe656f52374f@github.com>

On Fri, 29 Oct 2021 10:12:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I still think it is too much of a corner case to impose on the API doc so much. How about changing the @throws to
>> 
>> 
>>       * @throws IllegalArgumentException if realm is an empty string or is not correctly
>>       *         escaped, as specified in <a href="https://tools.ietf.org/html/rfc7230#section-3.2">
>>       *         RFC 7230 section-3.2</a>.
>>  ```
>
> OK - but then I'd still say: `The value of the {@code realm} parameter will be embedded in a quoted string.`
> Otherwise the caller might think they need to provide a quoted string such as: "\\"realm\\"" which would end up as realm=""realm"" over the wire, with double double quotes.

Or how about this?

 * @throws IllegalArgumentException if realm is an empty string or is not correctly
 *         quoted, as specified in <a href="https://tools.ietf.org/html/rfc7230#section-3.2">
 *         RFC 7230 section-3.2</a>. Note, any {@code } character used for quoting must itself
 *         also be quoted in source code.

Would need to check the correct way to display a \ char. It possibly needs to be {@code \} for the same reason.

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From duke at openjdk.java.net  Fri Oct 29 11:29:23 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 29 Oct 2021 11:29:23 GMT
Subject: RFR: 8276166: Remove dead code from MimeTable and MimeEntry
Message-ID: <RYJWDTbIo89hHlADQJDNkPGyWmbJQtXgVaG0EB0HV5c=.dce60a4c-693d-487d-b9c1-e243ef2a569f@github.com>

There are unused methods/constructors in mentioned classes that can be safely removed.

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

Commit messages:
 - 8276166: Remove dead code from MimeTable and MimeEntry

Changes: https://git.openjdk.java.net/jdk/pull/6169/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6169&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276166
  Stats: 45 lines in 2 files changed: 0 ins; 41 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6169.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6169/head:pull/6169

PR: https://git.openjdk.java.net/jdk/pull/6169

From michaelm at openjdk.java.net  Fri Oct 29 11:31:13 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 29 Oct 2021 11:31:13 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <IdQ-RDSGJ6DjXeG9vAUP9T-1vePcqVESD6Y6kfCCv3A=.5e294e7f-23e3-42fa-a475-fe656f52374f@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
 <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
 <5wcbXWPYPXXzvDPrUJmhHGYD4v8IVQrCTlT4P1LVjJA=.6f22fce4-750a-47bc-aa7f-d19fdd871aab@github.com>
 <mAu79Kvwe-cq2ciKSLmEUoCSXE9siLBCR9-vIyBn0WU=.21479330-6959-45a3-aac0-c3a38faaf3a2@github.com>
 <IdQ-RDSGJ6DjXeG9vAUP9T-1vePcqVESD6Y6kfCCv3A=.5e294e7f-23e3-42fa-a475-fe656f52374f@github.com>
Message-ID: <tWA9gPwYijrs5peYYSH0ebYmoz47HoYDP4fys2mdNBU=.17e250ac-83e6-4f91-872e-5fd5dad2d6cf@github.com>

On Fri, 29 Oct 2021 10:28:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> OK - but then I'd still say: `The value of the {@code realm} parameter will be embedded in a quoted string.`
>> Otherwise the caller might think they need to provide a quoted string such as: "\\"realm\\"" which would end up as realm=""realm"" over the wire, with double double quotes.
>
> Or how about this?
> 
>  * @throws IllegalArgumentException if realm is an empty string or is not correctly
>  *         quoted, as specified in <a href="https://tools.ietf.org/html/rfc7230#section-3.2">
>  *         RFC 7230 section-3.2</a>. Note, any {@code } character used for quoting must itself
>  *         also be quoted in source code.
> 
> Would need to check the correct way to display a \ char. It possibly needs to be {@code \} for the same reason.

I agree with adding this as well. "The value of the {@code realm} parameter will be embedded in a quoted string"

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From jboes at openjdk.java.net  Fri Oct 29 12:51:23 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Fri, 29 Oct 2021 12:51:23 GMT
Subject: RFR: 8275534: com.sun.net.httpserver.BasicAuthenticator should
 check whether "realm" is a quoted string
In-Reply-To: <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
References: <EN7JsdDh_b_4kzkgIRLVuLUieFJBYd4EHH9X8UzIV7Q=.70980e39-e169-4281-9330-eec43072b075@github.com>
 <csAjXqjKwdNCJtKOeTK-PXSfJuhCbzsLVC_EcwekcyA=.8119c8e7-c01c-4461-a029-1ef110bcd257@github.com>
Message-ID: <5vS_h6oz3SCCtPPfowF7NPgNP0RZr1sy9Z-QdngY6yQ=.8250a77e-c85b-4765-976a-a9401e4248e6@github.com>

On Tue, 26 Oct 2021 13:56:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This change ensures that the realm string passed to the BasicAuthenticator constructor is a quoted-string, as per RFC7230 [1]. A Utils class is added to jdk.httpserver/sun.net.httpserver that holds the new isQuotedString() method and the pre-existing isValidName() method (previously in ServerImpl.) 
>> Two tests are included:
>> - BasicAuthenticatorRealm.java to check that Latin-1 chars in the realm string are transported correctly,
>> - BasicAuthenticatorExceptionCheck.java to check realm strings with escaped quotes.
>> 
>> Testing: tier 1-3.
>> 
>> [1] https://datatracker.ietf.org/doc/html/rfc7230
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java line 78:
> 
>> 76:     public static boolean isQuotedString(String token) {
>> 77:         for (int i = 0; i < token.length(); i++) {
>> 78:             char c = token.charAt(i);
> 
> For the value it would probably be more correct to work with the bytes returned by `getBytes(StandardCharsets.ISO_8859_1)` rather than with Java UTF-16 chars - I don't think UTF-16 is a super set of ISO-8859-1

As discussed offline, the string representations are identical < 256 so no need to transliterate.

for (int i=0; i<256; i++) { 
    var s16 = new String(new byte[] {(byte)0, (byte)i}, "UTF-16"); 
    var s88 = new String(new byte[] {(byte)i}, "ISO-8859-1"); 
    if (!s16.equals(s88)) throw new RuntimeException(""%s" != "%s"".formatted(s16, s88));
}

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

PR: https://git.openjdk.java.net/jdk/pull/6117

From amaembo at gmail.com  Thu Oct  7 03:30:26 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 07 Oct 2021 03:30:26 -0000
Subject: RFR: 8274835: Remove unnecessary castings in java.base
In-Reply-To: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
 <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>
Message-ID: <CAE+3fjZfERs6k-ETuoO3t68f1yz46L0kC9prUSFSyeKz6cLjeA@mail.gmail.com>

On Thu, Oct 7, 2021 at 12:15 AM Joe Darcy <darcy at openjdk.java.net> wrote:

> Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis.

Yes, our analysis is written independently of Javac (mostly by Anna
Kozlova) and we had a long history of false-positives/false-negatives
in this inspection, so it was tuned many times. It's not nearly
simple. For now, it's turned on for the whole IntelliJ IDEA Ultimate
repository (a warning causes the CI build to fail). I've found only
five explicit suppressions in our codebase. Not sure if all of them
are still necessary.

>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/5454

From richard.j.gibson at oracle.com  Fri Oct 29 13:44:04 2021
From: richard.j.gibson at oracle.com (Richard Gibson)
Date: Fri, 29 Oct 2021 13:44:04 +0000
Subject: improving java.net.UnknownHostException
Message-ID: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>

The OCI DNS team are fielding an increasing amount of usage by customers relying upon Java, and the lack of detail associated with java.net.UnknownHostException for differentiating e.g. timeout vs. NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost a great deal of time in investigating issues. Does anyone on this list know how to get the ball rolling on improving things?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211029/13706057/attachment.htm>

From fweimer at redhat.com  Fri Oct 29 14:41:08 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 29 Oct 2021 16:41:08 +0200
Subject: improving java.net.UnknownHostException
In-Reply-To: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 (Richard Gibson's message of "Fri, 29 Oct 2021 13:44:04 +0000")
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
Message-ID: <87bl37ki63.fsf@oldenburg.str.redhat.com>

* Richard Gibson:

> The OCI DNS team are fielding an increasing amount of usage by
> customers relying upon Java, and the lack of detail associated with
> java.net.UnknownHostException for differentiating e.g. timeout
> vs. NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost a great deal
> of time in investigating issues. Does anyone on this list know how to
> get the ball rolling on improving things?

Is this about the system resolver (via the high-level POSIX interfaces),
or the separate OpenJDK DNS implementation?

Thanks,
Florian


From daniel.fuchs at oracle.com  Fri Oct 29 15:00:43 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 29 Oct 2021 16:00:43 +0100
Subject: improving java.net.UnknownHostException
In-Reply-To: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
Message-ID: <70dafddf-1903-5a28-7cd2-6e24df5279e9@oracle.com>

Hi Richard,

Information about hosts that are embedded in exceptions
are often limited and constrained for security reason.
That said, possibly some more details could be included in
some circumstances, for instance, if allowed by the
jdk.includeInExceptions property.

The platform built-in resolver that performs name-to-address
resolution delegates to `getaddrinfo`. AFAICS `getaddrinfo` doesn't
seem to provide this level of granularity in the error codes
that it might return - though maybe distinguishing between
some of the errors it returns could be envisaged.

JEP 418 (https://openjdk.java.net/jeps/418) which
is in the proposed-to-target state for 18 defines a service-provider
interface (SPI) for host name and address resolution, so that 
java.net.InetAddress can make use of resolvers other than the
platform's built-in resolver.

Such resolvers might be able to provide more details as to
what caused UnknownHostException to be thrown.

best regards,

-- daniel



On 29/10/2021 14:44, Richard Gibson wrote:
> The OCI DNS team are fielding an increasing amount of usage by customers 
> relying upon Java, and the lack of detail associated with 
> java.net.UnknownHostException for differentiating e.g. timeout vs. 
> NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost a great deal of 
> time in investigating issues. Does anyone on this list know how to get 
> the ball?rolling on improving things?


From richard.j.gibson at oracle.com  Fri Oct 29 15:05:13 2021
From: richard.j.gibson at oracle.com (Richard Gibson)
Date: Fri, 29 Oct 2021 15:05:13 +0000
Subject: [External] : Re: improving java.net.UnknownHostException
In-Reply-To: <87bl37ki63.fsf@oldenburg.str.redhat.com>
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 <87bl37ki63.fsf@oldenburg.str.redhat.com>
Message-ID: <DS7PR10MB5184E1DE1F73D0807FA0F926B0879@DS7PR10MB5184.namprd10.prod.outlook.com>

Probably the OpenJDK implementation, which currently appears to return even less information than the famously-restrained getaddrinfo. But I'd love to see use of something better such as getdns if that is not already the case.


________________________________
From: Florian Weimer <fweimer at redhat.com>
Sent: Friday, October 29, 2021 10:41
To: Richard Gibson <richard.j.gibson at oracle.com>
Cc: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: [External] : Re: improving java.net.UnknownHostException

* Richard Gibson:

> The OCI DNS team are fielding an increasing amount of usage by
> customers relying upon Java, and the lack of detail associated with
> java.net.UnknownHostException for differentiating e.g. timeout
> vs. NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost a great deal
> of time in investigating issues. Does anyone on this list know how to
> get the ball rolling on improving things?

Is this about the system resolver (via the high-level POSIX interfaces),
or the separate OpenJDK DNS implementation?

Thanks,
Florian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211029/936bda34/attachment.htm>

From fweimer at redhat.com  Fri Oct 29 15:41:22 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 29 Oct 2021 17:41:22 +0200
Subject: [External] : Re: improving java.net.UnknownHostException
In-Reply-To: <DS7PR10MB5184E1DE1F73D0807FA0F926B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 (Richard Gibson's message of "Fri, 29 Oct 2021 15:05:13 +0000")
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 <87bl37ki63.fsf@oldenburg.str.redhat.com>
 <DS7PR10MB5184E1DE1F73D0807FA0F926B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
Message-ID: <874k8zkfdp.fsf@oldenburg.str.redhat.com>

* Richard Gibson:

> Probably the OpenJDK implementation, which currently appears to return
> even less information than the famously-restrained getaddrinfo. But
> I'd love to see use of something better such as getdns if that is not
> already the case.

Oh, I was asking about the other OpenJDK name lookup implementation, for
JNDI, in src/jdk.naming.dns/share/classes/com/sun/jndi/dns/Resolver.java.

Thanks,
Florian


From aefimov at openjdk.java.net  Fri Oct 29 16:17:46 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 29 Oct 2021 16:17:46 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v10]
In-Reply-To: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
Message-ID: <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>

> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
> 
> The following API classes are added to `java.net.spi` package to facilitate this:
> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
> 
> More details in [JEP-418](https://openjdk.java.net/jeps/418).
> 
> Testing: new and existing `tier1:tier3` tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Replace 'system' with 'the system-wide', move comment section

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5822/files
  - new: https://git.openjdk.java.net/jdk/pull/5822/files/2ca78ba9..f660cc6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=08-09

  Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822

PR: https://git.openjdk.java.net/jdk/pull/5822

From aefimov at openjdk.java.net  Fri Oct 29 16:17:51 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 29 Oct 2021 16:17:51 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v9]
In-Reply-To: <fw2tN1vI4v7XDWUcwDWuCEkMPd9gHszwarIjIi2pNMI=.5d28a2b6-838c-409b-8a2a-377269e75568@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <e_uvB3lkYcVgTjKRj_YUngXr9RT2v6tbrPUMjRSskqw=.cf076442-bb71-419c-bb02-f0ec8a80a646@github.com>
 <fw2tN1vI4v7XDWUcwDWuCEkMPd9gHszwarIjIi2pNMI=.5d28a2b6-838c-409b-8a2a-377269e75568@github.com>
Message-ID: <in62DPYR3EJyJHmnVB3pxSzgLd6Ne3PusXMazCxPEPk=.11b775c3-1350-4b45-ac9e-3f365922a640@github.com>

On Wed, 27 Oct 2021 16:23:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @ throws NPE to hosts file resolver javadoc
>
> src/java.base/share/classes/java/net/InetAddress.java line 841:
> 
>> 839:         // 'resolver.lookupByAddress' and 'InetAddress.getAllByName0' delegate to the system-wide resolver,
>> 840:         // which could be a custom one. At that point we treat any unexpected RuntimeException thrown by
>> 841:         // the resolver as we would treat an UnknownHostException or an unmatched host name.
> 
> indentation issue in comment above

Thanks - moved the comment block inside `catch` block (f660cc6ecc7a31c83de220160b9fd8d0fbacd1be)

> src/java.base/share/classes/java/net/InetAddress.java line 1308:
> 
>> 1306:      * Creates an InetAddress based on the provided host name and IP address.
>> 1307:      * System {@linkplain InetAddressResolver resolver} is not used to check
>> 1308:      * the validity of the address.
> 
> Is this term "system resolver" defined somewhere? I think it means the configured resolver for the current VM. Previously, it really was the system resolver. So, I think it's potentially confusing, as there is also reference to the java.net.preferIPv6Addresses system property as having a possible value "system" which refers to the operating system. Since the CSR is approved, I'm happy to discuss this point post integration.

Thanks for highlighting that: Changed `"system"` to `"the system-wide"` - that's what was originally meant by `"system resolver"` (f660cc6ecc7a31c83de220160b9fd8d0fbacd1be).

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From dfuchs at openjdk.java.net  Fri Oct 29 16:28:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 29 Oct 2021 16:28:16 GMT
Subject: RFR: 8244202: Implementation of JEP 418: Internet-Address
 Resolution SPI [v10]
In-Reply-To: <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>
References: <tdZ2K-TO6ZFqaTHtvVYxOJOgnsHkjM5qh7Q-p-6HRik=.e8dd5a6e-b493-4c9a-bbc1-17803fbfbe2e@github.com>
 <wYHudTZS5moCO2RAeS4_UMhpxc6gbBF6evl3ZoE4q8w=.f9142ae2-aba7-4d91-985e-52e219dd2132@github.com>
Message-ID: <wKCFBv1uFCM0-LKR0sZ3XKsF9ikJGCGa5c5-JwX0TRk=.50646f60-003c-4e1c-a82b-32ca0a133540@github.com>

On Fri, 29 Oct 2021 16:17:46 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This change implements a new service provider interface for host name and address resolution, so that java.net.InetAddress API can make use of resolvers other than the platform's built-in resolver.
>> 
>> The following API classes are added to `java.net.spi` package to facilitate this:
>> - `InetAddressResolverProvider` -  abstract class defining a service, and is, essentially, a factory for `InetAddressResolver` resolvers.
>> - `InetAddressResolverProvider.Configuration ` - an interface describing the platform's built-in configuration for resolution operations that could be used to bootstrap a resolver construction, or to implement partial delegation of lookup operations.
>> - `InetAddressResolver` - an interface that defines methods for the fundamental forward and reverse lookup operations.
>> - `InetAddressResolver.LookupPolicy` - a class whose instances describe the characteristics of one forward lookup operation.  
>> 
>> More details in [JEP-418](https://openjdk.java.net/jeps/418).
>> 
>> Testing: new and existing `tier1:tier3` tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace 'system' with 'the system-wide', move comment section

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5822

From richard.j.gibson at oracle.com  Fri Oct 29 17:11:19 2021
From: richard.j.gibson at oracle.com (Richard Gibson)
Date: Fri, 29 Oct 2021 17:11:19 +0000
Subject: [External] : Re: improving java.net.UnknownHostException
In-Reply-To: <874k8zkfdp.fsf@oldenburg.str.redhat.com>
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 <87bl37ki63.fsf@oldenburg.str.redhat.com>
 <DS7PR10MB5184E1DE1F73D0807FA0F926B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 <874k8zkfdp.fsf@oldenburg.str.redhat.com>
Message-ID: <DS7PR10MB518451E0EB9FC17E13FD1428B0879@DS7PR10MB5184.namprd10.prod.outlook.com>

Oh, I'm not familiar with that so I don't know.
________________________________
From: Florian Weimer <fweimer at redhat.com>
Sent: Friday, October 29, 2021 11:41
To: Richard Gibson <richard.j.gibson at oracle.com>
Cc: net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: Re: [External] : Re: improving java.net.UnknownHostException

* Richard Gibson:

> Probably the OpenJDK implementation, which currently appears to return
> even less information than the famously-restrained getaddrinfo. But
> I'd love to see use of something better such as getdns if that is not
> already the case.

Oh, I was asking about the other OpenJDK name lookup implementation, for
JNDI, in src/jdk.naming.dns/share/classes/com/sun/jndi/dns/Resolver.java.

Thanks,
Florian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211029/510795d4/attachment-0001.htm>

From Alan.Bateman at oracle.com  Fri Oct 29 19:10:09 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 29 Oct 2021 20:10:09 +0100
Subject: improving java.net.UnknownHostException
In-Reply-To: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
Message-ID: <b2ce1a42-0305-bda6-a81d-49df3b393a80@oracle.com>

On 29/10/2021 14:44, Richard Gibson wrote:
> The OCI DNS team are fielding an increasing amount of usage by 
> customers relying upon Java, and the lack of detail associated with 
> java.net.UnknownHostException for differentiating e.g. timeout vs. 
> NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost a great deal of 
> time in investigating issues. Does anyone on this list know how to get 
> the ball?rolling on improving things?
I will guess that these customers are using the InetAddress API which 
will use getaddrinfo and maybe too high level for what you are looking 
for. If getaddrinfo fails then the gai_strerror is used to get the error 
description. As Daniel points out, there is a service provider interface 
in the work (JEP 416) that will allow deploying alternative underlying 
resolver implementations. This may be a possible direction to explore if 
you really want fine control on the DNS lookups.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20211029/c23d4bfd/attachment.htm>

From fweimer at redhat.com  Fri Oct 29 19:50:48 2021
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 29 Oct 2021 21:50:48 +0200
Subject: improving java.net.UnknownHostException
In-Reply-To: <70dafddf-1903-5a28-7cd2-6e24df5279e9@oracle.com> (Daniel Fuchs's
 message of "Fri, 29 Oct 2021 16:00:43 +0100")
References: <DS7PR10MB51846E74B7CBFD8952AC98B1B0879@DS7PR10MB5184.namprd10.prod.outlook.com>
 <70dafddf-1903-5a28-7cd2-6e24df5279e9@oracle.com>
Message-ID: <87v91fhap3.fsf@oldenburg.str.redhat.com>

* Daniel Fuchs:

> The platform built-in resolver that performs name-to-address
> resolution delegates to `getaddrinfo`. AFAICS `getaddrinfo` doesn't
> seem to provide this level of granularity in the error codes
> that it might return - though maybe distinguishing between
> some of the errors it returns could be envisaged.

I know that glibc has some issues with error reporting from the
low-level libresolv functions.  We can probably improve the situation
somewhat for cases that people actually encounter.  The DNS interface
has limits, though?if the recursive resolver cannot get data, queries
fail with SERVFAIL.  With glibc, timeouts usually mean that the network
between the host and its recursive resolver is down.  The glibc timeouts
are far longer than those of a typical recursive resolver, so the latter
gives up and produces the SERVFAIL error.

Thanks,
Florian


From duke at openjdk.java.net  Sun Oct 31 07:47:14 2021
From: duke at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sun, 31 Oct 2021 07:47:14 GMT
Subject: RFR: 8262442 (windows) use all proxy configuration sources when
 java.net.useSystemProxies=true
In-Reply-To: <LYXzqyYxDU2OLZ1YyyvWnvsH2OJDkRqNv4Pp2UPQgr4=.37b73580-1c60-4177-b89f-664d6efe6436@github.com>
References: <LYXzqyYxDU2OLZ1YyyvWnvsH2OJDkRqNv4Pp2UPQgr4=.37b73580-1c60-4177-b89f-664d6efe6436@github.com>
Message-ID: <KhNkZ6CsKoiiVStfturWGCSEOaZFzlEErqfpWLMwkVE=.b76de1f1-bd54-4b4e-b4c0-462487be44eb@github.com>

On Mon, 18 Oct 2021 19:25:12 GMT, Daniel Jeli?ski <duke at openjdk.java.net> wrote:

> With this patch DefaultProxySelector first attempts to use proxy config autodetection (http://wpad/wpad.dat) when that is configured and available.
> If proxy config autodetection is unavailable, selector tries to use configured proxy script (again, if configured and available)
> If both the above options fail, selector uses the configured proxy.
> 
> Verified on Windows 10 that:
> - when `fAutoDetect` is true, http://wpad/wpad.dat refers to an existing file, the file has correct syntax and returns a proxy, that proxy is used
> - when `fAutoDetect` is true, but the autoconfig file is not available / unusable for any reason, selector fails over to the next configured method
> - when `lpszAutoConfigUrl` is set and usable, the proxy returned is used
> - when `lpszAutoConfigUrl` is not set or unusable, selector fails over to next method
> - when `lpszProxy` is configured, that proxy is used
> - otherwise selector uses direct connection
> 
> The proxy configuration scripts are cached on system level, so testing (alternating between good and broken autoconfig script) may require waiting for the caches to invalidate.

No automatic tests; to test this manually I used 2 proxy autoconfig files of form:

function FindProxyForURL(url, host) {
  if (url.includes("example")) {
    return "PROXY 10.4.5.6:8192";
  } else {
    return "DIRECT";
  }
}

one named `wpad.dat`, other named `proxy.pac`, returning different proxy addresses so that I could figure out which one was used. These files were served by a http server running on localhost, conveniently set up with `python -m http.server 80`.
Next, I added the following line to `c:\Windows\System32\drivers\etc\hosts`:

127.0.0.1 wpad

Next, I used the little Java program found in [JDK-8262442](https://bugs.openjdk.java.net/browse/JDK-8262442) to test what ProxySelector returned with different combinations of proxy configuration options.

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

PR: https://git.openjdk.java.net/jdk/pull/5995