From ccleary at openjdk.java.net  Thu Oct  1 07:50:45 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 1 Oct 2020 07:50:45 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
Message-ID: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>

This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).

Some justifications for this change are as follows:

- Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
  memory neighborhood)
- Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
- While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
  infrequent/non-existent in this case.

Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
LinkedLists in this scenario.

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

Commit messages:
 - 8253179: Replace LinkedList Impl in net.http.Http2Connection

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

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

From shade at openjdk.java.net  Thu Oct  1 08:25:26 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 1 Oct 2020 08:25:26 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
In-Reply-To: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
Message-ID: <sPbkBH55yEjnFGPXn3nuLvw9lXP4BAmXQZhR_9OuHes=.fdcd0e37-2edc-4449-93ac-5c50cd23994c@github.com>

On Wed, 30 Sep 2020 10:22:11 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
> 
> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>   memory neighborhood)
> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>   infrequent/non-existent in this case.
> 
> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
> LinkedLists in this scenario.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 703:

> 701:         if (initialCause == null) this.cause = t;
> 702:         client2.deleteConnection(this);
> 703:         List<Stream<?>> c = new ArrayList<>(streams.values());

Why can't we dispense with this copy completely, and instead just iterate `streams.values()`?

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

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

From dfuchs at openjdk.java.net  Thu Oct  1 09:46:10 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 1 Oct 2020 09:46:10 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
In-Reply-To: <sPbkBH55yEjnFGPXn3nuLvw9lXP4BAmXQZhR_9OuHes=.fdcd0e37-2edc-4449-93ac-5c50cd23994c@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <sPbkBH55yEjnFGPXn3nuLvw9lXP4BAmXQZhR_9OuHes=.fdcd0e37-2edc-4449-93ac-5c50cd23994c@github.com>
Message-ID: <Z2f1hHxwyyH8E9ULklbGnc6NNXvY1hxlPbvg7m9cpzY=.036e1a22-550c-432a-a3c9-7b9e49a25698@github.com>

On Thu, 1 Oct 2020 08:22:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
>> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
>> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
>> 
>> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>>   memory neighborhood)
>> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
>> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>>   infrequent/non-existent in this case.
>> 
>> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
>> LinkedLists in this scenario.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 703:
> 
>> 701:         if (initialCause == null) this.cause = t;
>> 702:         client2.deleteConnection(this);
>> 703:         List<Stream<?>> c = new ArrayList<>(streams.values());
> 
> Why can't we dispense with this copy completely, and instead just iterate `streams.values()`?

Good point Aleksey. I guess that the original intent was to avoid `ConcurrentModificationException`. However I see that
`streams` is a `ConcurrentHashMap` now. So maybe we could dispense of the copy:

`    private final Map<Integer,Stream<?>> streams = new ConcurrentHashMap<>();`

Could be worth changing the type from `Map<Integer,Stream<?>>` to `ConcurrentMap<Integer,Stream<?>>` in the declaration
above if we decide to get rid of the copy though.

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

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

From ccleary at openjdk.java.net  Thu Oct  1 10:34:27 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 1 Oct 2020 10:34:27 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
In-Reply-To: <Z2f1hHxwyyH8E9ULklbGnc6NNXvY1hxlPbvg7m9cpzY=.036e1a22-550c-432a-a3c9-7b9e49a25698@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <sPbkBH55yEjnFGPXn3nuLvw9lXP4BAmXQZhR_9OuHes=.fdcd0e37-2edc-4449-93ac-5c50cd23994c@github.com>
 <Z2f1hHxwyyH8E9ULklbGnc6NNXvY1hxlPbvg7m9cpzY=.036e1a22-550c-432a-a3c9-7b9e49a25698@github.com>
Message-ID: <GvetEq59Ml6f653RwUm55NEXEOK5F5SkDfmJTd7kBNk=.9e915515-1752-40d9-883a-94dce1768a1d@github.com>

On Thu, 1 Oct 2020 09:43:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 703:
>> 
>>> 701:         if (initialCause == null) this.cause = t;
>>> 702:         client2.deleteConnection(this);
>>> 703:         List<Stream<?>> c = new ArrayList<>(streams.values());
>> 
>> Why can't we dispense with this copy completely, and instead just iterate `streams.values()`?
>
> Good point Aleksey. I guess that the original intent was to avoid `ConcurrentModificationException`. However I see that
> `streams` is a `ConcurrentHashMap` now. So maybe we could dispense of the copy:
> `    private final Map<Integer,Stream<?>> streams = new ConcurrentHashMap<>();`
> 
> Could be worth changing the type from `Map<Integer,Stream<?>>` to `ConcurrentMap<Integer,Stream<?>>` in the declaration
> above if we decide to get rid of the copy though.

Taking a look at this presently

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

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

From prappo at openjdk.java.net  Thu Oct  1 10:43:23 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 1 Oct 2020 10:43:23 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
In-Reply-To: <GvetEq59Ml6f653RwUm55NEXEOK5F5SkDfmJTd7kBNk=.9e915515-1752-40d9-883a-94dce1768a1d@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <sPbkBH55yEjnFGPXn3nuLvw9lXP4BAmXQZhR_9OuHes=.fdcd0e37-2edc-4449-93ac-5c50cd23994c@github.com>
 <Z2f1hHxwyyH8E9ULklbGnc6NNXvY1hxlPbvg7m9cpzY=.036e1a22-550c-432a-a3c9-7b9e49a25698@github.com>
 <GvetEq59Ml6f653RwUm55NEXEOK5F5SkDfmJTd7kBNk=.9e915515-1752-40d9-883a-94dce1768a1d@github.com>
Message-ID: <wLaShSuYAFG_cNpsRS4MMSJHPrQ50Ddfxxr_KXfIZ3U=.e9f0d74b-cddc-436e-a818-f715b3f34804@github.com>

On Thu, 1 Oct 2020 10:31:58 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Good point Aleksey. I guess that the original intent was to avoid `ConcurrentModificationException`. However I see that
>> `streams` is a `ConcurrentHashMap` now. So maybe we could dispense of the copy:
>> `    private final Map<Integer,Stream<?>> streams = new ConcurrentHashMap<>();`
>> 
>> Could be worth changing the type from `Map<Integer,Stream<?>>` to `ConcurrentMap<Integer,Stream<?>>` in the declaration
>> above if we decide to get rid of the copy though.
>
> Taking a look at this presently

Although Aleksey's proposal does not change the behavior, it raises a question (to be explored separately): can a
stream be added to that map while `Http2Connection.shutdown` is in progress? If this is the case, then the method is
racy.

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

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

From dfuchs at openjdk.java.net  Thu Oct  1 10:58:49 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 1 Oct 2020 10:58:49 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
In-Reply-To: <wLaShSuYAFG_cNpsRS4MMSJHPrQ50Ddfxxr_KXfIZ3U=.e9f0d74b-cddc-436e-a818-f715b3f34804@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <sPbkBH55yEjnFGPXn3nuLvw9lXP4BAmXQZhR_9OuHes=.fdcd0e37-2edc-4449-93ac-5c50cd23994c@github.com>
 <Z2f1hHxwyyH8E9ULklbGnc6NNXvY1hxlPbvg7m9cpzY=.036e1a22-550c-432a-a3c9-7b9e49a25698@github.com>
 <GvetEq59Ml6f653RwUm55NEXEOK5F5SkDfmJTd7kBNk=.9e915515-1752-40d9-883a-94dce1768a1d@github.com>
 <wLaShSuYAFG_cNpsRS4MMSJHPrQ50Ddfxxr_KXfIZ3U=.e9f0d74b-cddc-436e-a818-f715b3f34804@github.com>
Message-ID: <W7JFyfYSaCWQ8HAo4_tgWU3pPJBfidPAYIvjGdVzDhM=.bb89d74f-3c1d-448d-8a8f-4bbb5065ef45@github.com>

On Thu, 1 Oct 2020 10:38:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Taking a look at this presently
>
> Although Aleksey's proposal does not change the behavior, it raises a question (to be explored separately): can a
> stream be added to that map while `Http2Connection.shutdown` is in progress? If this is the case, then the method is
> racy.

Even if that happened , it should not matter as the connection will be (or is) closed anyway. I don't believe that's
the kind of scenario that the copy was trying to prevent. Closing a stream will definitely remove it from the map
though, so my guess that is where the CME would happen if no precaution was taken.

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

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

From pconcannon at openjdk.java.net  Thu Oct  1 10:59:51 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 1 Oct 2020 10:59:51 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v3]
In-Reply-To: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
Message-ID: <6UMV1z0rWyGeN_bTMGP8gy0YnORrU9cDsqRiMed9UAc=.793e09ac-d66c-4c34-be6e-94085efe64fc@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.Filter`
> `com.sun.net.httpserver.Filter.Chain`
> `com.sun.net.httpserver.Headers`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 two additional commits
since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253470
 - 8253470: Javadoc clean up in Filter and Headers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/429/files
  - new: https://git.openjdk.java.net/jdk/pull/429/files/bfff3c86..66d628fd

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

  Stats: 6798 lines in 1446 files changed: 1875 ins; 1003 del; 3920 mod
  Patch: https://git.openjdk.java.net/jdk/pull/429.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/429/head:pull/429

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

From pconcannon at openjdk.java.net  Thu Oct  1 12:03:04 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 1 Oct 2020 12:03:04 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
Message-ID: <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.Filter`
> `com.sun.net.httpserver.Filter.Chain`
> `com.sun.net.httpserver.Headers`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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:

 - 8253470: further formatting changes added
 - Merge remote-tracking branch 'origin/master' into JDK-8253470
 - Merge remote-tracking branch 'origin/master' into JDK-8253470
 - 8253470: Javadoc clean up in Filter and Headers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/429/files
  - new: https://git.openjdk.java.net/jdk/pull/429/files/66d628fd..4de7e6ca

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

  Stats: 124 lines in 24 files changed: 45 ins; 9 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/429.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/429/head:pull/429

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

From pconcannon at openjdk.java.net  Thu Oct  1 12:03:19 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 1 Oct 2020 12:03:19 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <_rNGMoSEdBmCspiPoRHkLEah0LG1TcuE9SJ1DpVhjlQ=.0db667bf-a2be-4e6b-bf4a-d9ef54d9a888@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <_rNGMoSEdBmCspiPoRHkLEah0LG1TcuE9SJ1DpVhjlQ=.0db667bf-a2be-4e6b-bf4a-d9ef54d9a888@github.com>
Message-ID: <YY_e_zRlGzCO00mBHRjjZdiQGcWRRw3acQpZ2dr3MhM=.2d53f343-5e40-408e-a089-9188912bd2f4@github.com>

On Wed, 30 Sep 2020 10:21:22 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 four additional commits
>> since the last revision:
>>  - 8253470: further formatting changes added
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>>  - 8253470: Javadoc clean up in Filter and Headers
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 40:
> 
>> 38:  * are organised in chains, and are associated with {@link HttpContext} instances.
>> 39:  *
>> 40:  * <p> Each Filter in the chain, invokes the next filter within its own
> 
> Here `Each Filter` should be either `Each filter` or `Each {@code Filter}`

Change made in commit 4de7e6c - `Each Filter` --> `Each {@code Filter}`

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 41:
> 
>> 39:  *
>> 40:  * <p> Each Filter in the chain, invokes the next filter within its own
>> 41:  * {@link #doFilter(HttpExchange, Chain)} implementation. The final Filter in
> 
> Same here for `the final Filter` - should be either `the final filter` or `the final {@code Filter}`

Change made in commit 4de7e6c - `the final Filter` --> `the final {@code Filter}`

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 109:
> 
>> 107:      *     <li> Filter the request body or the response body, by creating suitable
>> 108:      *     filter streams and calling {@link HttpExchange#setStreams(InputStream, OutputStream)}.
>> 109:      *     <li> Set attribute Objects in the exchange, which other filters or
> 
> `Set attribute objects` ...

Change made in commit 4de7e6c

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 62:
> 
>> 60:  *     <li>{@link #add(String,String)} adds the given header value to the list for the given key
>> 61:  *     <li>{@link #set(String,String)} sets the given header field to the single value given
>> 62:  *     overwriting any existing values in the value list
> 
> For consistency, either:
>   - no item should end with a punctuation sign
>   - or all of them should end with a coma, except the last that should end with a full stop.
>   - or all of them should end with a full stop.
> 
> I am not sure what is the best, but it is weird that the first item ends with a full stop and the other two don't.

Change made in commit 4de7e6c - all lines now end with a full stop

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

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

From pconcannon at openjdk.java.net  Thu Oct  1 12:03:11 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 1 Oct 2020 12:03:11 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <1ZHBJcDk98o4QCKl3ke-2fByYX7TgR7Sa968xRudz30=.ba984f61-04be-460c-8825-3e822874bf62@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <1ZHBJcDk98o4QCKl3ke-2fByYX7TgR7Sa968xRudz30=.ba984f61-04be-460c-8825-3e822874bf62@github.com>
Message-ID: <tR7vMvH84XIC5_-0Y_XPqDqOGb57rqBXBKmL5_58AL8=.f76de85f-ce0b-4da9-b38d-4bd2d094a0d4@github.com>

On Wed, 30 Sep 2020 10:31:29 GMT, Michael McMahon <michaelm 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 four additional commits
>> since the last revision:
>>  - 8253470: further formatting changes added
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>>  - 8253470: Javadoc clean up in Filter and Headers
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 61:
> 
>> 59:
>> 60:         /**
>> 61:          * The last element in the chain must invoke the users
> 
> invoke the users -> invoke the user's

Change made in commit https://github.com/openjdk/jdk/pull/429/commits/4de7e6cac8681914f94c407b032fb8c1cb172828

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 53:
> 
>> 51:  * HeaderName: value2
>> 52:  * </pre></blockquote>
>> 53:  *
> 
> The lines in the list look very long. Might be better to reformat to keep lines less than 80 chars (or whatever the
> limit is supposed to be).

Change made in commit 4de7e6c - reduced line length to 80 chars

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

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

From dfuchs at openjdk.java.net  Thu Oct  1 14:19:07 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 1 Oct 2020 14:19:07 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
Message-ID: <Pf7D_eD_GQZYL7Sbey-oOEjJb8eLkkjZ4VWC5z7kGvY=.49d80d08-7241-4882-a762-695d16b8503e@github.com>

On Thu, 1 Oct 2020 12:03:04 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.Filter`
>> `com.sun.net.httpserver.Filter.Chain`
>> `com.sun.net.httpserver.Headers`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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:
>  - 8253470: further formatting changes added
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: Javadoc clean up in Filter and Headers

Marked as reviewed by dfuchs (Reviewer).

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

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

From michaelm at openjdk.java.net  Thu Oct  1 14:31:05 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 1 Oct 2020 14:31:05 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
Message-ID: <ZJycHKVIvkXnEK0yEq5Tj5DGy_PZgfXr5zgHPM0aH68=.b6fea5c5-4581-4eec-8ed0-5722d53cf635@github.com>

On Thu, 1 Oct 2020 12:03:04 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.Filter`
>> `com.sun.net.httpserver.Filter.Chain`
>> `com.sun.net.httpserver.Headers`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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:
>  - 8253470: further formatting changes added
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: Javadoc clean up in Filter and Headers

Changes requested by michaelm (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 40:

> 38:  * are organised in chains, and are associated with {@link HttpContext} instances.
> 39:  *
> 40:  * <p> Each {@Filter} in the chain, invokes the next filter within its own

@Filter Is that supposed to be {@code Filter} or {@link Filter}?

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

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

From dfuchs at openjdk.java.net  Thu Oct  1 15:46:06 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 1 Oct 2020 15:46:06 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
Message-ID: <C7dU96zcpT9X26I2JGZPrCEMUVxd8t4AVFQO7Nz9VVM=.b1892dee-05d7-47bf-a820-b56c0581e3f0@github.com>

On Thu, 1 Oct 2020 12:03:04 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.Filter`
>> `com.sun.net.httpserver.Filter.Chain`
>> `com.sun.net.httpserver.Headers`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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:
>  - 8253470: further formatting changes added
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: Javadoc clean up in Filter and Headers

Changes requested by dfuchs (Reviewer).

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

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

From dfuchs at openjdk.java.net  Thu Oct  1 15:46:08 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 1 Oct 2020 15:46:08 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <ZJycHKVIvkXnEK0yEq5Tj5DGy_PZgfXr5zgHPM0aH68=.b6fea5c5-4581-4eec-8ed0-5722d53cf635@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
 <ZJycHKVIvkXnEK0yEq5Tj5DGy_PZgfXr5zgHPM0aH68=.b6fea5c5-4581-4eec-8ed0-5722d53cf635@github.com>
Message-ID: <EWi6u73_wfvRzdTxCvspNq0TQ3Al6ya7ycj0LGZtRA8=.2068f98f-ea50-406c-adf9-5ac1eb56e492@github.com>

On Thu, 1 Oct 2020 14:27:10 GMT, Michael McMahon <michaelm 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 four additional commits
>> since the last revision:
>>  - 8253470: further formatting changes added
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>>  - 8253470: Javadoc clean up in Filter and Headers
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 40:
> 
>> 38:  * are organised in chains, and are associated with {@link HttpContext} instances.
>> 39:  *
>> 40:  * <p> Each {@Filter} in the chain, invokes the next filter within its own
> 
> @Filter Is that supposed to be {@code Filter} or {@link Filter}?

Ah! I missed that. Well spotted Michael. Should be `{@code Filter}` of course.

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

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

From ccleary at openjdk.java.net  Fri Oct  2 08:41:56 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 2 Oct 2020 08:41:56 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
Message-ID: <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>

> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
> 
> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>   memory neighborhood)
> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>   infrequent/non-existent in this case.
> 
> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
> LinkedLists in this scenario.

Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:

  8253179: Removed ArrayList copy of streams

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/431/files
  - new: https://git.openjdk.java.net/jdk/pull/431/files/9ecb85ea..fc3f574d

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

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

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

From ccleary at openjdk.java.net  Fri Oct  2 08:45:45 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 2 Oct 2020 08:45:45 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
Message-ID: <vB612b7KqMetr2Onxd37Xt8jKqYZHzyFsq9EN0SzWrM=.7430d042-abd4-4171-8341-bef02f73c3b4@github.com>

On Fri, 2 Oct 2020 08:41:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
>> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
>> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
>> 
>> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>>   memory neighborhood)
>> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
>> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>>   infrequent/non-existent in this case.
>> 
>> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
>> LinkedLists in this scenario.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253179: Removed ArrayList copy of streams

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 704:

> 702:         client2.deleteConnection(this);
> 703:         for (Stream<?> s : streams.values()) {
> 704:             try {

To address some of the feedback given, the streams  are now directly addressed instead of making a copy.  ConcurrentMap
has also been used to initialise streams instead of Map. Seeking feedback/opinions on this if possible

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

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

From pconcannon at openjdk.java.net  Fri Oct  2 08:52:53 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 2 Oct 2020 08:52:53 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v5]
In-Reply-To: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
Message-ID: <kYhfuiGn0viag4N6zIj1iMmi4dblE_fAqMc78oKNK84=.ed1c6ab4-67bd-4424-b83d-3fad845aae36@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.Filter`
> `com.sun.net.httpserver.Filter.Chain`
> `com.sun.net.httpserver.Headers`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 six additional commits
since the last revision:

 - Fixed typos in com/sun/net/httpserver/Filter
 - Merge remote-tracking branch 'origin/master' into JDK-8253470
 - 8253470: further formatting changes added
 - Merge remote-tracking branch 'origin/master' into JDK-8253470
 - Merge remote-tracking branch 'origin/master' into JDK-8253470
 - 8253470: Javadoc clean up in Filter and Headers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/429/files
  - new: https://git.openjdk.java.net/jdk/pull/429/files/4de7e6ca..c4a65483

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

  Stats: 2323 lines in 35 files changed: 730 ins; 1293 del; 300 mod
  Patch: https://git.openjdk.java.net/jdk/pull/429.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/429/head:pull/429

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

From dfuchs at openjdk.java.net  Fri Oct  2 09:02:41 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 2 Oct 2020 09:02:41 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v5]
In-Reply-To: <kYhfuiGn0viag4N6zIj1iMmi4dblE_fAqMc78oKNK84=.ed1c6ab4-67bd-4424-b83d-3fad845aae36@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <kYhfuiGn0viag4N6zIj1iMmi4dblE_fAqMc78oKNK84=.ed1c6ab4-67bd-4424-b83d-3fad845aae36@github.com>
Message-ID: <QKJ6ottgVU8t-52qcD3xHs9MXan21RtMGNY_y41nvk8=.7c5daae8-78ba-4038-bbe1-5145222f3513@github.com>

On Fri, 2 Oct 2020 08:52:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.Filter`
>> `com.sun.net.httpserver.Filter.Chain`
>> `com.sun.net.httpserver.Headers`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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 six additional commits
> since the last revision:
>  - Fixed typos in com/sun/net/httpserver/Filter
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: further formatting changes added
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: Javadoc clean up in Filter and Headers

Marked as reviewed by dfuchs (Reviewer).

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

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

From pconcannon at openjdk.java.net  Fri Oct  2 09:02:42 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 2 Oct 2020 09:02:42 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v4]
In-Reply-To: <EWi6u73_wfvRzdTxCvspNq0TQ3Al6ya7ycj0LGZtRA8=.2068f98f-ea50-406c-adf9-5ac1eb56e492@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <FX-jzqyRLCPYrqfXnzTBLKq2LXqq913dK3D2VoHvKR0=.cd8369ef-8234-44be-bee1-c6033fdd46df@github.com>
 <ZJycHKVIvkXnEK0yEq5Tj5DGy_PZgfXr5zgHPM0aH68=.b6fea5c5-4581-4eec-8ed0-5722d53cf635@github.com>
 <EWi6u73_wfvRzdTxCvspNq0TQ3Al6ya7ycj0LGZtRA8=.2068f98f-ea50-406c-adf9-5ac1eb56e492@github.com>
Message-ID: <R_zP9fP_ecR3cd8V_EYWIgWMVVjTIwsIk6AF4koiHIo=.637d0987-0e04-474a-bae8-1433115d4ea7@github.com>

On Thu, 1 Oct 2020 15:43:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 40:
>> 
>>> 38:  * are organised in chains, and are associated with {@link HttpContext} instances.
>>> 39:  *
>>> 40:  * <p> Each {@Filter} in the chain, invokes the next filter within its own
>> 
>> @Filter Is that supposed to be {@code Filter} or {@link Filter}?
>
> Ah! I missed that. Well spotted Michael. Should be `{@code Filter}` of course.

Thanks for spotting this, Michael. I've rectified this in the latest commit
(https://github.com/openjdk/jdk/pull/429/commits/c4a654832e81740543313e2a86a245865f3283b9).

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

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

From michaelm at openjdk.java.net  Fri Oct  2 11:07:59 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 11:07:59 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v12]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <JJ4LdK57Ydn6L4KN4NWX-LEKvWPHu0DJZnwK0HE2OjU=.033af211-900d-4e8c-aa90-f327d79b4f1c@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels:
  (1) rename UnixDomainHelper to UnixDomainSocketsUtil
  (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
  (3) replace (2) with documented system/networking properties
  (4) Small update to UnixDomainSocketAddress API
  (5) CSR for (3) and (4) submitted at JDK-8253930
  (6) Update build to generate net.properties from shared net.properties.common
      plus platform specific additions.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/c40d2059..275e0928

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=10-11

  Stats: 357 lines in 10 files changed: 194 ins; 154 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Fri Oct  2 11:11:42 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 11:11:42 GMT
Subject: RFR: 8253470: Javadoc clean up in Filter and Headers [v5]
In-Reply-To: <kYhfuiGn0viag4N6zIj1iMmi4dblE_fAqMc78oKNK84=.ed1c6ab4-67bd-4424-b83d-3fad845aae36@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
 <kYhfuiGn0viag4N6zIj1iMmi4dblE_fAqMc78oKNK84=.ed1c6ab4-67bd-4424-b83d-3fad845aae36@github.com>
Message-ID: <0Ezb-JXSuxtclX8_a8gIURdjJDBWDINw0dnFXcefPJs=.8780e124-fa69-472e-8468-fe3b221676ff@github.com>

On Fri, 2 Oct 2020 08:52:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.Filter`
>> `com.sun.net.httpserver.Filter.Chain`
>> `com.sun.net.httpserver.Headers`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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 six additional commits
> since the last revision:
>  - Fixed typos in com/sun/net/httpserver/Filter
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: further formatting changes added
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - Merge remote-tracking branch 'origin/master' into JDK-8253470
>  - 8253470: Javadoc clean up in Filter and Headers

Marked as reviewed by michaelm (Reviewer).

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

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

From michaelm at openjdk.java.net  Fri Oct  2 11:28:49 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 11:28:49 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/275e0928..dc70cd6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=11-12

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

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

From pconcannon at openjdk.java.net  Fri Oct  2 12:09:43 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 2 Oct 2020 12:09:43 GMT
Subject: Integrated: 8253470: Javadoc clean up in Filter and Headers
In-Reply-To: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
References: <UKLoay7Yl2ZHPZV2rxtU2urBW06frA32h6EHdnbiVIs=.3b11ae34-09a8-4718-88f5-4b69da44db23@github.com>
Message-ID: <n5XLMJBVZMj-r4oYt7cJ5oGdzTeM4daxcUQ8LSQU0Ys=.a9e1039f-bcf0-4b62-a060-ba6018b2ba9d@github.com>

On Wed, 30 Sep 2020 10:02:06 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253470 - 'Javadoc clean up in Filter and Headers' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.Filter`
> `com.sun.net.httpserver.Filter.Chain`
> `com.sun.net.httpserver.Headers`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 0fd41c3b
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fd41c3b
Stats:     125 lines in 2 files changed: 43 ins; 16 del; 66 mod

8253470: Javadoc clean up in Filter and Headers

Reviewed-by: dfuchs, michaelm

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

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

From erikj at openjdk.java.net  Fri Oct  2 13:05:41 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 2 Oct 2020 13:05:41 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
Message-ID: <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>

On Fri, 2 Oct 2020 11:28:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk

make/modules/java.base/Copy.gmk line 190:

> 188: NET_PROPERTIES_SRC +=
> $(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/net.properties.$(OPENJDK_TARGET_OS_TYPE) 189:
> 190: NET_PROPERTIES_SRC_LIST := $(NET_PROPERTIES_SRC)

This variable seems unnecessary as it's just a copy of NET_PROPERTIES_SRC. I would suggest just adding an S for plural
to the original variable.

make/modules/java.base/Copy.gmk line 195:

> 193: 	$(call MakeTargetDir)
> 194: 	$(RM) $@ $@.tmp
> 195: 	$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)

This can be simplified. Cat takes multiple files as input, so no need for 'foreach'. Also no need to go via a temp
file. We have make configured to delete targets if a recipe fails, so the tmp dance isn't needed. (I know we still have
this pattern all over the place, but we are trying to quit the practice)

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

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

From michaelm at openjdk.java.net  Fri Oct  2 13:19:40 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 13:19:40 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
 <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
Message-ID: <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>

On Fri, 2 Oct 2020 12:58:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>
> make/modules/java.base/Copy.gmk line 195:
> 
>> 193: 	$(call MakeTargetDir)
>> 194: 	$(RM) $@ $@.tmp
>> 195: 	$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)
> 
> This can be simplified. Cat takes multiple files as input, so no need for 'foreach'. Also no need to go via a temp
> file. We have make configured to delete targets if a recipe fails, so the tmp dance isn't needed. (I know we still have
> this pattern all over the place, but we are trying to quit the practice)

Good points. I will update as suggested. Thanks.

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

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

From rriggs at openjdk.java.net  Fri Oct  2 15:24:51 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 15:24:51 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
Message-ID: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>

java.util.HexFormat utility:

 - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
 - Static factories and builder methods to create HexFormat copies with modified parameters.
 - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
 - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
 - Prefix and suffixes now apply to each formatted value, not the string as a whole
 - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
   like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
 - Immutable and thread safe, a "value-based" class

See the [HexFormat
javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.

Review comments and suggestions welcome.

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

Commit messages:
 - 8251989: Hex formatting and parsing utility

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

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

From alanb at openjdk.java.net  Sun Oct  4 08:30:38 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 4 Oct 2020 08:30:38 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
 <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
 <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>
Message-ID: <9t4xh-s8zuCV1pMwpenVJyThc6PUmbfVAd8CEo0Moec=.20e01f2f-7ca9-495c-b710-d738c758ccb6@github.com>

On Fri, 2 Oct 2020 13:17:04 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> make/modules/java.base/Copy.gmk line 195:
>> 
>>> 193: 	$(call MakeTargetDir)
>>> 194: 	$(RM) $@ $@.tmp
>>> 195: 	$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)
>> 
>> This can be simplified. Cat takes multiple files as input, so no need for 'foreach'. Also no need to go via a temp
>> file. We have make configured to delete targets if a recipe fails, so the tmp dance isn't needed. (I know we still have
>> this pattern all over the place, but we are trying to quit the practice)
>
> Good points. I will update as suggested. Thanks.

I would prefer if we didn't rename net.properties. Can we use the same approach as lib/security/default.policy where
the share and platform specific are concatenated?

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

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

From michaelm at openjdk.java.net  Sun Oct  4 13:14:49 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 4 Oct 2020 13:14:49 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - simplified Copy.gmk to CAT source files directly
  - renamed net.properties source files to all be net.properties

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/dc70cd6e..0096645e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=12-13

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

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

From michaelm at openjdk.java.net  Sun Oct  4 13:14:50 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 4 Oct 2020 13:14:50 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <9t4xh-s8zuCV1pMwpenVJyThc6PUmbfVAd8CEo0Moec=.20e01f2f-7ca9-495c-b710-d738c758ccb6@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
 <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
 <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>
 <9t4xh-s8zuCV1pMwpenVJyThc6PUmbfVAd8CEo0Moec=.20e01f2f-7ca9-495c-b710-d738c758ccb6@github.com>
Message-ID: <Rgzc9LEZ3V4MIWDI_xpbE1UNg6oEfgIn2aj5TtiWumU=.e0fc42c4-9e22-49e8-be9f-82c3330feb22@github.com>

On Sun, 4 Oct 2020 08:27:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Good points. I will update as suggested. Thanks.
>
> I would prefer if we didn't rename net.properties. Can we use the same approach as lib/security/default.policy where
> the share and platform specific are concatenated?

Okay, I have just pushed these suggested updates.

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

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

From chegar at openjdk.java.net  Mon Oct  5 09:11:38 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 5 Oct 2020 09:11:38 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v6]
In-Reply-To: <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
Message-ID: <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>

On Fri, 18 Sep 2020 16:41:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Continuing the review with a PR...
>> 
>> 8252374: Add a new factory method to concatenate a sequence
>>          of BodyPublisher instances into a single publisher.
>> https://bugs.openjdk.java.net/browse/JDK-8252374
>> 
>> 
>> Draft CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8252382
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved the API documentation of BodyPublishers::concat

Changes requested by chegar (Reviewer).

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

> 571:
> 572:         @Override
> 573:         public void request(long n) {

I believe that a negative demand value should result in an IllegalArgumentException

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

> 500:
> 501:     public static BodyPublisher concat(BodyPublisher... publishers) {
> 502:         if (publishers == null || publishers.length == 0) {

publishers cannot be null here - since NPE will be thrown from the API point. Maybe assert non-null or just remove?

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

> 567:             this.bodies = new ConcurrentLinkedQueue<>(bodies);
> 568:             this.subscriber = subscriber;
> 569:             scheduler = SequentialScheduler.synchronizedScheduler(this::run);

It's a little unpleasant that this call to the scheduler is inside the constructor. I wonder if it could be located in
the subscribe method above, just after the subscription is created? (since both classes are in the same nest )

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

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

From dfuchs at openjdk.java.net  Mon Oct  5 09:45:39 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Oct 2020 09:45:39 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v6]
In-Reply-To: <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
 <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
Message-ID: <hr9Zk7IH9PDvTfPvvgqbdt1pLUiSFtAIF1PpOxp4p2k=.b69aecc3-019a-43d2-b1ef-1d168642cfeb@github.com>

On Mon, 5 Oct 2020 08:52:33 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved the API documentation of BodyPublishers::concat
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 502:
> 
>> 500:
>> 501:     public static BodyPublisher concat(BodyPublisher... publishers) {
>> 502:         if (publishers == null || publishers.length == 0) {
> 
> publishers cannot be null here - since NPE will be thrown from the API point. Maybe assert non-null or just remove?

OK - will remove.

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 569:
> 
>> 567:             this.bodies = new ConcurrentLinkedQueue<>(bodies);
>> 568:             this.subscriber = subscriber;
>> 569:             scheduler = SequentialScheduler.synchronizedScheduler(this::run);
> 
> It's a little unpleasant that this call to the scheduler is inside the constructor. I wonder if it could be located in
> the subscribe method above, just after the subscription is created? (since both classes are in the same nest )

Scheduler is a final variable in `AggregateSubscription`. Fixed to:

`    this.scheduler = ....;`

(though the `this.` is not strictly needed in this third instantiation)

> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 573:
> 
>> 571:
>> 572:         @Override
>> 573:         public void request(long n) {
> 
> I believe that a negative demand value should result in an IllegalArgumentException

That will be thrown by Demand::increase below.

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

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

From dfuchs at openjdk.java.net  Mon Oct  5 10:02:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Oct 2020 10:02:59 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v7]
In-Reply-To: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
Message-ID: <QeJdz1FTvPlLaPLhKy_ZC_YNXGPzoFmCZm_-6dt9Gcc=.e61caec4-fe3f-4a20-9039-1f383a9b28f6@github.com>

> Continuing the review with a PR...
> 
> 8252374: Add a new factory method to concatenate a sequence
>          of BodyPublisher instances into a single publisher.
> https://bugs.openjdk.java.net/browse/JDK-8252374
> 
> 
> Draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8252382

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since
the last revision:

 - Merge
 - Incorporated review comments
 - Improved the API documentation of BodyPublishers::concat
 - Improved API documentation, added more tests for contentLength()
 - Merge remote-tracking branch 'origin/master' into concat-bs-8252374
 - Merge remote-tracking branch 'origin/master' into concat-bs-8252374
 - Merge remote-tracking branch 'origin/master' into concat-bs-8252374
 - 8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/57/files
  - new: https://git.openjdk.java.net/jdk/pull/57/files/496c80d9..63709bb2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=05-06

  Stats: 59049 lines in 2712 files changed: 18192 ins; 30753 del; 10104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/57/head:pull/57

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

From prappo at openjdk.java.net  Mon Oct  5 10:19:37 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 5 Oct 2020 10:19:37 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v6]
In-Reply-To: <hr9Zk7IH9PDvTfPvvgqbdt1pLUiSFtAIF1PpOxp4p2k=.b69aecc3-019a-43d2-b1ef-1d168642cfeb@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
 <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
 <hr9Zk7IH9PDvTfPvvgqbdt1pLUiSFtAIF1PpOxp4p2k=.b69aecc3-019a-43d2-b1ef-1d168642cfeb@github.com>
Message-ID: <5zHgWpY8RwTjoPlDbuHN5AMWV3cXOnAvVx_46OGjowo=.fa9616c4-2f80-42c3-8523-3759a4be6411@github.com>

On Mon, 5 Oct 2020 09:40:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 569:
>> 
>>> 567:             this.bodies = new ConcurrentLinkedQueue<>(bodies);
>>> 568:             this.subscriber = subscriber;
>>> 569:             scheduler = SequentialScheduler.synchronizedScheduler(this::run);
>> 
>> It's a little unpleasant that this call to the scheduler is inside the constructor. I wonder if it could be located in
>> the subscribe method above, just after the subscription is created? (since both classes are in the same nest )
>
> Scheduler is a final variable in `AggregateSubscription`. Fixed to:
> 
> `    this.scheduler = ....;`
> 
> (though the `this.` is not strictly needed in this third instantiation)

Daniel, I believe Chris' concern is the escape of `this` before the (`AggregateSubscription`) object is fully
constructed.

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

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

From dfuchs at openjdk.java.net  Mon Oct  5 11:05:37 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Oct 2020 11:05:37 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v6]
In-Reply-To: <5zHgWpY8RwTjoPlDbuHN5AMWV3cXOnAvVx_46OGjowo=.fa9616c4-2f80-42c3-8523-3759a4be6411@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
 <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
 <hr9Zk7IH9PDvTfPvvgqbdt1pLUiSFtAIF1PpOxp4p2k=.b69aecc3-019a-43d2-b1ef-1d168642cfeb@github.com>
 <5zHgWpY8RwTjoPlDbuHN5AMWV3cXOnAvVx_46OGjowo=.fa9616c4-2f80-42c3-8523-3759a4be6411@github.com>
Message-ID: <5Jo5J2gzq5oXDhbvueNC9zyFb4cJXDHz-_u6_VGneEQ=.6daeed02-cf0f-4df4-a253-e28fc1dfff61@github.com>

On Mon, 5 Oct 2020 10:14:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Scheduler is a final variable in `AggregateSubscription`. Fixed to:
>> 
>> `    this.scheduler = ....;`
>> 
>> (though the `this.` is not strictly needed in this third instantiation)
>
> Daniel, I believe Chris' concern is the escape of `this` before the (`AggregateSubscription`) object is fully
> constructed.

Sorry - where does it escape? It doesn't escape anywhere. We have used this idiom everywhere where a sequential
scheduler was needed.

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

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

From prappo at openjdk.java.net  Mon Oct  5 11:12:37 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 5 Oct 2020 11:12:37 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v6]
In-Reply-To: <5Jo5J2gzq5oXDhbvueNC9zyFb4cJXDHz-_u6_VGneEQ=.6daeed02-cf0f-4df4-a253-e28fc1dfff61@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
 <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
 <hr9Zk7IH9PDvTfPvvgqbdt1pLUiSFtAIF1PpOxp4p2k=.b69aecc3-019a-43d2-b1ef-1d168642cfeb@github.com>
 <5zHgWpY8RwTjoPlDbuHN5AMWV3cXOnAvVx_46OGjowo=.fa9616c4-2f80-42c3-8523-3759a4be6411@github.com>
 <5Jo5J2gzq5oXDhbvueNC9zyFb4cJXDHz-_u6_VGneEQ=.6daeed02-cf0f-4df4-a253-e28fc1dfff61@github.com>
Message-ID: <PgMfrNuxQQyXhMWA5zO3C2pQZVYmveG6uyTgg2z-xB4=.d0c81971-84f6-44e3-b2d9-386ef06957f4@github.com>

On Mon, 5 Oct 2020 11:02:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel, I believe Chris' concern is the escape of `this` before the (`AggregateSubscription`) object is fully
>> constructed.
>
> Sorry - where does it escape? It doesn't escape anywhere. We have used this idiom everywhere where a sequential
> scheduler was needed.

Right here:
scheduler = SequentialScheduler.synchronizedScheduler(this::run);
                                                      ^

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

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

From erikj at openjdk.java.net  Mon Oct  5 13:01:56 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 5 Oct 2020 13:01:56 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
Message-ID: <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>

On Sun, 4 Oct 2020 13:14:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - simplified Copy.gmk to CAT source files directly
>   - renamed net.properties source files to all be net.properties

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From dfuchs at openjdk.java.net  Mon Oct  5 13:58:01 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Oct 2020 13:58:01 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v8]
In-Reply-To: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
Message-ID: <YbLqU4JeCSjJpMMMK3eRs3T9W8asYh8siP93Fo_i5Qw=.bb4ad977-7b8b-4b9e-a3c7-bd71b985fbb4@github.com>

> Continuing the review with a PR...
> 
> 8252374: Add a new factory method to concatenate a sequence
>          of BodyPublisher instances into a single publisher.
> https://bugs.openjdk.java.net/browse/JDK-8252374
> 
> 
> Draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8252382

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since
the last revision:

 - Merge
 - Added a test case for requesting a non positive number of items.
 - Merge
 - Incorporated review comments
 - Improved the API documentation of BodyPublishers::concat
 - Improved API documentation, added more tests for contentLength()
 - Merge remote-tracking branch 'origin/master' into concat-bs-8252374
 - Merge remote-tracking branch 'origin/master' into concat-bs-8252374
 - Merge remote-tracking branch 'origin/master' into concat-bs-8252374
 - 8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/57/files
  - new: https://git.openjdk.java.net/jdk/pull/57/files/63709bb2..2346c69d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=06-07

  Stats: 129 lines in 9 files changed: 121 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/57/head:pull/57

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

From pconcannon at openjdk.java.net  Mon Oct  5 14:43:51 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 5 Oct 2020 14:43:51 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer
Message-ID: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>

Hi,

Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?

This fix is set of formatting changes intended to clean up the javadoc of the following classes :

`com.sun.net.httpserver.HttpExchange`
`com.sun.net.httpserver.HttpServer`

This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)

Kind regards,
Patrick

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

Commit messages:
 - 8253475: Javadoc clean up in HttpExchange and HttpServer

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

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

From michaelm at openjdk.java.net  Mon Oct  5 15:12:47 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 5 Oct 2020 15:12:47 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
 <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>
Message-ID: <pj2L_CiUy60Ifew4KZ37wJl5tDPin3_ZPzW0rL-IoBE=.feca82ef-4de2-46d7-8810-989bb1d1a72a@github.com>

On Mon, 5 Oct 2020 12:58:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - simplified Copy.gmk to CAT source files directly
>>   - renamed net.properties source files to all be net.properties
>
> Build changes look good.

Thanks again Alan. Assume where there is no comment from me below that suggestions are accepted:
I will push an update based on these changes soon.

Michael.

> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
> [nio-dev](mailto:nio-dev at openjdk.java.net):_
> On 04/10/2020 14:14, Michael McMahon wrote:
> Another round of comments, this time on v14.
> 
> src/java.base/share/classes/java/net/StandardProtocolFamily.java
> - the enum constant is "UNIX" and might be better to put "Local" in
> parentheses rather than "Unix domain".
> 
> src/java.base/share/classes/java/nio/channels/package-info.java
> - L260 ends with "family only", I think "only" can be dropped.
> 
> src/java.base/share/classes/java/net/UnixDomainSocketAddress.java
> - left over "fix message" comments in constructor
> - a few formatting nits in the equals method due to a spurious space in
> the expression at L192, and missing a space at L194.
> 

I don't see a missing space at L194 ?

> src/java.base/share/classes/sun/net/util/SocketExceptions.java
> - Can of(IOException e, SocketAddress addr) check enhancedExceptionText
> to avoid the ugly check in the ofXXX methods?
> - Can you explain the inconsistency in the null handling for the address
> types, maybe a left over from an early prototype?
> 

The null check was always there for Inet sockets. It is not required for Unix
but would be benign. So, the check can be promoted to the calling method.

> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
> - I think we need to change the class descriptions of both to start with
> "Base implementations ..."
> - We need to find a clean way to push the socket() method down to the
> InetXXXImpl classes as they are the only classes that should know about
> the socket adaptors.

Only way to do this is to define yet another implXXX method (implSocket)
but I think it is worthwhile as neither the field nor the implementation
belong in the super class

> 
> src/java.base/share/classes/sun/nio/ch/UnixDomainServerSocketChannelImpl.java
> - implBind should not loop/retry when a local address is provided

It actually catches the BindException and rethrows it when 'local != null, but maybe
the comment above the loop is confusing. I will reword it.

> - what behavior is expected when getTempDir returns null?

I was assuming that ${java.io.tmpdir} would always be defined, but I see
getTempDir() could be more robust in dealing with errors in the preceding
search steps. So, in the unlikely event that ${java.io.tmpdir} is not defined
null would be returned. I will change to throw a BindException in that case.

> - Why doesn't this code use SecureRandom, as is done in the Windows
> Selector implementation.

It does use SecureRandom but only uses the Random api.

> - Can supportedOptions be changed to return
> Set.of(StandardSocketOptions.SO_RCVBUF)?

I can simplify that code definitely, but I think for consistency it should
still return a static unmodifiable instance

> - toString has a left over "TODO".
> - The message for the IOException in implBind should start with a
> capital to be consistent with the other exceptions thrown in this area
> 
> src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java
> - The initializer sets the system property
> "jdk.nio.channels.unixdomain.maxnamelength". Looks like it's to help the
> tests so need to find another solution for the tests.

Okay, the tests didn't really need this anyway

> - checkCapability should be renamed to checkPermission as it does a
> security manager check. Would it more be consistent with existing code
> if changed to "if (sm != null) sm.checkPermission(...)"
> - Can inTempDirectory be removed as it doesn't seem to be used and
> raises several questions if it is needed.
> - getTempName should use the path separator rather than "/".? Also I
> don't think "nio" should be in the name.
> - Can the init method be removed, may be a left over from a previous
> iteration.
> - The left breaks in the initialization of UNNAMED and support seem
> unnecessary, maybe they were very long in previous iterations?
> - Several methods are public, is that intentional, or maybe a left over?
> 
> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
> => Is the intention to put the NET_ functions into libnet or libnio? The
> function prototypes are declared in net_util.h but the functions have
> been compiled in libnio.
> 

They were probably in libnet originally, but makes more sense to be
in libnio. So, I will move the function prototypes to nio_util.h and rename
them to remove the NET_ prefix.

> src/java.base/share/classes/sun/nio/ch/Net.java
> - spurious blank line, probably left over from a previous iteration.
> 
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java
> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
> - getSunPathForSocketFile should not accept null, let
> to{Unix,Windows}Path handle it
> 
> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
> src/java.base/windows/classes/sun/nio/ch/SinkChannelImpl.java
> src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
> - The changes to PipeImpl look like they will set TCP_NODELAY for users
> of the Pipe API on older Windows releases. I think I would prefer to see
> a parameter on the PipeImpl constructor to indicate if there should
> buffered/nodelay or not. That way it will be clearer for the two usages
> of PipeImpl.

Right, good point.

> - The volatile noUnixDomainSockets does not need to be initialized to false.
> 
> src/jdk.net/share/classes/jdk/net/UnixDomainPrincipal.java
> - if records are finalized in Java 16 then this may be a candidate to be
> a record
> 

Right. I don't think there is anything we can do further we can do right now
on this point, but if records make it, then it would be a simple API change to make.

> test/jdk/java/nio/channels/etc/ProtocolFamilies.java
> - minor nit but the existing test uses "ssc", "sc", and "dc" so best to
> keep it consistent if you can.
> 
> test/jdk/jdk/nio/Basic.java
> - can you change this to use
> Class.forName("sun.nio.ch.InetSocketChannelImpl"), that should be
> cleaner and void the retry and introducing getFD1.
> 

Good idea, but needs to be "sun.nio.ch.SocketChannelImpl" I think

> I'm still working through the changes to the InheritedChannel
> implementation and all the changes/additions of tests so more comments
> soon on that aspect of the patch.
> 
> -Alan.

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

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

From dfuchs at openjdk.java.net  Mon Oct  5 15:46:03 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Oct 2020 15:46:03 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v9]
In-Reply-To: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
Message-ID: <lqNv9HkvvZdyJRm7iji5JGzq0SpIw4FGD4YDOQyAf6Y=.5471c684-478f-429a-befa-69a2e612b025@github.com>

> Continuing the review with a PR...
> 
> 8252374: Add a new factory method to concatenate a sequence
>          of BodyPublisher instances into a single publisher.
> https://bugs.openjdk.java.net/browse/JDK-8252374
> 
> 
> Draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8252382

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Use a dataProvider for testNegativeRequest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/57/files
  - new: https://git.openjdk.java.net/jdk/pull/57/files/2346c69d..c8c07682

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=07-08

  Stats: 18 lines in 1 file changed: 10 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/57/head:pull/57

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

From dfuchs at openjdk.java.net  Mon Oct  5 17:01:44 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Oct 2020 17:01:44 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer
In-Reply-To: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
Message-ID: <dOiZ2g4ZzNBgw2Rom3KTMGWZzesPSsKTSiWlzDomuVo=.ff0f1075-c118-4e3b-a3f9-f9951b4fe4ba@github.com>

On Mon, 5 Oct 2020 14:38:35 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpExchange`
> `com.sun.net.httpserver.HttpServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 46:

> 44:  *     <li>{@link #getRequestHeaders()} to examine the request headers (if
> 45:  *     needed).
> 46:  *     <li>{@link #getRequestBody()} returns a {@link java.io.InputStream} for

Hi Patrick, could you double check what the text of the link is in the generated javadoc here? Is it a
`java.io.InputStream` or just a `InputStream` (in which case `a` should be `an`)

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 275:

> 273:
> 274:     /**
> 275:      * Used by {@linkplain #Filter Filters} to wrap either (or both) of this exchange's InputStream

Are you sure about the # here? Can you double check that the generated link is working? InputStream should be {@code
InputStream}. OutputStream below should be {@code OutputStream}.

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

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

From pconcannon at openjdk.java.net  Mon Oct  5 18:45:59 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 5 Oct 2020 18:45:59 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v2]
In-Reply-To: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
Message-ID: <wKVg2tEOv6rfl_tXvfg-faVf1lN7wrQ1Zr3Lzsn6dlQ=.77d9b797-4eda-4f30-a0da-bcdb50133739@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpExchange`
> `com.sun.net.httpserver.HttpServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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:

 - 8253475: Fixed typo and bad link in HttpExchange
 - Merge remote-tracking branch 'origin/master' into JDK-8253475
 - 8253475: Javadoc clean up in HttpExchange and HttpServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/506/files
  - new: https://git.openjdk.java.net/jdk/pull/506/files/00ca1176..3b4546ef

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

  Stats: 411 lines in 24 files changed: 327 ins; 18 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/506.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/506/head:pull/506

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

From pconcannon at openjdk.java.net  Mon Oct  5 18:46:01 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 5 Oct 2020 18:46:01 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v2]
In-Reply-To: <dOiZ2g4ZzNBgw2Rom3KTMGWZzesPSsKTSiWlzDomuVo=.ff0f1075-c118-4e3b-a3f9-f9951b4fe4ba@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
 <dOiZ2g4ZzNBgw2Rom3KTMGWZzesPSsKTSiWlzDomuVo=.ff0f1075-c118-4e3b-a3f9-f9951b4fe4ba@github.com>
Message-ID: <HZtQex_cHe8rU0j1Cstap519b0f4_RKgloGSv_FyKVk=.3d9de3c9-d2e8-4b67-a810-adf854bc20ea@github.com>

On Mon, 5 Oct 2020 16:38:18 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:
>>  - 8253475: Fixed typo and bad link in HttpExchange
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253475
>>  - 8253475: Javadoc clean up in HttpExchange and HttpServer
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 46:
> 
>> 44:  *     <li>{@link #getRequestHeaders()} to examine the request headers (if
>> 45:  *     needed).
>> 46:  *     <li>{@link #getRequestBody()} returns a {@link java.io.InputStream} for
> 
> Hi Patrick, could you double check what the text of the link is in the generated javadoc here? Is it a
> `java.io.InputStream` or just a `InputStream` (in which case `a` should be `an`)

It appears as `InputStream` so I've changed `a` to `an` as suggested in new commit (3b4546e).

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

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

From pconcannon at openjdk.java.net  Mon Oct  5 18:50:45 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 5 Oct 2020 18:50:45 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v2]
In-Reply-To: <dOiZ2g4ZzNBgw2Rom3KTMGWZzesPSsKTSiWlzDomuVo=.ff0f1075-c118-4e3b-a3f9-f9951b4fe4ba@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
 <dOiZ2g4ZzNBgw2Rom3KTMGWZzesPSsKTSiWlzDomuVo=.ff0f1075-c118-4e3b-a3f9-f9951b4fe4ba@github.com>
Message-ID: <TeL9FZ8461QgjBWgnHsYEvJDM_-OYreD0c1xv1e15is=.64e07cff-824a-4f6b-bc7e-d52fa8b857e5@github.com>

On Mon, 5 Oct 2020 16:52:15 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:
>>  - 8253475: Fixed typo and bad link in HttpExchange
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253475
>>  - 8253475: Javadoc clean up in HttpExchange and HttpServer
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 275:
> 
>> 273:
>> 274:     /**
>> 275:      * Used by {@linkplain #Filter Filters} to wrap either (or both) of this exchange's InputStream
> 
> Are you sure about the # here? Can you double check that the generated link is working? InputStream should be {@code
> InputStream}. OutputStream below should be {@code OutputStream}.

Well spotted. I have fixed the link to the `Filter` class. I also changed the first appearance of `InputStream` and
`OutputSteam` to  `{@link InputStream}` and `{@link OutputStream}` and subsequent occurrences to `{@code InputStream)`
and `{@code OutputStream)`. The changes can be found in commit 3b4546e

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

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

From pconcannon at openjdk.java.net  Tue Oct  6 08:03:54 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 6 Oct 2020 08:03:54 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v3]
In-Reply-To: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
Message-ID: <DvA9VOVSscw8CIdH5_jrW8yEGQfLC9ZPs4qtOSMJXtI=.ca3223de-6c3c-4538-b896-d0b1097837bb@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpExchange`
> `com.sun.net.httpserver.HttpServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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-8253475
 - 8253475: Fixed typo and bad link in HttpExchange
 - Merge remote-tracking branch 'origin/master' into JDK-8253475
 - 8253475: Javadoc clean up in HttpExchange and HttpServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/506/files
  - new: https://git.openjdk.java.net/jdk/pull/506/files/3b4546ef..a3eab0e6

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

  Stats: 111 lines in 9 files changed: 56 ins; 36 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/506.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/506/head:pull/506

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

From dfuchs at openjdk.java.net  Tue Oct  6 08:57:44 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 08:57:44 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v3]
In-Reply-To: <DvA9VOVSscw8CIdH5_jrW8yEGQfLC9ZPs4qtOSMJXtI=.ca3223de-6c3c-4538-b896-d0b1097837bb@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
 <DvA9VOVSscw8CIdH5_jrW8yEGQfLC9ZPs4qtOSMJXtI=.ca3223de-6c3c-4538-b896-d0b1097837bb@github.com>
Message-ID: <JSzE6WvWdAQ6NbZc8d2bE66pP_N7xdorLyEvKdWpPxA=.953b6ad8-3081-4588-a338-8717ae788675@github.com>

On Tue, 6 Oct 2020 08:03:54 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpExchange`
>> `com.sun.net.httpserver.HttpServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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-8253475
>  - 8253475: Fixed typo and bad link in HttpExchange
>  - Merge remote-tracking branch 'origin/master' into JDK-8253475
>  - 8253475: Javadoc clean up in HttpExchange and HttpServer

Looks good to me. Alternatively you could (if you want) make sure that `InputStream` and `OutputStream` are imported
and change `{@link java.io.XxxxStream}` into `{@link XxxxStream}`.

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

Marked as reviewed by dfuchs (Reviewer).

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

From michaelm at openjdk.java.net  Tue Oct  6 09:36:54 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 6 Oct 2020 09:36:54 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v15]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <yKnjNYori5L_X2W-NryG3PSpR05rOj2wgsQNJOz6yZU=.6052e1e6-3ad6-4011-8cd7-82c3a862634b@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - update after Alan's review on Oct 4
  - includes API change required by JDK-8251952
  - original CSR for the overall change will be resubmitted with
    all api changes consolidated based on this update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/0096645e..17acf10a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=13-14

  Stats: 327 lines in 35 files changed: 108 ins; 125 del; 94 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Tue Oct  6 09:52:10 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 6 Oct 2020 09:52:10 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v16]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <hyFYcTMFpVLhyN7qi_hVwR9Ti5KBVwNJNFex9ZQkf28=.5ce14f1a-1f7f-4180-ac0e-254984af0652@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since
the last revision:

 - Merge branch 'master' into unixdomainchannels
 - - update after Alan's review on Oct 4
   - includes API change required by JDK-8251952
   - original CSR for the overall change will be resubmitted with
     all api changes consolidated based on this update
 - - simplified Copy.gmk to CAT source files directly
   - renamed net.properties source files to all be net.properties
 - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
 - unixdomainchannels:
   (1) rename UnixDomainHelper to UnixDomainSocketsUtil
   (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
   (3) replace (2) with documented system/networking properties
   (4) Small update to UnixDomainSocketAddress API
   (5) CSR for (3) and (4) submitted at JDK-8253930
   (6) Update build to generate net.properties from shared net.properties.common
       plus platform specific additions.
 - Merge branch 'master' into unixdomainchannels
 - unixdomainchannels: remove more cruft from Windows Net.c
 - unixdomainchannels: change to Net.c was missed after all
 - unixdomainchannels: typo in WindowsFileSystemProvider.java
 - unixdomainchannels: Update after Alan's review of Sept 29
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/96b742dd...36efb46c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/17acf10a..36efb46c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=14-15

  Stats: 15436 lines in 1715 files changed: 5751 ins; 2807 del; 6878 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From dfuchs at openjdk.java.net  Tue Oct  6 09:58:41 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 09:58:41 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
Message-ID: <wl24u_cR6VktCM87dqxKBRfLlckgl_lyIz2osyMDX_M=.e97646ea-986a-43ef-90c7-56468980fe8c@github.com>

On Fri, 2 Oct 2020 08:41:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
>> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
>> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
>> 
>> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>>   memory neighborhood)
>> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
>> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>>   infrequent/non-existent in this case.
>> 
>> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
>> LinkedLists in this scenario.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253179: Removed ArrayList copy of streams

Looks good to me Conor.
best regards

-- daniel

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

Marked as reviewed by dfuchs (Reviewer).

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

From prappo at openjdk.java.net  Tue Oct  6 15:37:08 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 6 Oct 2020 15:37:08 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
Message-ID: <Hi09UL9e5EgpwziUYr9b77XI-Bg-sLhL3X4vYkMdR4Y=.5dfc55d7-d3f8-4658-8ebd-66888148ef49@github.com>

On Fri, 2 Oct 2020 08:41:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
>> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
>> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
>> 
>> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>>   memory neighborhood)
>> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
>> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>>   infrequent/non-existent in this case.
>> 
>> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
>> LinkedLists in this scenario.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253179: Removed ArrayList copy of streams

This looks good.

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

Marked as reviewed by prappo (Reviewer).

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

From chegar at openjdk.java.net  Tue Oct  6 15:41:11 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 6 Oct 2020 15:41:11 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
Message-ID: <ZZeYHlSnsbO0-TBXpEx8dgk1qfzl4dgiftOuuBKBnPA=.a1982b38-0821-45f9-a3e5-b890ea68606a@github.com>

On Fri, 2 Oct 2020 08:41:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
>> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
>> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
>> 
>> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>>   memory neighborhood)
>> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
>> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>>   infrequent/non-existent in this case.
>> 
>> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
>> LinkedLists in this scenario.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253179: Removed ArrayList copy of streams

Marked as reviewed by chegar (Reviewer).

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

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

From pconcannon at openjdk.java.net  Tue Oct  6 16:18:24 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 6 Oct 2020 16:18:24 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v4]
In-Reply-To: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
Message-ID: <l0NGPvS4WDeJi6Ol4_ScGdDUfLWnIZ8KqOIdc6aK82I=.2c969f72-4f50-463b-bd7d-cd0f98f806db@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpExchange`
> `com.sun.net.httpserver.HttpServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 five additional commits
since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253475
 - Merge remote-tracking branch 'origin/master' into JDK-8253475
 - 8253475: Fixed typo and bad link in HttpExchange
 - Merge remote-tracking branch 'origin/master' into JDK-8253475
 - 8253475: Javadoc clean up in HttpExchange and HttpServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/506/files
  - new: https://git.openjdk.java.net/jdk/pull/506/files/a3eab0e6..f8abb290

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

  Stats: 1581 lines in 87 files changed: 912 ins; 339 del; 330 mod
  Patch: https://git.openjdk.java.net/jdk/pull/506.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/506/head:pull/506

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

From pconcannon at openjdk.java.net  Tue Oct  6 16:28:21 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 6 Oct 2020 16:28:21 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v5]
In-Reply-To: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
Message-ID: <qVtHLXHKPEz6sePKckLfVEbDBVtoecyy34mAwkXnWXI=.86154511-027b-42f6-b4f7-9af36f07fa8f@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpExchange`
> `com.sun.net.httpserver.HttpServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8253475: Changed several @links to use concise form in HttpExchange

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/506/files
  - new: https://git.openjdk.java.net/jdk/pull/506/files/f8abb290..6df6ddfe

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

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

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

From pconcannon at openjdk.java.net  Tue Oct  6 16:43:07 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 6 Oct 2020 16:43:07 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v3]
In-Reply-To: <JSzE6WvWdAQ6NbZc8d2bE66pP_N7xdorLyEvKdWpPxA=.953b6ad8-3081-4588-a338-8717ae788675@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
 <DvA9VOVSscw8CIdH5_jrW8yEGQfLC9ZPs4qtOSMJXtI=.ca3223de-6c3c-4538-b896-d0b1097837bb@github.com>
 <JSzE6WvWdAQ6NbZc8d2bE66pP_N7xdorLyEvKdWpPxA=.953b6ad8-3081-4588-a338-8717ae788675@github.com>
Message-ID: <qBSXsXX1ZVu8yKyA6KW7bNOFbD9LiY9LVdVBD_bDSVo=.5a487b25-6ff8-4899-b4f0-0b007e068d23@github.com>

On Tue, 6 Oct 2020 08:54:29 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 four additional commits
>> since the last revision:
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253475
>>  - 8253475: Fixed typo and bad link in HttpExchange
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253475
>>  - 8253475: Javadoc clean up in HttpExchange and HttpServer
>
> Looks good to me. Alternatively you could (if you want) make sure that `InputStream` and `OutputStream` are imported
> and change `{@link java.io.XxxxStream}` into `{@link XxxxStream}`.

Thanks @dfuch, that's a good observation. I've incorporated it into commit 6df6ddf

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

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

From dfuchs at openjdk.java.net  Tue Oct  6 16:50:09 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 16:50:09 GMT
Subject: RFR: 8253475: Javadoc clean up in HttpExchange and HttpServer [v5]
In-Reply-To: <qVtHLXHKPEz6sePKckLfVEbDBVtoecyy34mAwkXnWXI=.86154511-027b-42f6-b4f7-9af36f07fa8f@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
 <qVtHLXHKPEz6sePKckLfVEbDBVtoecyy34mAwkXnWXI=.86154511-027b-42f6-b4f7-9af36f07fa8f@github.com>
Message-ID: <Ft6fiaGuO1gu_2cx-VefiiuXP_B-b1So4_XA4oEciC8=.a956e981-183b-4505-9164-e25cbb31ff3b@github.com>

On Tue, 6 Oct 2020 16:28:21 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpExchange`
>> `com.sun.net.httpserver.HttpServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253475: Changed several @links to use concise form in HttpExchange

Marked as reviewed by dfuchs (Reviewer).

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

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

From dfuchs at openjdk.java.net  Tue Oct  6 17:03:28 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 17:03:28 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v10]
In-Reply-To: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
Message-ID: <bkPlqsAs7YYPO5wLtZVO75TmW0GnG5Rn850xaAiWEkY=.9f8c3d95-97ae-478c-b9f7-54bbef1f7cac@github.com>

> Continuing the review with a PR...
> 
> 8252374: Add a new factory method to concatenate a sequence
>          of BodyPublisher instances into a single publisher.
> https://bugs.openjdk.java.net/browse/JDK-8252374
> 
> 
> Draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8252382

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Fixed handling of negative request. Added BodyPublishers::concat to the TCK tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/57/files
  - new: https://git.openjdk.java.net/jdk/pull/57/files/c8c07682..9719bf29

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=08-09

  Stats: 159 lines in 6 files changed: 147 ins; 4 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/57/head:pull/57

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

From shade at openjdk.java.net  Tue Oct  6 17:07:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Oct 2020 17:07:10 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
Message-ID: <BNZdOG9wvfPUXPvU6mBCgJBlVNIrqfrArzTnPdXivU4=.46498c4a-a0e0-482c-9e6d-e5eb7923e0b8@github.com>

On Fri, 2 Oct 2020 08:41:56 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
>> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
>> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
>> 
>> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>>   memory neighborhood)
>> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
>> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>>   infrequent/non-existent in this case.
>> 
>> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
>> LinkedLists in this scenario.
>
> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253179: Removed ArrayList copy of streams

Marked as reviewed by shade (Reviewer).

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

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

From shade at openjdk.java.net  Tue Oct  6 17:07:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Oct 2020 17:07:10 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <BNZdOG9wvfPUXPvU6mBCgJBlVNIrqfrArzTnPdXivU4=.46498c4a-a0e0-482c-9e6d-e5eb7923e0b8@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
 <BNZdOG9wvfPUXPvU6mBCgJBlVNIrqfrArzTnPdXivU4=.46498c4a-a0e0-482c-9e6d-e5eb7923e0b8@github.com>
Message-ID: <ImVEaBbHvQyAYa5JTrN-Yd9rkcQxYfFO-Lk80GQO-jk=.e41d50db-8fa7-41ba-bf21-65c4f5711d29@github.com>

On Tue, 6 Oct 2020 17:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Conor Cleary has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253179: Removed ArrayList copy of streams
>
> Marked as reviewed by shade (Reviewer).

I can sponsor this, but it is not clear what testing was done on this. At least `tier1`?

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

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

From dfuchs at openjdk.java.net  Tue Oct  6 17:54:06 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 17:54:06 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v6]
In-Reply-To: <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tD14LKvzdb4tqUCTE3E7pwImr-WT0o6E9e4eeuzkFzU=.81785318-12e0-4e55-8398-6e06e9892ccc@github.com>
 <gl8n6tDG4fTMg6V3lSXTFrHSX-8OaW8G3lLisibhGCk=.292026bf-155a-403b-b431-eaf8c3907692@github.com>
Message-ID: <xtr7FWRyH0CZurQSSkkzNzmxLTvaOAP1kfRZ_ZVaYlo=.bdf60a8c-dffc-4686-a92e-5dad2b6391e9@github.com>

On Mon, 5 Oct 2020 09:09:17 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved the API documentation of BodyPublishers::concat
>
> Changes requested by chegar (Reviewer).

@ChrisHegarty As we discussed I have fixed the handling of negative requests, and hooked the publishers created by the
new concat method to the TCK tests.

This made me realize that the `AggregateSubscription` should be checking its cancellation status more often to make it
sure it's reported as soon as possible to the upstream publishers. Similarly I updated the `PullPublisher` to check its
error state more often. The issue here is when the error/cancellation gets reported in the same thread in which the
sequential scheduler is running, and when the upstream publisher is busily forwarding items until its demand is
exhausted. If you had a single `request()` call with a high demand - then you do need to check the error/cancellation
state before forwarding the next item - and not only after/before each `request()` call to the upstream publisher.

I also tweaked `Demand` to generate an `IllegalArgumentException` message that contains the (optional) message string
expected by the TCK.

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

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

From michaelm at openjdk.java.net  Tue Oct  6 19:53:18 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 6 Oct 2020 19:53:18 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v17]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <cHLt3KxXbRfBSo7EX--jOzxQWLj7Afp-1l9tWg7rwMw=.2e9e408d-05c8-4c9d-aaf2-5027ff7e6d81@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels:
  - updated property name
  - added JFR unit test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/36efb46c..0e8e527f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=15-16

  Stats: 185 lines in 10 files changed: 147 ins; 0 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From ccleary at openjdk.java.net  Tue Oct  6 21:42:06 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Tue, 6 Oct 2020 21:42:06 GMT
Subject: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection
 [v2]
In-Reply-To: <ImVEaBbHvQyAYa5JTrN-Yd9rkcQxYfFO-Lk80GQO-jk=.e41d50db-8fa7-41ba-bf21-65c4f5711d29@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
 <SbFvNa-0z7JloKOAa8-qfe_Y2gNGe4ZHNcw5tPr7PMA=.8a4b0aa1-2b23-4be7-8b16-1d48033233f2@github.com>
 <BNZdOG9wvfPUXPvU6mBCgJBlVNIrqfrArzTnPdXivU4=.46498c4a-a0e0-482c-9e6d-e5eb7923e0b8@github.com>
 <ImVEaBbHvQyAYa5JTrN-Yd9rkcQxYfFO-Lk80GQO-jk=.e41d50db-8fa7-41ba-bf21-65c4f5711d29@github.com>
Message-ID: <yZ6UrEYC0Qah90AhkEJo2SbAYNRQPNOlYRvj9DcKuWo=.f0cecc9f-53ff-4544-a126-b6fda9158ded@github.com>

On Tue, 6 Oct 2020 17:04:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I can sponsor this, but it is not clear what testing was done on this. At least `tier1`?

`tier1`, `tier2`, `jdk_net`, `test/jdk/java/net/httpclient` tests were conducted with all passing.

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

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

From ccleary at openjdk.java.net  Wed Oct  7 06:24:11 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Wed, 7 Oct 2020 06:24:11 GMT
Subject: Integrated: 8253179: Replace LinkedList Impl in
 net.http.Http2Connection
In-Reply-To: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
References: <-y-nzP1ZwfzOq4ELfYh922EHThZmw3vvoQtUW_UeVvk=.f91f2f36-1562-43d1-80f4-87961eb532e7@github.com>
Message-ID: <hgq0B72c4iIta5dLxf6YXvdCOux3RCsDz8cMPx6fyjg=.df0c254b-5417-4506-98db-6f54a9f11cc7@github.com>

On Wed, 30 Sep 2020 10:22:11 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> This patch replaces a LinkedList data structure used in the net.http.Http2Connection class with an ArrayList. This
> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in
> java.net](https://bugs.openjdk.java.net/browse/JDK-8246048).  Some justifications for this change are as follows:
> 
> - Sequential Access Times for ArrayLists are improved due to locality of reference (i.e ArrayList elements stored in same
>   memory neighborhood)
> - Get(index) operations are O(1) time complexity for ArrayLists as opposed to worst-case O(N-1) for LinkedLists
> - While insertion operations can be expensive (O(N) in the worst case), these operations appear to be
>   infrequent/non-existent in this case.
> 
> Additional justifications or challenges to those listed are welcome! The general idea is that ArrayLists out-perform
> LinkedLists in this scenario.

This pull request has now been integrated.

Changeset: 703b345e
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/703b345e
Stats:     5 lines in 1 file changed: 1 ins; 2 del; 2 mod

8253179: Replace LinkedList Impl in net.http.Http2Connection

Reviewed-by: dfuchs, prappo, chegar, shade

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

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

From chegar at openjdk.java.net  Wed Oct  7 08:17:09 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 7 Oct 2020 08:17:09 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v10]
In-Reply-To: <bkPlqsAs7YYPO5wLtZVO75TmW0GnG5Rn850xaAiWEkY=.9f8c3d95-97ae-478c-b9f7-54bbef1f7cac@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <bkPlqsAs7YYPO5wLtZVO75TmW0GnG5Rn850xaAiWEkY=.9f8c3d95-97ae-478c-b9f7-54bbef1f7cac@github.com>
Message-ID: <ryUlzWjwhJlGKeJ8vXwNUkb77Ax4xZnA5FxBD5mH8cE=.107c604e-7288-44b1-be87-91fba1f87e8b@github.com>

On Tue, 6 Oct 2020 17:03:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Continuing the review with a PR...
>> 
>> 8252374: Add a new factory method to concatenate a sequence
>>          of BodyPublisher instances into a single publisher.
>> https://bugs.openjdk.java.net/browse/JDK-8252374
>> 
>> 
>> Draft CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8252382
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed handling of negative request. Added BodyPublishers::concat to the TCK tests.

src/java.net.http/share/classes/jdk/internal/net/http/PullPublisher.java line 105:

> 103:                 }
> 104:
> 105:                 while (demand.tryDecrement() && !cancelled && error == null) {

The changes to `PullPublisher` seem like a general bug fix unrelated to `concat`. Is that true? Does it make sense to
separate them out, or are they only applicable to a very narrow boundary scenario?

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

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

From pconcannon at openjdk.java.net  Wed Oct  7 09:16:12 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 7 Oct 2020 09:16:12 GMT
Subject: Integrated: 8253475: Javadoc clean up in HttpExchange and HttpServer
In-Reply-To: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
References: <0VuLZQgWYI7XWPmJfeKkmVJYt42wjKW64sTl56YOmtY=.70fc8f39-b358-4201-9a90-32b06db7f3c4@github.com>
Message-ID: <mpIlbw3mZV_VmqkUlTmBa9KsRy8Mh1-BtLz5V8ecTdQ=.919190b4-617c-4bdf-935a-7b34b0eb7ebc@github.com>

On Mon, 5 Oct 2020 14:38:35 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253475 - 'Javadoc clean up in HttpExchange and HttpServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpExchange`
> `com.sun.net.httpserver.HttpServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 49128a1e
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/49128a1e
Stats:     342 lines in 2 files changed: 56 ins; 4 del; 282 mod

8253475: Javadoc clean up in HttpExchange and HttpServer

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.java.net  Wed Oct  7 13:12:33 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 7 Oct 2020 13:12:33 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v11]
In-Reply-To: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
Message-ID: <tTP7yqN7n5rKYa1s6murm3G3oFVlgNaG9YCvQQujoyA=.f1acd912-f95d-4c1c-a096-6e351ef6a2ff@github.com>

> Continuing the review with a PR...
> 
> 8252374: Add a new factory method to concatenate a sequence
>          of BodyPublisher instances into a single publisher.
> https://bugs.openjdk.java.net/browse/JDK-8252374
> 
> 
> Draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8252382

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since
the last revision:

 - Merge
 - Added a plain test for positive requests.
 - Keep changes to PullPublisher for a later fix
 - Fixed handling of negative request. Added BodyPublishers::concat to the TCK tests.
 - Use a dataProvider for testNegativeRequest
 - Merge
 - Added a test case for requesting a non positive number of items.
 - Merge
 - Incorporated review comments
 - Improved the API documentation of BodyPublishers::concat
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/702cde1a...9ff5a3b3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/57/files
  - new: https://git.openjdk.java.net/jdk/pull/57/files/9719bf29..9ff5a3b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=57&range=09-10

  Stats: 4647 lines in 169 files changed: 2498 ins; 1156 del; 993 mod
  Patch: https://git.openjdk.java.net/jdk/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/57/head:pull/57

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

From dfuchs at openjdk.java.net  Thu Oct  8 15:24:44 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 8 Oct 2020 15:24:44 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
Message-ID: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>

Hi,

This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
synchronized monitors.

Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
outlined below:

1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
   `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
   ( a snapshot of the data is taken before printing instead)

2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
    `MeteredStream::close` was missing synchronization: it is now protected by the lock

3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
    `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
    Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
    `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
    is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
    code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
    reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
    there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
    method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
    casting to PrintStream.

4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
    Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
    There is no need for a synchronized here as the method is only called from a method that already
    holds the lock.

5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
    Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
    This method is only called from methods already protected by the lock.
    Also the method has been made private.

6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
    `queuedForCleanup` is made volatile as it is read and written directly from outside the class
    and without protection by the `KeepAliveCleanerEntry`.
    Lock protection is also added to `close()`, which was missing it.
    Some methods that have no lock protection and did not need it because only called from
    within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`

7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
    `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
    acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
    from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`

8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
    Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
    to help track the fact that AuthenticationInfo::setHeaders is only called while
    holding the lock.
    Synchronization was also removed from some method that didn't need it because only
    called from within code blocks protected by the lock:
    `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
    `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
    `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
    `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).

9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
    synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
    synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
    synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

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

Commit messages:
 - 8229867: Re-examine synchronization usages in http and https protocol handlers

Changes: https://git.openjdk.java.net/jdk/pull/558/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=558&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8229867
  Stats: 1116 lines in 18 files changed: 551 ins; 149 del; 416 mod
  Patch: https://git.openjdk.java.net/jdk/pull/558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/558/head:pull/558

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

From alanb at openjdk.java.net  Thu Oct  8 17:17:24 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 8 Oct 2020 17:17:24 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
In-Reply-To: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
Message-ID: <X1gX-ShW_Uahvw68q2I8tXLxQimuoC0IkWI68X_exqk=.dec8a4cc-5b4e-43cc-8557-357346dc1190@github.com>

On Thu, 8 Oct 2020 11:22:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
> synchronized monitors.
> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
> outlined below:
> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>    ( a snapshot of the data is taken before printing instead)
> 
> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
> 
> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>     casting to PrintStream.
> 
> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>     There is no need for a synchronized here as the method is only called from a method that already
>     holds the lock.
> 
> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>     This method is only called from methods already protected by the lock.
>     Also the method has been made private.
> 
> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>     and without protection by the `KeepAliveCleanerEntry`.
>     Lock protection is also added to `close()`, which was missing it.
>     Some methods that have no lock protection and did not need it because only called from
>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
> 
> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
> 
> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>     holding the lock.
>     Synchronization was also removed from some method that didn't need it because only
>     called from within code blocks protected by the lock:
>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
> 
> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

Mostly looks good.

HttpClient.openServer - is there a reason to do the SM permission check while holding the lock?

The "closed" field in MeteredStream and ChunkedInputStream needs to be volatile if you really want to read it without
holding the lock.

There are a couple of places with comments that I assume you added for yourself when auditing this code. There's one in
HttpCapture, and 3 in HttpURLConnection.

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

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

From dfuchs at openjdk.java.net  Thu Oct  8 17:39:21 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 8 Oct 2020 17:39:21 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
In-Reply-To: <X1gX-ShW_Uahvw68q2I8tXLxQimuoC0IkWI68X_exqk=.dec8a4cc-5b4e-43cc-8557-357346dc1190@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <X1gX-ShW_Uahvw68q2I8tXLxQimuoC0IkWI68X_exqk=.dec8a4cc-5b4e-43cc-8557-357346dc1190@github.com>
Message-ID: <W-oXH74MHzVWd0_2w3J8DG1gE2rSsPP_v0Bf29zwAFY=.632ca5a0-cdb8-4da3-9b54-241d969d0b4b@github.com>

On Thu, 8 Oct 2020 17:14:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
>> synchronized monitors.
>> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
>> outlined below:
>> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>>    ( a snapshot of the data is taken before printing instead)
>> 
>> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
>> 
>> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>>     casting to PrintStream.
>> 
>> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>>     There is no need for a synchronized here as the method is only called from a method that already
>>     holds the lock.
>> 
>> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>>     This method is only called from methods already protected by the lock.
>>     Also the method has been made private.
>> 
>> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>>     and without protection by the `KeepAliveCleanerEntry`.
>>     Lock protection is also added to `close()`, which was missing it.
>>     Some methods that have no lock protection and did not need it because only called from
>>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
>> 
>> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
>> 
>> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>>     holding the lock.
>>     Synchronization was also removed from some method that didn't need it because only
>>     called from within code blocks protected by the lock:
>>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
>> 
>> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>
> Mostly looks good.
> 
> HttpClient.openServer - is there a reason to do the SM permission check while holding the lock?
> 
> The "closed" field in MeteredStream and ChunkedInputStream needs to be volatile if you really want to read it without
> holding the lock.
> There are a couple of places with comments that I assume you added for yourself when auditing this code. There's one in
> HttpCapture, and 3 in HttpURLConnection.

Thanks Alan!

> HttpClient.openServer - is there a reason to do the SM permission check while holding the lock?

Mostly that was a mechanical change since openServer was synchronized before.
But I guess it seems also desirable for accessing host & port which are protected and not final;

> The "closed" field in MeteredStream and ChunkedInputStream needs to be volatile if you really want to read it without
> holding the lock.

I am not so sure. `closed` starts at `false`, and can only moved from `false` to `true`. It can never go back to
`false` after it's been set to `true`; So if you observe `true` outside of the lock it does means that it is really
closed, isn't it?  If `closed` is not volatile, the worse that can happen is that you will observe `false` while it's
really `true`, and then you will need to pay the price of locking, after which you should be able to see the real
`true` value.

> There are a couple of places with comments that I assume you added for yourself when auditing this code. There's one in
> HttpCapture, and 3 in HttpURLConnection.

Yes - well - I thought that would be mostly beneficial for someone searching for `synchronized` in the java/net and
sun/net packages - so that they can determine that the `synchronized` in those places was considered safe and
intentionally kept unchanged, and not just overlooked. I can remove them or reformulate if you think it's better - but
I was actually intending to keep these comments.

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

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

From alanb at openjdk.java.net  Fri Oct  9 07:08:27 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 9 Oct 2020 07:08:27 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
In-Reply-To: <W-oXH74MHzVWd0_2w3J8DG1gE2rSsPP_v0Bf29zwAFY=.632ca5a0-cdb8-4da3-9b54-241d969d0b4b@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <X1gX-ShW_Uahvw68q2I8tXLxQimuoC0IkWI68X_exqk=.dec8a4cc-5b4e-43cc-8557-357346dc1190@github.com>
 <W-oXH74MHzVWd0_2w3J8DG1gE2rSsPP_v0Bf29zwAFY=.632ca5a0-cdb8-4da3-9b54-241d969d0b4b@github.com>
Message-ID: <WljhsNCLcoAZSYKWQP3vx3uQ8ck6v5SZC8T2vSA1G3A=.f9cb1b8e-8a5f-4b1d-b6d4-0520962a1216@github.com>

On Thu, 8 Oct 2020 17:36:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Mostly that was a mechanical change since openServer was synchronized before.
> But I guess it seems also desirable for accessing host & port which are protected and not final;

Okay, I mis-read the old code. The syncrhonization to access host/port isn't obvious so leaving it as is is okay.
 
> I am not so sure. `closed` starts at `false`, and can only moved from `false` to `true`. It can never go back to
> `false` after it's been set to `true`; So if you observe `true` outside of the lock it does means that it is really
> closed, isn't it? If `closed` is not volatile, the worse that can happen is that you will observe `false` while it's
> really `true`, and then you will need to pay the price of locking, after which you should be able to see the real
> `true` value.

Allowing for visibility failures here is confusing for maintainers. If you really want to access closed without the
lock (and I don't see any reason to do that) then it would be clearer to all if it were volatile.


> Yes - well - I thought that would be mostly beneficial for someone searching for `synchronized` in the java/net and
> sun/net packages - so that they can determine that the `synchronized` in those places was considered safe and
> intentionally kept unchanged, and not just overlooked. I can remove them or reformulate if you think it's better - but
> I was actually intending to keep these comments.

I don't have. a strong opinion here but they did initially look like left over comments. Will they mean anything to
someone looking at this code in 2025?

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

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

From chegar at openjdk.java.net  Fri Oct  9 08:18:11 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 9 Oct 2020 08:18:11 GMT
Subject: RFR: 8252374: Add a new factory method to concatenate a sequence
 of BodyPublisher instances into a single publisher. [v11]
In-Reply-To: <tTP7yqN7n5rKYa1s6murm3G3oFVlgNaG9YCvQQujoyA=.f1acd912-f95d-4c1c-a096-6e351ef6a2ff@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
 <tTP7yqN7n5rKYa1s6murm3G3oFVlgNaG9YCvQQujoyA=.f1acd912-f95d-4c1c-a096-6e351ef6a2ff@github.com>
Message-ID: <c0jyGNem3ccnfPzDLqJe-ua835vNKLY_aVCTHd_UM9Y=.d6d6707c-9baf-4262-ab96-307687932c20@github.com>

On Wed, 7 Oct 2020 13:12:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Continuing the review with a PR...
>> 
>> 8252374: Add a new factory method to concatenate a sequence
>>          of BodyPublisher instances into a single publisher.
>> https://bugs.openjdk.java.net/browse/JDK-8252374
>> 
>> 
>> Draft CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8252382
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since
> the last revision:
>  - Merge
>  - Added a plain test for positive requests.
>  - Keep changes to PullPublisher for a later fix
>  - Fixed handling of negative request. Added BodyPublishers::concat to the TCK tests.
>  - Use a dataProvider for testNegativeRequest
>  - Merge
>  - Added a test case for requesting a non positive number of items.
>  - Merge
>  - Incorporated review comments
>  - Improved the API documentation of BodyPublishers::concat
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/2210e3d2...9ff5a3b3

Marked as reviewed by chegar (Reviewer).

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

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

From chegar at openjdk.java.net  Fri Oct  9 09:04:22 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 9 Oct 2020 09:04:22 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
In-Reply-To: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
Message-ID: <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>

On Thu, 8 Oct 2020 11:22:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
> synchronized monitors.
> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
> outlined below:
> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>    ( a snapshot of the data is taken before printing instead)
> 
> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
> 
> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>     casting to PrintStream.
> 
> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>     There is no need for a synchronized here as the method is only called from a method that already
>     holds the lock.
> 
> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>     This method is only called from methods already protected by the lock.
>     Also the method has been made private.
> 
> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>     and without protection by the `KeepAliveCleanerEntry`.
>     Lock protection is also added to `close()`, which was missing it.
>     Some methods that have no lock protection and did not need it because only called from
>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
> 
> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
> 
> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>     holding the lock.
>     Synchronization was also removed from some method that didn't need it because only
>     called from within code blocks protected by the lock:
>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
> 
> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

Mostly looks good. Just a few comments.

src/java.base/share/classes/sun/net/www/MessageHeader.java line 330:

> 328:         at the end. Omits pairs with a null key. Omits
> 329:         colon if key-value pair is the requestline. */
> 330:     private  void print(int nkeys, String[] keys, String[] values, PrintStream p) {

While not strictly necessary, this method (along with isRequestline) could be _static_. Which ensures that their
implementations do not access instance fields.

src/java.base/share/classes/sun/net/www/MeteredStream.java line 123:

> 121:         lock();
> 122:         try {
> 123:             if (closed) return -1;

This double check of `closed` is kind of irritating. Is it really need, or maybe we just drop it and lock
unconditionally?

src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java line 69:

> 67:     public void close() throws IOException  {
> 68:         // If the inputstream is closed already, or if this stream
> 69:         // has already been queued for cleanup.just return.

Minor typo, "cleanup.just"

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

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

From chegar at openjdk.java.net  Fri Oct  9 09:18:23 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 9 Oct 2020 09:18:23 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v17]
In-Reply-To: <cHLt3KxXbRfBSo7EX--jOzxQWLj7Afp-1l9tWg7rwMw=.2e9e408d-05c8-4c9d-aaf2-5027ff7e6d81@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <cHLt3KxXbRfBSo7EX--jOzxQWLj7Afp-1l9tWg7rwMw=.2e9e408d-05c8-4c9d-aaf2-5027ff7e6d81@github.com>
Message-ID: <bWk_AYECv8BfJyLjLRByYY3DMDX5c9UyCqt8BRfrYkc=.b3f8388a-4b80-40e4-a691-d8ee119a460c@github.com>

On Tue, 6 Oct 2020 19:53:18 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unixdomainchannels:
>   - updated property name
>   - added JFR unit test

src/java.base/share/classes/java/net/UnixDomainSocketAddress.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

Can the copyright year range for 2020 be added please.

src/java.base/share/classes/java/net/UnixDomainSocketAddress.java line 139:

> 137:
> 138:     /**
> 139:      * Create a UnixDomainSocketAddress from the given path string.

Create*S* a ...

src/java.base/share/classes/java/net/UnixDomainSocketAddress.java line 156:

> 154:
> 155:     /**
> 156:      * Create a UnixDomainSocketAddress for the given path.

Create*S* a ...

src/java.base/share/classes/java/net/UnixDomainSocketAddress.java line 173:

> 171:
> 172:     /**
> 173:      * Return this address's path.

Return*S* this ...

test/jdk/java/nio/channels/unixdomain/AddressTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

Can the copyright year range for 2020 be added please.

test/jdk/java/nio/channels/unixdomain/AddressTest.java line 49:

> 47:             throw new RuntimeException("Expected illegal path exception");
> 48:         } catch (IllegalArgumentException e) {}
> 49:     }

Would be a good candidate for a testng test, using assertThrows or similar.

test/jdk/java/nio/channels/unixdomain/IOExchanges.java line 113:

> 111:         SPINBAccep_NBConn_NBIO_WR_11a
> 112:         SPINBAccep_NBConn_NBIO_RW_12a
> 113:     */

I recognise this test ;-)  I thought there was a version for IP-specific channels, but cannot find it now. I was going
to ask if these could be merged or abstracted out somehow.

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

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

From dfuchs at openjdk.java.net  Fri Oct  9 09:20:18 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 9 Oct 2020 09:20:18 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
In-Reply-To: <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
Message-ID: <5ozPffL2Nf9a84cIlodNQskaGWTab98tgpEPRgPOMkQ=.2d343a27-a6f0-415d-b80e-570b790241f3@github.com>

On Fri, 9 Oct 2020 08:36:03 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
>> synchronized monitors.
>> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
>> outlined below:
>> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>>    ( a snapshot of the data is taken before printing instead)
>> 
>> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
>> 
>> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>>     casting to PrintStream.
>> 
>> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>>     There is no need for a synchronized here as the method is only called from a method that already
>>     holds the lock.
>> 
>> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>>     This method is only called from methods already protected by the lock.
>>     Also the method has been made private.
>> 
>> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>>     and without protection by the `KeepAliveCleanerEntry`.
>>     Lock protection is also added to `close()`, which was missing it.
>>     Some methods that have no lock protection and did not need it because only called from
>>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
>> 
>> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
>> 
>> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>>     holding the lock.
>>     Synchronization was also removed from some method that didn't need it because only
>>     called from within code blocks protected by the lock:
>>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
>> 
>> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>
> src/java.base/share/classes/sun/net/www/MeteredStream.java line 123:
> 
>> 121:         lock();
>> 122:         try {
>> 123:             if (closed) return -1;
> 
> This double check of `closed` is kind of irritating. Is it really need, or maybe we just drop it and lock
> unconditionally?

We could.

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

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

From michaelm at openjdk.java.net  Fri Oct  9 10:49:20 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 9 Oct 2020 10:49:20 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers
In-Reply-To: <5ozPffL2Nf9a84cIlodNQskaGWTab98tgpEPRgPOMkQ=.2d343a27-a6f0-415d-b80e-570b790241f3@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
 <5ozPffL2Nf9a84cIlodNQskaGWTab98tgpEPRgPOMkQ=.2d343a27-a6f0-415d-b80e-570b790241f3@github.com>
Message-ID: <uvmnU8YrXg8pKCxaw4X-2tJ7oKLQwQIyiZTgJXst24E=.c5af4570-aa3d-4d14-b737-1850a00506bf@github.com>

On Fri, 9 Oct 2020 09:17:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/MeteredStream.java line 123:
>> 
>>> 121:         lock();
>>> 122:         try {
>>> 123:             if (closed) return -1;
>> 
>> This double check of `closed` is kind of irritating. Is it really need, or maybe we just drop it and lock
>> unconditionally?
>
> We could. That's a good suggestion.

I agree on that point.

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

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

From dfuchs at openjdk.java.net  Fri Oct  9 11:49:30 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 9 Oct 2020 11:49:30 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v2]
In-Reply-To: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
Message-ID: <R-BFYZ5t_YWCmanhcjdv1tbF9wP7ywNzrXOGmVM8hi0=.75dcd24f-ac56-4b3e-83e1-b6495b69154f@github.com>

> Hi,
> 
> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
> synchronized monitors.
> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
> outlined below:
> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>    ( a snapshot of the data is taken before printing instead)
> 
> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
> 
> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>     casting to PrintStream.
> 
> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>     There is no need for a synchronized here as the method is only called from a method that already
>     holds the lock.
> 
> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>     This method is only called from methods already protected by the lock.
>     Also the method has been made private.
> 
> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>     and without protection by the `KeepAliveCleanerEntry`.
>     Lock protection is also added to `close()`, which was missing it.
>     Some methods that have no lock protection and did not need it because only called from
>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
> 
> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
> 
> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>     holding the lock.
>     Synchronization was also removed from some method that didn't need it because only
>     called from within code blocks protected by the lock:
>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
> 
> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  8229867: Re-examine synchronization usages in http and https protocol handlers
  
  Incorporated review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/558/files
  - new: https://git.openjdk.java.net/jdk/pull/558/files/c8dc2ac9..ddfa2e6c

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

  Stats: 35 lines in 8 files changed: 15 ins; 14 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/558/head:pull/558

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

From dfuchs at openjdk.java.net  Fri Oct  9 12:08:44 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 9 Oct 2020 12:08:44 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v2]
In-Reply-To: <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
Message-ID: <U1yJnZu7ah24u1n7k8buGzEEDVheZKrnzO55iz3Way0=.4df04090-7eea-4eac-b481-087cd6eab0df@github.com>

On Fri, 9 Oct 2020 08:49:54 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8229867: Re-examine synchronization usages in http and https protocol handlers
>>   
>>   Incorporated review feedback
>
> src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java line 69:
> 
>> 67:     public void close() throws IOException  {
>> 68:         // If the inputstream is closed already, or if this stream
>> 69:         // has already been queued for cleanup.just return.
> 
> Minor typo, "cleanup.just"

done

> src/java.base/share/classes/sun/net/www/MessageHeader.java line 330:
> 
>> 328:         at the end. Omits pairs with a null key. Omits
>> 329:         colon if key-value pair is the requestline. */
>> 330:     private  void print(int nkeys, String[] keys, String[] values, PrintStream p) {
> 
> While not strictly necessary, this method (along with isRequestline) could be _static_. Which ensures that their
> implementations do not access instance fields.

Done.

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

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

From dfuchs at openjdk.java.net  Fri Oct  9 12:12:05 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 9 Oct 2020 12:12:05 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v2]
In-Reply-To: <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <MPjRBQUvT9XOFQZmR2IWR1QSCX9hKWlyBDUTN3e-v0E=.0825ef82-d3a9-46d1-9d7b-11630f0273ac@github.com>
Message-ID: <GuD5BTUOROnbReIWDe3_y0iRbTZNljs1u4XK7PuUDps=.0d44fc9b-d9bd-42ae-935a-4d31dd77b085@github.com>

On Fri, 9 Oct 2020 09:01:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8229867: Re-examine synchronization usages in http and https protocol handlers
>>   
>>   Incorporated review feedback
>
> Mostly looks good. Just a few comments.

>From Alan:

> Allowing for visibility failures here is confusing for maintainers. If you really want to access closed without the
> lock (and I don't see any reason to do that) then it would be clearer to all if it were volatile.

>From Chris:

> This double check of closed is kind of irritating. Is it really need, or maybe we just drop it and lock unconditionally?

=> I have removed the double locking.

>From Alan:

> I don't have a strong opinion here but they did initially look like left over comments. Will they mean anything to
> someone looking at this code in 2025?

I have updated the comments to be more explanatory for future maintainer (especially if they use the Annotate feature
of the IDE to correlate with the fix in which they were introduced). That said, if you prefer removing them altogether
let me know, and I'll remove them.

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

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

From alanb at openjdk.java.net  Fri Oct  9 13:25:10 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 9 Oct 2020 13:25:10 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v2]
In-Reply-To: <R-BFYZ5t_YWCmanhcjdv1tbF9wP7ywNzrXOGmVM8hi0=.75dcd24f-ac56-4b3e-83e1-b6495b69154f@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <R-BFYZ5t_YWCmanhcjdv1tbF9wP7ywNzrXOGmVM8hi0=.75dcd24f-ac56-4b3e-83e1-b6495b69154f@github.com>
Message-ID: <l0xLm5f5wPtcvvvPzQ1oXLLTy2M8VgtovDDD4qYkBGg=.f3f7f902-3372-4387-bccf-341576835708@github.com>

On Fri, 9 Oct 2020 11:49:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
>> synchronized monitors.
>> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
>> outlined below:
>> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>>    ( a snapshot of the data is taken before printing instead)
>> 
>> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
>> 
>> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>>     casting to PrintStream.
>> 
>> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>>     There is no need for a synchronized here as the method is only called from a method that already
>>     holds the lock.
>> 
>> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>>     This method is only called from methods already protected by the lock.
>>     Also the method has been made private.
>> 
>> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>>     and without protection by the `KeepAliveCleanerEntry`.
>>     Lock protection is also added to `close()`, which was missing it.
>>     Some methods that have no lock protection and did not need it because only called from
>>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
>> 
>> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
>> 
>> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>>     holding the lock.
>>     Synchronization was also removed from some method that didn't need it because only
>>     called from within code blocks protected by the lock:
>>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
>> 
>> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8229867: Re-examine synchronization usages in http and https protocol handlers
>   
>   Incorporated review feedback

src/java.base/share/classes/sun/net/www/http/HttpCapture.java line 59:

> 57:     // Although accessing files could result in blocking operations,
> 58:     // HttpCapture is a corner case; there seem no urgent need to convert
> 59:     // this class to using java.util.concurrent.locks at this time.

The updated patch looks good but I think this comment needs another iteration to ensure that it doesn't confuse future
maintainers. You could drop it or else replace it with something simple that says that HttpCapture does blocking I/O
operations while holding monitors but it's not a concern because it rarely used.

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

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

From michaelm at openjdk.java.net  Fri Oct  9 14:39:14 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 9 Oct 2020 14:39:14 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v17]
In-Reply-To: <bWk_AYECv8BfJyLjLRByYY3DMDX5c9UyCqt8BRfrYkc=.b3f8388a-4b80-40e4-a691-d8ee119a460c@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <cHLt3KxXbRfBSo7EX--jOzxQWLj7Afp-1l9tWg7rwMw=.2e9e408d-05c8-4c9d-aaf2-5027ff7e6d81@github.com>
 <bWk_AYECv8BfJyLjLRByYY3DMDX5c9UyCqt8BRfrYkc=.b3f8388a-4b80-40e4-a691-d8ee119a460c@github.com>
Message-ID: <EXz8LlJk-TI-j89e-OPtAMSokvBOzo9CElhMWC1_6MY=.b5083ac8-eb0f-411f-b7b5-b1ca8a1fa3a5@github.com>

On Fri, 9 Oct 2020 09:14:33 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   unixdomainchannels:
>>   - updated property name
>>   - added JFR unit test
>
> test/jdk/java/nio/channels/unixdomain/IOExchanges.java line 113:
> 
>> 111:         SPINBAccep_NBConn_NBIO_WR_11a
>> 112:         SPINBAccep_NBConn_NBIO_RW_12a
>> 113:     */
> 
> I recognise this test ;-)  I thought there was a version for IP-specific channels, but cannot find it now. I was going
> to ask if these could be merged or abstracted out somehow.

Chris,
Thanks for the comments. I will incorporate them all into the next revision. As regards the IOExchanges test, it uses a
@DataProvider of ProtocolFamily with values "UNIX" and "INET" which means the tests are run for TCP sockets. Is that
what you were asking? I'm not sure I get the question exactly. Michael.

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

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

From michaelm at openjdk.java.net  Fri Oct  9 14:55:25 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 9 Oct 2020 14:55:25 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v18]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <bpcXkVMyCZ5PgKeRTbAP2vnf3_cYOsvyO-558Aidf_Y=.3be79c9a-66b6-4f37-8b15-121fb43e9111@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels: updates from Chris's review 9 Oct 2020

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/0e8e527f..cb28f3c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=16-17

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

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

From michaelm at openjdk.java.net  Mon Oct 12 11:06:12 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 12 Oct 2020 11:06:12 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <pj2L_CiUy60Ifew4KZ37wJl5tDPin3_ZPzW0rL-IoBE=.feca82ef-4de2-46d7-8810-989bb1d1a72a@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
 <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>
 <pj2L_CiUy60Ifew4KZ37wJl5tDPin3_ZPzW0rL-IoBE=.feca82ef-4de2-46d7-8810-989bb1d1a72a@github.com>
Message-ID: <BS_3HOYA_pJiIEWrE6L4zQDQgkDIIJrJblqnZmc2poI=.953702a1-33be-4651-89d6-fb9223d834e0@github.com>

On Mon, 5 Oct 2020 15:09:53 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Build changes look good.
>
> Thanks again Alan. Assume where there is no comment from me below that suggestions are accepted:
> I will push an update based on these changes soon.
> 
> Michael.
> 
>> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
>> [nio-dev](mailto:nio-dev at openjdk.java.net):_
>> On 04/10/2020 14:14, Michael McMahon wrote:
>> Another round of comments, this time on v14.
>> 
>> src/java.base/share/classes/java/net/StandardProtocolFamily.java
>> - the enum constant is "UNIX" and might be better to put "Local" in
>> parentheses rather than "Unix domain".
>> 
>> src/java.base/share/classes/java/nio/channels/package-info.java
>> - L260 ends with "family only", I think "only" can be dropped.
>> 
>> src/java.base/share/classes/java/net/UnixDomainSocketAddress.java
>> - left over "fix message" comments in constructor
>> - a few formatting nits in the equals method due to a spurious space in
>> the expression at L192, and missing a space at L194.
>> 
> 
> I don't see a missing space at L194 ?
> 
>> src/java.base/share/classes/sun/net/util/SocketExceptions.java
>> - Can of(IOException e, SocketAddress addr) check enhancedExceptionText
>> to avoid the ugly check in the ofXXX methods?
>> - Can you explain the inconsistency in the null handling for the address
>> types, maybe a left over from an early prototype?
>> 
> 
> The null check was always there for Inet sockets. It is not required for Unix
> but would be benign. So, the check can be promoted to the calling method.
> 
>> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
>> - I think we need to change the class descriptions of both to start with
>> "Base implementations ..."
>> - We need to find a clean way to push the socket() method down to the
>> InetXXXImpl classes as they are the only classes that should know about
>> the socket adaptors.
> 
> Only way to do this is to define yet another implXXX method (implSocket)
> but I think it is worthwhile as neither the field nor the implementation
> belong in the super class
> 
>> 
>> src/java.base/share/classes/sun/nio/ch/UnixDomainServerSocketChannelImpl.java
>> - implBind should not loop/retry when a local address is provided
> 
> It actually catches the BindException and rethrows it when 'local != null, but maybe
> the comment above the loop is confusing. I will reword it.
> 
>> - what behavior is expected when getTempDir returns null?
> 
> I was assuming that ${java.io.tmpdir} would always be defined, but I see
> getTempDir() could be more robust in dealing with errors in the preceding
> search steps. So, in the unlikely event that ${java.io.tmpdir} is not defined
> null would be returned. I will change to throw a BindException in that case.
> 
>> - Why doesn't this code use SecureRandom, as is done in the Windows
>> Selector implementation.
> 
> It does use SecureRandom but only uses the Random api.
> 
>> - Can supportedOptions be changed to return
>> Set.of(StandardSocketOptions.SO_RCVBUF)?
> 
> I can simplify that code definitely, but I think for consistency it should
> still return a static unmodifiable instance
> 
>> - toString has a left over "TODO".
>> - The message for the IOException in implBind should start with a
>> capital to be consistent with the other exceptions thrown in this area
>> 
>> src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java
>> - The initializer sets the system property
>> "jdk.nio.channels.unixdomain.maxnamelength". Looks like it's to help the
>> tests so need to find another solution for the tests.
> 
> Okay, the tests didn't really need this anyway
> 
>> - checkCapability should be renamed to checkPermission as it does a
>> security manager check. Would it more be consistent with existing code
>> if changed to "if (sm != null) sm.checkPermission(...)"
>> - Can inTempDirectory be removed as it doesn't seem to be used and
>> raises several questions if it is needed.
>> - getTempName should use the path separator rather than "/".? Also I
>> don't think "nio" should be in the name.
>> - Can the init method be removed, may be a left over from a previous
>> iteration.
>> - The left breaks in the initialization of UNNAMED and support seem
>> unnecessary, maybe they were very long in previous iterations?
>> - Several methods are public, is that intentional, or maybe a left over?
>> 
>> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
>> => Is the intention to put the NET_ functions into libnet or libnio? The
>> function prototypes are declared in net_util.h but the functions have
>> been compiled in libnio.
>> 
> 
> They were probably in libnet originally, but makes more sense to be
> in libnio. So, I will move the function prototypes to nio_util.h and rename
> them to remove the NET_ prefix.
> 
>> src/java.base/share/classes/sun/nio/ch/Net.java
>> - spurious blank line, probably left over from a previous iteration.
>> 
>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java
>> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
>> - getSunPathForSocketFile should not accept null, let
>> to{Unix,Windows}Path handle it
>> 
>> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
>> src/java.base/windows/classes/sun/nio/ch/SinkChannelImpl.java
>> src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
>> - The changes to PipeImpl look like they will set TCP_NODELAY for users
>> of the Pipe API on older Windows releases. I think I would prefer to see
>> a parameter on the PipeImpl constructor to indicate if there should
>> buffered/nodelay or not. That way it will be clearer for the two usages
>> of PipeImpl.
> 
> Right, good point.
> 
>> - The volatile noUnixDomainSockets does not need to be initialized to false.
>> 
>> src/jdk.net/share/classes/jdk/net/UnixDomainPrincipal.java
>> - if records are finalized in Java 16 then this may be a candidate to be
>> a record
>> 
> 
> Right. I don't think there is anything we can do further we can do right now
> on this point, but if records make it, then it would be a simple API change to make.
> 
>> test/jdk/java/nio/channels/etc/ProtocolFamilies.java
>> - minor nit but the existing test uses "ssc", "sc", and "dc" so best to
>> keep it consistent if you can.
>> 
>> test/jdk/jdk/nio/Basic.java
>> - can you change this to use
>> Class.forName("sun.nio.ch.InetSocketChannelImpl"), that should be
>> cleaner and void the retry and introducing getFD1.
>> 
> 
> Good idea, but needs to be "sun.nio.ch.SocketChannelImpl" I think
> 
>> I'm still working through the changes to the InheritedChannel
>> implementation and all the changes/additions of tests so more comments
>> soon on that aspect of the patch.
>> 
>> -Alan.

> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
> [nio-dev](mailto:nio-dev at openjdk.java.net):_
> I went through the latest patch, v18.
> 
> I'm still a bit uncomfortable with splitting up SocketChannelImpl and
> ServerSocketChannelImpl but okay with go along with this for now if we
> can continue explore alternatives. Given that the InetXXX and UnixXXX
> sub-classes aren't too big then one thing that we can try is just
> special casing the protocol family in the 4-5 methods that are
> different. In the mean-time, I think the abstract methods in
> SocketChannelImpl and ServerSocketChannelImpl should have a clear method
> description on what the implXXX method should. I would prefer the other
> methods be changed to final so that it's clear that they cannot be
> overridden. implSocket is new in v17 or v18 and I'd prefer if that were
> abstract so it can be implemented in UnixXXX to throw UOE.
> 

Okay, I'll take a look at pulling all the changes back into one SocketChannelImpl
and ServerSocketChannelImpl.

> I think the JFR events need another look. Are UnixSocketReadEvent and
> UnixSocketWriteEvent really needed? SocketXXXEvent "address" is just a
> String so it can be used for any address type, the port can be left as
> 0. Part of this comment is wondering if a parallel set of events are
> really needed. Part of it that I would prefer if the read/write methods
> were final in SocketChannelImpl.
> 

The existing socket read/write events include these fields:

    @Label("Remote Host")
    public String host;

    @Label("Remote Address")
    public String address;

    @Label("Remote Port")
    public int port;

I guess, address could be used to encode a path name. port could just be set to -1
and host could be hard coded to some string which indicates the event relates to
a Unix domain socket. I was originally thinking "localhost" would be a good value,
but it would need to be something more explicit than that, to clearly indicate the
socket type, because remote addresses will often be empty path names.

It could be a string like "Unix domain socket" or if a string with white-space embedded
might cause a problem, then something like  AF_UNIX:<path\> where path is the address (which
might be empty)? Which wouldn't look great imo. I guess some guidance from JFR experts
would help here ...

All comments below look fine.

Thanks
Michael

> You might want to take a pass over the files in the patch as several of
> the new files have copyright dates starting 2012, 2019 and other years,
> probably initially copied from other files.
> 
> A few specific comments on v18:
> 
> src/java.base/share/classes/sun/nio/ch/UnixDomainSocketChannelImpl.java
> - supportedOptions doesn't need to wrap the unmodifable collection with
> Collections.unmodifiableSet
> - I think implBind should be re-worked so the local != null case is not
> handled in the loop body. That will help future maintainers.
> 
> src/java.base/windows/classes/sun/nio/ch/UnixDomainSocketsUtil.java
> - I think we should look at adding JAVA_IO_TMPDIR to StaticProperty.
> 
> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
> - are the AIX specific includes really needed?
> - can unixSocketAddressToSockaddr use if-then-else to avoid the goto.
> - bind0 checks if the path is NULL, is this a left over?
> - the declaration of accept0 is mis-aligned, might be left over from
> refactoring
> 
> src/java.base/unix/native/libnio/ch/InheritedChannel.c
> - might be clearer if matchFamily is renamed to toInetFamily
> 
> src/java.base/unix/classes/sun/nio/ch/InheritedChannel.java
> - peerAddress0 is replaced by peerAddressInet and peerAddressUnix0 which
> looks a bit consistent, maybe rename those to inetPeerAddress0 and
> unixPeerAddress0 ?
> 
> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
> - we've gone through a few iterations on this and only a few minor comments
> - source/sink can be final and I assume no need to change their type
> from SourceChannel/SinkChannel
> - no need to initialize noUnixDomainSockets to false
> - can the comments at L178-179 be turned into a method description.
> 
> Can the tests for java.net.UnixDomainSocketAddress be moved to
> jdk/test/java/net/UnixSocketAddress?
> 
> Could test/jdk/java/nio/file/spi/TestProvider.java be used as
> alternative provider in the test to avoid DummyPath?
> 
> test/jdk/java/nio/channels/etc/ProtocolFamilies.java has been updated to
> add "expectedFamily", is that used?
> 
> test/jdk/java/nio/channels/unixdomain/WindowsDriver.java and
> NonWindowsDriver.java
> - are these needed now? Both of them run the same 5 tests and not clear
> why these tests don't have their own @test tags.
> 
> test/jdk/java/nio/channels/unixdomain/Security.java
> - is there any reason why this test can't run with run
> main/othervm/java.security.policy=java.policy1 -Djava.security.manager ?
> 
> That's all I have from this pass over the changes.
> 
> -Alan

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

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

From dfuchs at openjdk.java.net  Mon Oct 12 12:58:22 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 12:58:22 GMT
Subject: Integrated: 8252374: Add a new factory method to concatenate a
 sequence of BodyPublisher instances into a single publisher.
In-Reply-To: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
References: <oY1CWwK7rYDqFV7ne7vt0iU7xMF6i-ZA-r1w1qgx4Z0=.e1fdb903-209e-42e4-a95c-690f42978bf2@github.com>
Message-ID: <O7hrjcVXmjxCiRPqOkQ2UcXUFriZ7VJ2N-w6epSODYU=.6a6519f9-ef8f-4748-8e96-a811c240bc2d@github.com>

On Mon, 7 Sep 2020 13:54:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Continuing the review with a PR...
> 
> 8252374: Add a new factory method to concatenate a sequence
>          of BodyPublisher instances into a single publisher.
> https://bugs.openjdk.java.net/browse/JDK-8252374
> 
> 
> Draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8252382

This pull request has now been integrated.

Changeset: 4184959d
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4184959d
Stats:     1183 lines in 6 files changed: 1181 ins; 0 del; 2 mod

8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher.

Reviewed-by: chegar

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

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

From pconcannon at openjdk.java.net  Mon Oct 12 13:44:20 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 12 Oct 2020 13:44:20 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer
Message-ID: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>

Hi,

Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
HttpsServer' ?

This fix is set of formatting changes intended to clean up the javadoc of the following classes :

`com.sun.net.httpserver.HttpsExchange`
`com.sun.net.httpserver.HttpsParameters`
`com.sun.net.httpserver.HttpsServer`

This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)

Kind regards,
Patrick

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

Commit messages:
 - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

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

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

From dfuchs at openjdk.java.net  Mon Oct 12 13:50:30 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 13:50:30 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v3]
In-Reply-To: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
Message-ID: <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>

> Hi,
> 
> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
> synchronized monitors.
> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
> outlined below:
> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>    ( a snapshot of the data is taken before printing instead)
> 
> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
> 
> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>     casting to PrintStream.
> 
> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>     There is no need for a synchronized here as the method is only called from a method that already
>     holds the lock.
> 
> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>     This method is only called from methods already protected by the lock.
>     Also the method has been made private.
> 
> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>     and without protection by the `KeepAliveCleanerEntry`.
>     Lock protection is also added to `close()`, which was missing it.
>     Some methods that have no lock protection and did not need it because only called from
>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
> 
> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
> 
> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>     holding the lock.
>     Synchronization was also removed from some method that didn't need it because only
>     called from within code blocks protected by the lock:
>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
> 
> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since
the last revision:

 - 8229867: Re-examine synchronization usages in http and https protocol handlers
   
   Incorporated review feedback
 - Merge
 - 8229867: Re-examine synchronization usages in http and https protocol handlers
   
   Incorporated review feedback
 - 8229867: Re-examine synchronization usages in http and https protocol handlers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/558/files
  - new: https://git.openjdk.java.net/jdk/pull/558/files/ddfa2e6c..d8fa0439

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

  Stats: 23530 lines in 473 files changed: 14274 ins; 6170 del; 3086 mod
  Patch: https://git.openjdk.java.net/jdk/pull/558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/558/head:pull/558

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

From dfuchs at openjdk.java.net  Mon Oct 12 13:50:31 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 13:50:31 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v2]
In-Reply-To: <l0xLm5f5wPtcvvvPzQ1oXLLTy2M8VgtovDDD4qYkBGg=.f3f7f902-3372-4387-bccf-341576835708@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <R-BFYZ5t_YWCmanhcjdv1tbF9wP7ywNzrXOGmVM8hi0=.75dcd24f-ac56-4b3e-83e1-b6495b69154f@github.com>
 <l0xLm5f5wPtcvvvPzQ1oXLLTy2M8VgtovDDD4qYkBGg=.f3f7f902-3372-4387-bccf-341576835708@github.com>
Message-ID: <NfWXitVRejEMzaJTly-QRze-ZKUU4yExhY5O9HvZpZo=.a28e89ba-8e72-4284-b07d-06d4eb55d6cb@github.com>

On Fri, 9 Oct 2020 13:22:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8229867: Re-examine synchronization usages in http and https protocol handlers
>>   
>>   Incorporated review feedback
>
> src/java.base/share/classes/sun/net/www/http/HttpCapture.java line 59:
> 
>> 57:     // Although accessing files could result in blocking operations,
>> 58:     // HttpCapture is a corner case; there seem no urgent need to convert
>> 59:     // this class to using java.util.concurrent.locks at this time.
> 
> The updated patch looks good but I think this comment needs another iteration to ensure that it doesn't confuse future
> maintainers. You could drop it or else replace it with something simple that says that HttpCapture does blocking I/O
> operations while holding monitors but it's not a concern because it rarely used.

Updated as requested.

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

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

From alanb at openjdk.java.net  Mon Oct 12 14:16:13 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 12 Oct 2020 14:16:13 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v3]
In-Reply-To: <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>
Message-ID: <3ZfHI2iWTIkNhZHDEAUTXxBDfajuDu21McbJWNmf-5c=.007587e5-7d25-432d-8d77-a006524833cd@github.com>

On Mon, 12 Oct 2020 13:50:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
>> synchronized monitors.
>> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
>> outlined below:
>> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>>    ( a snapshot of the data is taken before printing instead)
>> 
>> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
>> 
>> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>>     casting to PrintStream.
>> 
>> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>>     There is no need for a synchronized here as the method is only called from a method that already
>>     holds the lock.
>> 
>> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>>     This method is only called from methods already protected by the lock.
>>     Also the method has been made private.
>> 
>> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>>     and without protection by the `KeepAliveCleanerEntry`.
>>     Lock protection is also added to `close()`, which was missing it.
>>     Some methods that have no lock protection and did not need it because only called from
>>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
>> 
>> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
>> 
>> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>>     holding the lock.
>>     Synchronization was also removed from some method that didn't need it because only
>>     called from within code blocks protected by the lock:
>>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
>> 
>> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since
> the last revision:
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers
>    
>    Incorporated review feedback
>  - Merge
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers
>    
>    Incorporated review feedback
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.java.net  Mon Oct 12 19:18:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 19:18:12 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <u46_TLScNFJZSOsyabac2AugF1gv3zGnkRqYjlfdO-w=.fa0717a0-2566-404e-9f74-51e033f049a1@github.com>

On Mon, 12 Oct 2020 13:37:04 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Changes requested by dfuchs (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsExchange.java line 43:

> 41:      * Constructor for subclasses to call.
> 42:      */
> 43:     protected HttpsExchange() {}

Ah. I guess this trivial change will require a CSR...

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 48:

> 46:
> 47:     /**
> 48:      */

If you're going to write a CSR, then you could as well provide the "Constructor for subclasses to call." comment...

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 60:

> 58:      * {@link #setHttpsConfigurator(HttpsConfigurator)}.
> 59:      *
> 60:      * @throws IOException if an I/O error occurs

Third change that will need to be listed in the CSR (filling out the @throws comment)

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 81:

> 79:      *             the address
> 80:      * @param backlog the socket backlog. If this value is less than or equal to
> 81:      *               zero, then a system default value is used

There is more than one sentence here, and the second sentence is a full sentence so I believe you'll need a full-stop
at the end.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 84:

> 82:      * @throws BindException if the server cannot bind to the requested address,
> 83:      *          or if the server is already bound
> 84:      * @throws IOException if an I/O error occurs

This one needs to be listed in the CSR too.

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

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

From dfuchs at openjdk.java.net  Mon Oct 12 19:18:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 19:18:12 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer
In-Reply-To: <u46_TLScNFJZSOsyabac2AugF1gv3zGnkRqYjlfdO-w=.fa0717a0-2566-404e-9f74-51e033f049a1@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <u46_TLScNFJZSOsyabac2AugF1gv3zGnkRqYjlfdO-w=.fa0717a0-2566-404e-9f74-51e033f049a1@github.com>
Message-ID: <_6xdA6Y5iMmGOPFHJdZj8hl5vRSQg2vPS0vYsg-dVww=.062990f9-720d-4b3e-be91-ff923e436021@github.com>

On Mon, 12 Oct 2020 19:13:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
>> HttpsServer' ?
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpsExchange`
>> `com.sun.net.httpserver.HttpsParameters`
>> `com.sun.net.httpserver.HttpsServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> Changes requested by dfuchs (Reviewer).

This is a JDK specific API - but since you're updating (filling out) some API doc comments that were previously empty I
suspect a CSR will still be needed.

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

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

From chegar at openjdk.java.net  Tue Oct 13 13:12:14 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 13 Oct 2020 13:12:14 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v3]
In-Reply-To: <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>
Message-ID: <Lo0ckM1LhvYKa_CQ5ORlhzwOxdGiTzqGbjFHqeIGFDw=.ad4d9c50-e520-4407-8b17-b76315042637@github.com>

On Mon, 12 Oct 2020 13:50:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
>> synchronized monitors.
>> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
>> outlined below:
>> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>>    ( a snapshot of the data is taken before printing instead)
>> 
>> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
>> 
>> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>>     casting to PrintStream.
>> 
>> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>>     There is no need for a synchronized here as the method is only called from a method that already
>>     holds the lock.
>> 
>> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>>     This method is only called from methods already protected by the lock.
>>     Also the method has been made private.
>> 
>> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>>     and without protection by the `KeepAliveCleanerEntry`.
>>     Lock protection is also added to `close()`, which was missing it.
>>     Some methods that have no lock protection and did not need it because only called from
>>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
>> 
>> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
>> 
>> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>>     holding the lock.
>>     Synchronization was also removed from some method that didn't need it because only
>>     called from within code blocks protected by the lock:
>>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
>> 
>> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since
> the last revision:
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers
>    
>    Incorporated review feedback
>  - Merge
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers
>    
>    Incorporated review feedback
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers

LGTM.

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

Marked as reviewed by chegar (Reviewer).

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

From michaelm at openjdk.java.net  Tue Oct 13 13:28:17 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 13 Oct 2020 13:28:17 GMT
Subject: RFR: 8229867: Re-examine synchronization usages in http and https
 protocol handlers [v3]
In-Reply-To: <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
 <X6BROx4s1sf7s0djSjnmliomO3rbOXch-lF9yhV3EEU=.b6bc812b-8f72-4b87-bbbb-2ee513969610@github.com>
Message-ID: <SLmRxZiXVvdbLImYfhp2yQwOuJKO-Cin5mU2IWN_7Ew=.30cd9eae-3434-4b34-976c-1e0a2088d138@github.com>

On Mon, 12 Oct 2020 13:50:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
>> synchronized monitors.
>> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
>> outlined below:
>> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>>    ( a snapshot of the data is taken before printing instead)
>> 
>> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
>> 
>> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>>     casting to PrintStream.
>> 
>> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>>     There is no need for a synchronized here as the method is only called from a method that already
>>     holds the lock.
>> 
>> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>>     This method is only called from methods already protected by the lock.
>>     Also the method has been made private.
>> 
>> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>>     and without protection by the `KeepAliveCleanerEntry`.
>>     Lock protection is also added to `close()`, which was missing it.
>>     Some methods that have no lock protection and did not need it because only called from
>>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
>> 
>> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
>> 
>> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>>     holding the lock.
>>     Synchronization was also removed from some method that didn't need it because only
>>     called from within code blocks protected by the lock:
>>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
>> 
>> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>> 
>> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since
> the last revision:
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers
>    
>    Incorporated review feedback
>  - Merge
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers
>    
>    Incorporated review feedback
>  - 8229867: Re-examine synchronization usages in http and https protocol handlers

Marked as reviewed by michaelm (Reviewer).

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

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

From dfuchs at openjdk.java.net  Tue Oct 13 14:25:18 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 13 Oct 2020 14:25:18 GMT
Subject: Integrated: 8229867: Re-examine synchronization usages in http and
 https protocol handlers
In-Reply-To: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
References: <BgNsRIeYafz2D7wlpZgydFjJYYh_fyYQyVGT9ld2pt8=.f8648055-6c39-43df-a095-af190ac3a397@github.com>
Message-ID: <y9OVUVIdd6L05M8aUKfyY6M28JsArq43iA1nmOfq0Q0=.b32dbfea-d8b2-408e-aeeb-3c99b5b9f068@github.com>

On Thu, 8 Oct 2020 11:22:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use virtual-thread friendly locking instead of
> synchronized monitors.
> Most of the changes are mechanical - but there are still a numbers of subtle non-mechanical differences that are
> outlined below:
> 1. src/java.base/share/classes/sun/net/www/MessageHeader.java:
>    `MessageHeader::print(PrintStream)` => synchronization modified to not synchronize on this while printing
>    ( a snapshot of the data is taken before printing instead)
> 
> 2. src/java.base/share/classes/sun/net/www/MeteredStream.java:
>     `MeteredStream::close` was missing synchronization: it is now protected by the lock
> 
> 3. src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java:
>     `ChunkedOutputStream` no longer extends `PrintStream` but extends `OutputStream` directly.
>     Extending `PrintStream` is problematic for virtual thread. After careful analysis, it appeared that
>     `ChunkedOutputStream` didn't really need to extend `PrintStream`. `ChunkedOutputStream`
>     is already wrapping a `PrintStream`.  `ChunkedOutputStream` is never returned directly to user
>     code but is wrapped in another stream. `ChunkedOutputStream` completely reimplement and
>     reverse the flush logic implemented by its old super class`PrintStream` which leads me to believe
>     there was no real reason for it to extend `PrintStream` - except for being able to call its `checkError`
>     method - which can be done by using `instanceof ChunkedOutputStream` in the caller instead of
>     casting to PrintStream.
> 
> 4. src/java.base/share/classes/sun/net/www/http/HttpClient.java:
>     Synchronization removed from `HttpClient::privilegedOpenServer` and replaced by an `assert`.
>     There is no need for a synchronized here as the method is only called from a method that already
>     holds the lock.
> 
> 5. src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java:
>     Synchronization removed from `KeepAliveCache::removeVector` and replaced by an `assert`.
>     This method is only called from methods already protected by the lock.
>     Also the method has been made private.
> 
> 6. src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
>     `queuedForCleanup` is made volatile as it is read and written directly from outside the class
>     and without protection by the `KeepAliveCleanerEntry`.
>     Lock protection is also added to `close()`, which was missing it.
>     Some methods that have no lock protection and did not need it because only called from
>     within code blocks protected by the lock have aquired an `assert isLockHeldByCurrentThread();`
> 
> 7. Concrete subclasses of `AuthenticationInfo` that provide an implementation for
>     `AuthenticationInfo::setHeaders(HttpURLConnection conn, HeaderParser p, String raw)` have
>     acquired an `assert conn.isLockheldByCurrentThread();` as the method should only be called
>     from within a lock-protected block in `s.n.w.p.h.HttpURLConnection`
> 
> 8. src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>     Several methods in this class have a acquired an `assert isLockheldByCurrentThread();`
>     to help track the fact that AuthenticationInfo::setHeaders is only called while
>     holding the lock.
>     Synchronization was also removed from some method that didn't need it because only
>     called from within code blocks protected by the lock:
>     `getOutputStream0()`: synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `setCookieHeader()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `getInputStream0()`:  synchronization removed and replaced by an `assert isLockheldByCurrentThread();`
>     `StreamingOutputStream`: small change to accomodate point 3. above (changes in ChunkedOutputStream).
> 
> 9. src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java.:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 10. src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.
> 
> 11. src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java:
>     synchronization removed from `setHeaders` and replace by an assert. See point 7. above.

This pull request has now been integrated.

Changeset: 65393a09
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65393a09
Stats:     1126 lines in 18 files changed: 558 ins; 156 del; 412 mod

8229867: Re-examine synchronization usages in http and https protocol handlers

Reviewed-by: chegar, alanb, michaelm

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

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

From dfuchs at openjdk.java.net  Tue Oct 13 15:34:29 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 13 Oct 2020 15:34:29 GMT
Subject: RFR: 8254704: Add missing @since tag to BodyPublishers::concat
Message-ID: <yTsgCdduSMzas7G7CuITMxKu84D6liUTkOoMAzqkK9Q=.14d6f1f8-fb78-4946-8642-e975ad0c5efc@github.com>

Please review a trivial change that adds a missing `@since 16` tag to the API documentation of the new
`BodyPublishers::concat` method. I missed that in my changes that was integrated yesterday - and that was unfortunately
missed in the review and CSR as well.

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

Commit messages:
 - 8254704: Add missing @since tag to BodyPublishers::concat

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

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

From chegar at openjdk.java.net  Tue Oct 13 15:34:29 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 13 Oct 2020 15:34:29 GMT
Subject: RFR: 8254704: Add missing @since tag to BodyPublishers::concat
In-Reply-To: <yTsgCdduSMzas7G7CuITMxKu84D6liUTkOoMAzqkK9Q=.14d6f1f8-fb78-4946-8642-e975ad0c5efc@github.com>
References: <yTsgCdduSMzas7G7CuITMxKu84D6liUTkOoMAzqkK9Q=.14d6f1f8-fb78-4946-8642-e975ad0c5efc@github.com>
Message-ID: <3MSVq3EMTKRKnbRua7UUENHhj_9ji7JAJ3f5jSdS0xE=.508c1513-ba9f-4898-a08a-77f50b346651@github.com>

On Tue, 13 Oct 2020 15:22:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please review a trivial change that adds a missing `@since 16` tag to the API documentation of the new
> `BodyPublishers::concat` method. I missed that in my changes that was integrated yesterday - and that was unfortunately
> missed in the review and CSR as well.

Marked as reviewed by chegar (Reviewer).

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

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

From dfuchs at openjdk.java.net  Tue Oct 13 16:57:17 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 13 Oct 2020 16:57:17 GMT
Subject: Integrated: 8254704: Add missing @since tag to BodyPublishers::concat
In-Reply-To: <yTsgCdduSMzas7G7CuITMxKu84D6liUTkOoMAzqkK9Q=.14d6f1f8-fb78-4946-8642-e975ad0c5efc@github.com>
References: <yTsgCdduSMzas7G7CuITMxKu84D6liUTkOoMAzqkK9Q=.14d6f1f8-fb78-4946-8642-e975ad0c5efc@github.com>
Message-ID: <DWyTZ6HVFATCZvrwAYClZ7LdvHQlHRuCYy7lnnUborM=.4d2a3326-844e-4e94-b5b8-1e2f05db633b@github.com>

On Tue, 13 Oct 2020 15:22:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please review a trivial change that adds a missing `@since 16` tag to the API documentation of the new
> `BodyPublishers::concat` method. I missed that in my changes that was integrated yesterday - and that was unfortunately
> missed in the review and CSR as well.

This pull request has now been integrated.

Changeset: 6ed4c89d
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6ed4c89d
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8254704: Add missing @since tag to BodyPublishers::concat

Reviewed-by: chegar

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

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

From michaelm at openjdk.java.net  Tue Oct 13 17:36:12 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 13 Oct 2020 17:36:12 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <BS_3HOYA_pJiIEWrE6L4zQDQgkDIIJrJblqnZmc2poI=.953702a1-33be-4651-89d6-fb9223d834e0@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
 <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>
 <pj2L_CiUy60Ifew4KZ37wJl5tDPin3_ZPzW0rL-IoBE=.feca82ef-4de2-46d7-8810-989bb1d1a72a@github.com>
 <BS_3HOYA_pJiIEWrE6L4zQDQgkDIIJrJblqnZmc2poI=.953702a1-33be-4651-89d6-fb9223d834e0@github.com>
Message-ID: <xQV2iqvRjz1wqBYd6DocCIG1cf87UsnRJR6DuF62ay4=.6d9c4729-4c58-4bbf-8adb-d0709ada8c06@github.com>

On Mon, 12 Oct 2020 11:02:12 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Thanks again Alan. Assume where there is no comment from me below that suggestions are accepted:
>> I will push an update based on these changes soon.
>> 
>> Michael.
>> 
>>> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
>>> [nio-dev](mailto:nio-dev at openjdk.java.net):_
>>> On 04/10/2020 14:14, Michael McMahon wrote:
>>> Another round of comments, this time on v14.
>>> 
>>> src/java.base/share/classes/java/net/StandardProtocolFamily.java
>>> - the enum constant is "UNIX" and might be better to put "Local" in
>>> parentheses rather than "Unix domain".
>>> 
>>> src/java.base/share/classes/java/nio/channels/package-info.java
>>> - L260 ends with "family only", I think "only" can be dropped.
>>> 
>>> src/java.base/share/classes/java/net/UnixDomainSocketAddress.java
>>> - left over "fix message" comments in constructor
>>> - a few formatting nits in the equals method due to a spurious space in
>>> the expression at L192, and missing a space at L194.
>>> 
>> 
>> I don't see a missing space at L194 ?
>> 
>>> src/java.base/share/classes/sun/net/util/SocketExceptions.java
>>> - Can of(IOException e, SocketAddress addr) check enhancedExceptionText
>>> to avoid the ugly check in the ofXXX methods?
>>> - Can you explain the inconsistency in the null handling for the address
>>> types, maybe a left over from an early prototype?
>>> 
>> 
>> The null check was always there for Inet sockets. It is not required for Unix
>> but would be benign. So, the check can be promoted to the calling method.
>> 
>>> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
>>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
>>> - I think we need to change the class descriptions of both to start with
>>> "Base implementations ..."
>>> - We need to find a clean way to push the socket() method down to the
>>> InetXXXImpl classes as they are the only classes that should know about
>>> the socket adaptors.
>> 
>> Only way to do this is to define yet another implXXX method (implSocket)
>> but I think it is worthwhile as neither the field nor the implementation
>> belong in the super class
>> 
>>> 
>>> src/java.base/share/classes/sun/nio/ch/UnixDomainServerSocketChannelImpl.java
>>> - implBind should not loop/retry when a local address is provided
>> 
>> It actually catches the BindException and rethrows it when 'local != null, but maybe
>> the comment above the loop is confusing. I will reword it.
>> 
>>> - what behavior is expected when getTempDir returns null?
>> 
>> I was assuming that ${java.io.tmpdir} would always be defined, but I see
>> getTempDir() could be more robust in dealing with errors in the preceding
>> search steps. So, in the unlikely event that ${java.io.tmpdir} is not defined
>> null would be returned. I will change to throw a BindException in that case.
>> 
>>> - Why doesn't this code use SecureRandom, as is done in the Windows
>>> Selector implementation.
>> 
>> It does use SecureRandom but only uses the Random api.
>> 
>>> - Can supportedOptions be changed to return
>>> Set.of(StandardSocketOptions.SO_RCVBUF)?
>> 
>> I can simplify that code definitely, but I think for consistency it should
>> still return a static unmodifiable instance
>> 
>>> - toString has a left over "TODO".
>>> - The message for the IOException in implBind should start with a
>>> capital to be consistent with the other exceptions thrown in this area
>>> 
>>> src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java
>>> - The initializer sets the system property
>>> "jdk.nio.channels.unixdomain.maxnamelength". Looks like it's to help the
>>> tests so need to find another solution for the tests.
>> 
>> Okay, the tests didn't really need this anyway
>> 
>>> - checkCapability should be renamed to checkPermission as it does a
>>> security manager check. Would it more be consistent with existing code
>>> if changed to "if (sm != null) sm.checkPermission(...)"
>>> - Can inTempDirectory be removed as it doesn't seem to be used and
>>> raises several questions if it is needed.
>>> - getTempName should use the path separator rather than "/".? Also I
>>> don't think "nio" should be in the name.
>>> - Can the init method be removed, may be a left over from a previous
>>> iteration.
>>> - The left breaks in the initialization of UNNAMED and support seem
>>> unnecessary, maybe they were very long in previous iterations?
>>> - Several methods are public, is that intentional, or maybe a left over?
>>> 
>>> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
>>> => Is the intention to put the NET_ functions into libnet or libnio? The
>>> function prototypes are declared in net_util.h but the functions have
>>> been compiled in libnio.
>>> 
>> 
>> They were probably in libnet originally, but makes more sense to be
>> in libnio. So, I will move the function prototypes to nio_util.h and rename
>> them to remove the NET_ prefix.
>> 
>>> src/java.base/share/classes/sun/nio/ch/Net.java
>>> - spurious blank line, probably left over from a previous iteration.
>>> 
>>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java
>>> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
>>> - getSunPathForSocketFile should not accept null, let
>>> to{Unix,Windows}Path handle it
>>> 
>>> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
>>> src/java.base/windows/classes/sun/nio/ch/SinkChannelImpl.java
>>> src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
>>> - The changes to PipeImpl look like they will set TCP_NODELAY for users
>>> of the Pipe API on older Windows releases. I think I would prefer to see
>>> a parameter on the PipeImpl constructor to indicate if there should
>>> buffered/nodelay or not. That way it will be clearer for the two usages
>>> of PipeImpl.
>> 
>> Right, good point.
>> 
>>> - The volatile noUnixDomainSockets does not need to be initialized to false.
>>> 
>>> src/jdk.net/share/classes/jdk/net/UnixDomainPrincipal.java
>>> - if records are finalized in Java 16 then this may be a candidate to be
>>> a record
>>> 
>> 
>> Right. I don't think there is anything we can do further we can do right now
>> on this point, but if records make it, then it would be a simple API change to make.
>> 
>>> test/jdk/java/nio/channels/etc/ProtocolFamilies.java
>>> - minor nit but the existing test uses "ssc", "sc", and "dc" so best to
>>> keep it consistent if you can.
>>> 
>>> test/jdk/jdk/nio/Basic.java
>>> - can you change this to use
>>> Class.forName("sun.nio.ch.InetSocketChannelImpl"), that should be
>>> cleaner and void the retry and introducing getFD1.
>>> 
>> 
>> Good idea, but needs to be "sun.nio.ch.SocketChannelImpl" I think
>> 
>>> I'm still working through the changes to the InheritedChannel
>>> implementation and all the changes/additions of tests so more comments
>>> soon on that aspect of the patch.
>>> 
>>> -Alan.
>
>> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
>> [nio-dev](mailto:nio-dev at openjdk.java.net):_
>> I went through the latest patch, v18.
>> 
>> I'm still a bit uncomfortable with splitting up SocketChannelImpl and
>> ServerSocketChannelImpl but okay with go along with this for now if we
>> can continue explore alternatives. Given that the InetXXX and UnixXXX
>> sub-classes aren't too big then one thing that we can try is just
>> special casing the protocol family in the 4-5 methods that are
>> different. In the mean-time, I think the abstract methods in
>> SocketChannelImpl and ServerSocketChannelImpl should have a clear method
>> description on what the implXXX method should. I would prefer the other
>> methods be changed to final so that it's clear that they cannot be
>> overridden. implSocket is new in v17 or v18 and I'd prefer if that were
>> abstract so it can be implemented in UnixXXX to throw UOE.
>> 
> 
> Okay, I'll take a look at pulling all the changes back into one SocketChannelImpl
> and ServerSocketChannelImpl.
> 
>> I think the JFR events need another look. Are UnixSocketReadEvent and
>> UnixSocketWriteEvent really needed? SocketXXXEvent "address" is just a
>> String so it can be used for any address type, the port can be left as
>> 0. Part of this comment is wondering if a parallel set of events are
>> really needed. Part of it that I would prefer if the read/write methods
>> were final in SocketChannelImpl.
>> 
> 
> The existing socket read/write events include these fields:
> 
>     @Label("Remote Host")
>     public String host;
> 
>     @Label("Remote Address")
>     public String address;
> 
>     @Label("Remote Port")
>     public int port;
> 
> I guess, address could be used to encode a path name. port could just be set to -1
> and host could be hard coded to some string which indicates the event relates to
> a Unix domain socket. I was originally thinking "localhost" would be a good value,
> but it would need to be something more explicit than that, to clearly indicate the
> socket type, because remote addresses will often be empty path names.
> 
> It could be a string like "Unix domain socket" or if a string with white-space embedded
> might cause a problem, then something like  AF_UNIX:<path\> where path is the address (which
> might be empty)? Which wouldn't look great imo. I guess some guidance from JFR experts
> would help here ...
> 
> All comments below look fine.
> 
> Thanks
> Michael
> 
>> You might want to take a pass over the files in the patch as several of
>> the new files have copyright dates starting 2012, 2019 and other years,
>> probably initially copied from other files.
>> 
>> A few specific comments on v18:
>> 
>> src/java.base/share/classes/sun/nio/ch/UnixDomainSocketChannelImpl.java
>> - supportedOptions doesn't need to wrap the unmodifable collection with
>> Collections.unmodifiableSet
>> - I think implBind should be re-worked so the local != null case is not
>> handled in the loop body. That will help future maintainers.
>> 
>> src/java.base/windows/classes/sun/nio/ch/UnixDomainSocketsUtil.java
>> - I think we should look at adding JAVA_IO_TMPDIR to StaticProperty.
>> 
>> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
>> - are the AIX specific includes really needed?
>> - can unixSocketAddressToSockaddr use if-then-else to avoid the goto.
>> - bind0 checks if the path is NULL, is this a left over?
>> - the declaration of accept0 is mis-aligned, might be left over from
>> refactoring
>> 
>> src/java.base/unix/native/libnio/ch/InheritedChannel.c
>> - might be clearer if matchFamily is renamed to toInetFamily
>> 
>> src/java.base/unix/classes/sun/nio/ch/InheritedChannel.java
>> - peerAddress0 is replaced by peerAddressInet and peerAddressUnix0 which
>> looks a bit consistent, maybe rename those to inetPeerAddress0 and
>> unixPeerAddress0 ?
>> 
>> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
>> - we've gone through a few iterations on this and only a few minor comments
>> - source/sink can be final and I assume no need to change their type
>> from SourceChannel/SinkChannel
>> - no need to initialize noUnixDomainSockets to false
>> - can the comments at L178-179 be turned into a method description.
>> 
>> Can the tests for java.net.UnixDomainSocketAddress be moved to
>> jdk/test/java/net/UnixSocketAddress?
>> 
>> Could test/jdk/java/nio/file/spi/TestProvider.java be used as
>> alternative provider in the test to avoid DummyPath?
>> 
>> test/jdk/java/nio/channels/etc/ProtocolFamilies.java has been updated to
>> add "expectedFamily", is that used?
>> 
>> test/jdk/java/nio/channels/unixdomain/WindowsDriver.java and
>> NonWindowsDriver.java
>> - are these needed now? Both of them run the same 5 tests and not clear
>> why these tests don't have their own @test tags.
>> 
>> test/jdk/java/nio/channels/unixdomain/Security.java
>> - is there any reason why this test can't run with run
>> main/othervm/java.security.policy=java.policy1 -Djava.security.manager ?
>> 
>> That's all I have from this pass over the changes.
>> 
>> -Alan

So, I have done the refactoring and other work suggested and I think it was worthwhile. We're back to only two impl
classes now (from six). The JFR changes are simplified (at the cost of shoe-horning Unix domain addresses into the Inet
structure) but it's probably beneficial to have only one read and write event type for all sockets. When I went through
the comments below, there was one thing I missed in my reply yesterday. See below:

I will push these changes to the branch shortly.

> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
> [nio-dev](mailto:nio-dev at openjdk.java.net):_
> I went through the latest patch, v18.
> 
> I'm still a bit uncomfortable with splitting up SocketChannelImpl and
> ServerSocketChannelImpl but okay with go along with this for now if we
> can continue explore alternatives. Given that the InetXXX and UnixXXX
> sub-classes aren't too big then one thing that we can try is just
> special casing the protocol family in the 4-5 methods that are
> different. In the mean-time, I think the abstract methods in
> SocketChannelImpl and ServerSocketChannelImpl should have a clear method
> description on what the implXXX method should. I would prefer the other
> methods be changed to final so that it's clear that they cannot be
> overridden. implSocket is new in v17 or v18 and I'd prefer if that were
> abstract so it can be implemented in UnixXXX to throw UOE.
> 
> I think the JFR events need another look. Are UnixSocketReadEvent and
> UnixSocketWriteEvent really needed? SocketXXXEvent "address" is just a
> String so it can be used for any address type, the port can be left as
> 0. Part of this comment is wondering if a parallel set of events are
> really needed. Part of it that I would prefer if the read/write methods
> were final in SocketChannelImpl.
> 
> You might want to take a pass over the files in the patch as several of
> the new files have copyright dates starting 2012, 2019 and other years,
> probably initially copied from other files.
> 
> A few specific comments on v18:
> 
> src/java.base/share/classes/sun/nio/ch/UnixDomainSocketChannelImpl.java
> - supportedOptions doesn't need to wrap the unmodifable collection with
> Collections.unmodifiableSet
> - I think implBind should be re-worked so the local != null case is not
> handled in the loop body. That will help future maintainers.
> 
> src/java.base/windows/classes/sun/nio/ch/UnixDomainSocketsUtil.java
> - I think we should look at adding JAVA_IO_TMPDIR to StaticProperty.
> 
> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
> - are the AIX specific includes really needed?
> - can unixSocketAddressToSockaddr use if-then-else to avoid the goto.
> - bind0 checks if the path is NULL, is this a left over?
> - the declaration of accept0 is mis-aligned, might be left over from
> refactoring
> 
> src/java.base/unix/native/libnio/ch/InheritedChannel.c
> - might be clearer if matchFamily is renamed to toInetFamily
> 
> src/java.base/unix/classes/sun/nio/ch/InheritedChannel.java
> - peerAddress0 is replaced by peerAddressInet and peerAddressUnix0 which
> looks a bit consistent, maybe rename those to inetPeerAddress0 and
> unixPeerAddress0 ?
> 
> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
> - we've gone through a few iterations on this and only a few minor comments
> - source/sink can be final and I assume no need to change their type
> from SourceChannel/SinkChannel

I added a package private method so SinkChannelImpl for accessing the channel. So, sink needs to be a SinkChannelImpl
at least. Also, the fields are not assigned in the constructor. So, don't think they can easily be made final.

> - no need to initialize noUnixDomainSockets to false
> - can the comments at L178-179 be turned into a method description.
> 
> Can the tests for java.net.UnixDomainSocketAddress be moved to
> jdk/test/java/net/UnixSocketAddress?
> 
> Could test/jdk/java/nio/file/spi/TestProvider.java be used as
> alternative provider in the test to avoid DummyPath?
> 
> test/jdk/java/nio/channels/etc/ProtocolFamilies.java has been updated to
> add "expectedFamily", is that used?
> 
> test/jdk/java/nio/channels/unixdomain/WindowsDriver.java and
> NonWindowsDriver.java
> - are these needed now? Both of them run the same 5 tests and not clear
> why these tests don't have their own @test tags.
> 
> test/jdk/java/nio/channels/unixdomain/Security.java
> - is there any reason why this test can't run with run
> main/othervm/java.security.policy=java.policy1 -Djava.security.manager ?
> 
> That's all I have from this pass over the changes.
> 
> -Alan

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

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

From michaelm at openjdk.java.net  Tue Oct 13 18:56:38 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 13 Oct 2020 18:56:38 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v19]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <_sNK1gCg4SBDHE2bDYuPY7e5H5xBlnchuqXo7hTN9x0=.8cdf66b8-6bb6-4e20-b0f4-f4f75bd2a9e8@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
  - removed the new Unix domain socket events and folded the behavior into the existing socket events
  - implemented other comments from Alan on Oct 11.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/cb28f3c0..36a0e30c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=17-18

  Stats: 2700 lines in 64 files changed: 792 ins; 1771 del; 137 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Tue Oct 13 19:09:44 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 13 Oct 2020 19:09:44 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
the last revision:

 - Merge branch 'master' into unixdomainchannels
 - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
   - removed the new Unix domain socket events and folded the behavior into the existing socket events
   - implemented other comments from Alan on Oct 11.
 - unixdomainchannels: updates from Chris's review 9 Oct 2020
 - unixdomainchannels:
   - updated property name
   - added JFR unit test
 - Merge branch 'master' into unixdomainchannels
 - - update after Alan's review on Oct 4
   - includes API change required by JDK-8251952
   - original CSR for the overall change will be resubmitted with
     all api changes consolidated based on this update
 - - simplified Copy.gmk to CAT source files directly
   - renamed net.properties source files to all be net.properties
 - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
 - unixdomainchannels:
   (1) rename UnixDomainHelper to UnixDomainSocketsUtil
   (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
   (3) replace (2) with documented system/networking properties
   (4) Small update to UnixDomainSocketAddress API
   (5) CSR for (3) and (4) submitted at JDK-8253930
   (6) Update build to generate net.properties from shared net.properties.common
       plus platform specific additions.
 - Merge branch 'master' into unixdomainchannels
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/cb9c14cf...7f677d5a

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/36a0e30c..7f677d5a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=18-19

  Stats: 31969 lines in 692 files changed: 18116 ins; 9096 del; 4757 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From dfuchs at openjdk.java.net  Wed Oct 14 12:39:31 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 12:39:31 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
Message-ID: <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>

On Tue, 13 Oct 2020 19:09:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
> the last revision:
>  - Merge branch 'master' into unixdomainchannels
>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>    - implemented other comments from Alan on Oct 11.
>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>  - unixdomainchannels:
>    - updated property name
>    - added JFR unit test
>  - Merge branch 'master' into unixdomainchannels
>  - - update after Alan's review on Oct 4
>    - includes API change required by JDK-8251952
>    - original CSR for the overall change will be resubmitted with
>      all api changes consolidated based on this update
>  - - simplified Copy.gmk to CAT source files directly
>    - renamed net.properties source files to all be net.properties
>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>  - unixdomainchannels:
>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>    (3) replace (2) with documented system/networking properties
>    (4) Small update to UnixDomainSocketAddress API
>    (5) CSR for (3) and (4) submitted at JDK-8253930
>    (6) Update build to generate net.properties from shared net.properties.common
>        plus platform specific additions.
>  - Merge branch 'master' into unixdomainchannels
>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/bc3cab15...7f677d5a

src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java line 63:

> 61:     /** Return the, possibly empty, set of extended socket options available. */
> 62:     public final Set<SocketOption<?>> unixOptions() { return unixOptions; }
> 63:

Could the name of the method - or alternatively its API doc comment - be improved to make it clear that these options
are **Unix Domain protocol** specific option (as opposed to Unix OS specific option). For instance, the field and
method could be named: `unixDomainOptions` instead of `unixOptions`?

src/java.base/share/classes/sun/nio/ch/ServerSocketAdaptor.java line 96:

> 94:     @Override
> 95:     public InetAddress getInetAddress() {
> 96:         InetSocketAddress local = (InetSocketAddress)ssc.localAddress();

Idle wondering as to whether ServerSocketChannelImpl could be parameterized to avoid casts...
`... class ServerSocketChannelImpl<SA extends SocketAddress> extends ...`
Or maybe that would just make things more complex. Have you considered it and rejected it?

src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 99:

> 97:     // Binding
> 98:     private SocketAddress localAddress; // null => unbound
> 99:

See my previous comment about parameterization.

src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 267:

> 265:             HashSet<SocketOption<?>> set = new HashSet<>();
> 266:             set.add(StandardSocketOptions.SO_RCVBUF);
> 267:             return Collections.unmodifiableSet(set);

Wondering: should there be a call to `ExtendedSocketOptions` after line 266 here, even if that call just returns an
empty set?

src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 430:

> 428:
> 429:     protected int implAcceptUnix(FileDescriptor fd, FileDescriptor newfd, SocketAddress[] addrs)
> 430:         throws IOException

Does this method needs to be `protected` ? I couldn't find a place where it was called outside of this file. By
contrast `implAcceptInet` was declared `private` above...

src/java.base/share/classes/sun/nio/ch/SocketAdaptor.java line 110:

> 108:     public InetAddress getInetAddress() {
> 109:         InetSocketAddress remote = (InetSocketAddress)sc.remoteAddress();
> 110:         if (remote == null) {

I guess I'll have the same question about parameterizing `SocketChannelImpl`. Was it considered and rejected?

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 152:

> 150:         this.family = family;
> 151:         this.fdVal = IOUtil.fdVal(fd);
> 152:     }

If you introduced:
private static FileDescriptor socketFor(ProtocolFamily family) throws IOException ...
and
private SocketChannelImpl(SelectorProvider sp, ProtocolFamily family, FileDescriptor fd) throws IOException {
      super(sp);
      this.family = family;
      this.fd = fd;
      this.fdVal = IOUtil.fdVal(fd);
 }
then you could move all the checking to `socketFor(ProtocolFamilly)` and write this constructor as:
SocketChannelImpl(SelectorProvider sp, ProtocolFamily family) throws IOException {
    this(sp, family, sockectFor(family));
}
which would push all the validation to **before** the object gets constructed.

src/java.base/unix/native/libnio/ch/UnixDomainSockets.c line 65:

> 63:         if (namelen != 0) {
> 64:             (*env)->SetByteArrayRegion(env, name, 0, namelen, (jbyte*)sa->sun_path);
> 65:         }

Should the exception status be checked after calling `SetByteArrayRegion`?

src/java.base/unix/native/libnio/ch/UnixDomainSockets.c line 76:

> 74:     sa->sun_family = AF_UNIX;
> 75:     int ret;
> 76:     const char* pname = (const char *)(*env)->GetByteArrayElements(env, path, NULL);

Should `pname == NULL` be checked?

src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 48:

> 46:         if (name != NULL) {
> 47:             (*env)->SetByteArrayRegion(env, name, 0, namelen, (jbyte*)sa->sun_path);
> 48:         }

Same remark here - about exception status

src/java.base/windows/native/libnio/ch/UnixDomainSockets.c line 66:

> 64:     jboolean isCopy;
> 65:     char *pname = (*env)->GetByteArrayElements(env, addr, &isCopy);
> 66:

... and here about checking for `pname == NULL`

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

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

From dfuchs at openjdk.java.net  Wed Oct 14 12:39:15 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 12:39:15 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v18]
In-Reply-To: <bpcXkVMyCZ5PgKeRTbAP2vnf3_cYOsvyO-558Aidf_Y=.3be79c9a-66b6-4f37-8b15-121fb43e9111@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <bpcXkVMyCZ5PgKeRTbAP2vnf3_cYOsvyO-558Aidf_Y=.3be79c9a-66b6-4f37-8b15-121fb43e9111@github.com>
Message-ID: <VgTglpOfA-X1DA63SBhqWslHotf336LpUfh1sFPL_Ng=.faf1125b-cfaf-4d3b-9ed2-4b8a979e999c@github.com>

On Fri, 9 Oct 2020 14:55:25 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unixdomainchannels: updates from Chris's review 9 Oct 2020

Very good work. I have not looked at the tests yet.

src/java.base/share/classes/java/net/UnixDomainSocketAddress.java line 134:

> 132:         if (fs.getClass().getModule() != Object.class.getModule()) {
> 133:             throw new IllegalArgumentException();
> 134:         }

I believe it would be better if this verification was done outside of the constructor (you could do it in the of(Path)
static factory method) - this would avoid creating the object if the path is invalid.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 13:21:27 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 13:21:27 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
Message-ID: <AbVZii-dFK37Ro1lN-SZPjFJ7egAVfbCZLXvtG5iNmk=.11aeaf95-2d29-4867-920b-2bd8fefbd898@github.com>

On Wed, 14 Oct 2020 11:04:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/21a8f700...7f677d5a
>
> src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java line 63:
> 
>> 61:     /** Return the, possibly empty, set of extended socket options available. */
>> 62:     public final Set<SocketOption<?>> unixOptions() { return unixOptions; }
>> 63:
> 
> Could the name of the method - or alternatively its API doc comment - be improved to make it clear that these options
> are **Unix Domain protocol** specific option (as opposed to Unix OS specific option). For instance, the field and
> method could be named: `unixDomainOptions` instead of `unixOptions`?

I think unixDomainOptions would be reasonable and the docs could be updated also to clearly define what each set is.

> src/java.base/share/classes/sun/nio/ch/ServerSocketAdaptor.java line 96:
> 
>> 94:     @Override
>> 95:     public InetAddress getInetAddress() {
>> 96:         InetSocketAddress local = (InetSocketAddress)ssc.localAddress();
> 
> Idle wondering as to whether ServerSocketChannelImpl could be parameterized to avoid casts...
> `... class ServerSocketChannelImpl<SA extends SocketAddress> extends ...`
> Or maybe that would just make things more complex. Have you considered it and rejected it?

Hmm. Not sure how much it would improve clarity, though it would remove some annoying casts. Let me look into it.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 13:21:19 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 13:21:19 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v18]
In-Reply-To: <VgTglpOfA-X1DA63SBhqWslHotf336LpUfh1sFPL_Ng=.faf1125b-cfaf-4d3b-9ed2-4b8a979e999c@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <bpcXkVMyCZ5PgKeRTbAP2vnf3_cYOsvyO-558Aidf_Y=.3be79c9a-66b6-4f37-8b15-121fb43e9111@github.com>
 <VgTglpOfA-X1DA63SBhqWslHotf336LpUfh1sFPL_Ng=.faf1125b-cfaf-4d3b-9ed2-4b8a979e999c@github.com>
Message-ID: <aH30N6JSN5zLDP06KLZjUl0qV1vizzSQztZj2S6k4yo=.3cbed047-d2ed-4b04-9bf2-7126efeec083@github.com>

On Tue, 13 Oct 2020 15:50:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   unixdomainchannels: updates from Chris's review 9 Oct 2020
>
> src/java.base/share/classes/java/net/UnixDomainSocketAddress.java line 134:
> 
>> 132:         if (fs.getClass().getModule() != Object.class.getModule()) {
>> 133:             throw new IllegalArgumentException();
>> 134:         }
> 
> I believe it would be better if this verification was done outside of the constructor (you could do it in the of(Path)
> static factory method) - this would avoid creating the object if the path is invalid.

Good point.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 13:33:25 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 13:33:25 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
Message-ID: <mtbSfA9viWc3RygP2UMkBIWLeOVOI0tQNbS29-1WgcI=.123fa82f-91f2-408d-a041-4fb30a9e0482@github.com>

On Wed, 14 Oct 2020 11:37:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/0017bc71...7f677d5a
>
> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 267:
> 
>> 265:             HashSet<SocketOption<?>> set = new HashSet<>();
>> 266:             set.add(StandardSocketOptions.SO_RCVBUF);
>> 267:             return Collections.unmodifiableSet(set);
> 
> Wondering: should there be a call to `ExtendedSocketOptions` after line 266 here, even if that call just returns an
> empty set?

I suppose for consistency that would make sense, though it would be an empty set for now.

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

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

From dfuchs at openjdk.java.net  Wed Oct 14 15:54:33 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 15:54:33 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
Message-ID: <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>

On Tue, 13 Oct 2020 19:09:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
> the last revision:
>  - Merge branch 'master' into unixdomainchannels
>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>    - implemented other comments from Alan on Oct 11.
>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>  - unixdomainchannels:
>    - updated property name
>    - added JFR unit test
>  - Merge branch 'master' into unixdomainchannels
>  - - update after Alan's review on Oct 4
>    - includes API change required by JDK-8251952
>    - original CSR for the overall change will be resubmitted with
>      all api changes consolidated based on this update
>  - - simplified Copy.gmk to CAT source files directly
>    - renamed net.properties source files to all be net.properties
>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>  - unixdomainchannels:
>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>    (3) replace (2) with documented system/networking properties
>    (4) Small update to UnixDomainSocketAddress API
>    (5) CSR for (3) and (4) submitted at JDK-8253930
>    (6) Update build to generate net.properties from shared net.properties.common
>        plus platform specific additions.
>  - Merge branch 'master' into unixdomainchannels
>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/2d7ca1fc...7f677d5a

test/jdk/java/net/UnixDomainSocketAddress/LengthTest.java line 68:

> 66:                 {new String(new char[100]).replaceAll("\0", "x")},
> 67:                 {new String(new char[namelen]).replaceAll("\0", "x")},
> 68:                 {new String(new char[namelen-1]).replaceAll("\0", "x")},

What's the story with `namelen` ? AFAICS it is always equals to 100? Is it some left over?

test/jdk/java/nio/channels/unixdomain/Bind.java line 175:

> 173:         checkNormal(() -> {
> 174:             client = SocketChannel.open(StandardProtocolFamily.UNIX);
> 175:             client.bind(null);

Should there be a test that also verify that you could call:
client.bind(UNNAMED);
AFAIU that should be equivalent to `client.bind(null)` ?
(same remark for the server side)

test/jdk/java/nio/channels/unixdomain/Bind.java line 245:

> 243:                 client = SocketChannel.open(StandardProtocolFamily.UNIX);
> 244:                 client.bind(cAddr);
> 245:                 client.bind(cAddr);

Should there be a similar test where the first bind call is `client.bind(null)` ?
Same for the server side?

Also maybe there should be a test where the two addresses are different?

test/jdk/java/nio/channels/unixdomain/Bind.java line 178:

> 176:             SocketAddress a = client.getLocalAddress();
> 177:             assertAddress(a, nullAddr, "null address");
> 178:             assertEquals(a, UNNAMED);

If after binding, the client's localAddress  is still unnamed, and if the file is not automatically deleted, then how
do you find out which file to delete when you have finished with the socket? (I mean, in a real world application - not
in this test). Or am I missing something?

test/jdk/java/nio/channels/unixdomain/Security.java line 64:

> 62:             threw = true;
> 63:             if (!(expectedException.isAssignableFrom(t.getClass()))) {
> 64:                 throw new RuntimeException("wrong exception type thrown " + t.toString());

Maybe the wrong exception should be set at the cause to help debugging if the test ever fails here.

test/jdk/java/nio/channels/unixdomain/Security.java line 69:

> 67:         if (expectedException != null && !threw) {
> 68:             // should have thrown
> 69:             throw new RuntimeException("SecurityException was expected");

Well technically the message should say
throw new RuntimeException("%s was expected".formatted(expectedException.getName()));

test/jdk/java/nio/channels/unixdomain/Security.java line 78:

> 76:            SocketChannel.open(UNIX);
> 77:         }
> 78:         catch (UnsupportedOperationException e) {

Any reason for the strange formatting?

test/jdk/java/nio/channels/unixdomain/Security.java line 48:

> 46:
> 47: public class Security {
> 48:

I was expecting to see a test case that verifies that the local address is not revealed if the caller doesn't have the
required permission. Maybe it's already tested elsewhere?

test/jdk/java/nio/channels/unixdomain/Shutdown.java line 3:

> 1: /*
> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Should this be 2020?

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

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

From dfuchs at openjdk.java.net  Wed Oct 14 15:54:33 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 15:54:33 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v17]
In-Reply-To: <EXz8LlJk-TI-j89e-OPtAMSokvBOzo9CElhMWC1_6MY=.b5083ac8-eb0f-411f-b7b5-b1ca8a1fa3a5@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <cHLt3KxXbRfBSo7EX--jOzxQWLj7Afp-1l9tWg7rwMw=.2e9e408d-05c8-4c9d-aaf2-5027ff7e6d81@github.com>
 <bWk_AYECv8BfJyLjLRByYY3DMDX5c9UyCqt8BRfrYkc=.b3f8388a-4b80-40e4-a691-d8ee119a460c@github.com>
 <EXz8LlJk-TI-j89e-OPtAMSokvBOzo9CElhMWC1_6MY=.b5083ac8-eb0f-411f-b7b5-b1ca8a1fa3a5@github.com>
Message-ID: <skpyN0oO6-No9zjUM6GJxZxQouKmVtaP8oE9mu5hgN8=.0e1eca1f-c502-4e9e-a93a-2ef03cf8b312@github.com>

On Fri, 9 Oct 2020 14:36:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> test/jdk/java/nio/channels/unixdomain/IOExchanges.java line 113:
>> 
>>> 111:         SPINBAccep_NBConn_NBIO_WR_11a
>>> 112:         SPINBAccep_NBConn_NBIO_RW_12a
>>> 113:     */
>> 
>> I recognise this test ;-)  I thought there was a version for IP-specific channels, but cannot find it now. I was going
>> to ask if these could be merged or abstracted out somehow.
>
> Chris,
> Thanks for the comments. I will incorporate them all into the next revision. As regards the IOExchanges test, it uses a
> @DataProvider of ProtocolFamily with values "UNIX" and "INET" which means the tests are run for TCP sockets. Is that
> what you were asking? I'm not sure I get the question exactly. Michael.

Should it also have INET6 in the case where IPv6 is supported on the machine?

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

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

From michaelm at openjdk.java.net  Wed Oct 14 16:23:21 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 16:23:21 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
Message-ID: <6CkdkcBl6OkvDVBOy0YLM2CH6qV4S2UZgzUIPtg31TA=.c05b30c5-0c8e-4ec4-8033-0d21392e44ce@github.com>

On Wed, 14 Oct 2020 11:19:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/a9828a5a...7f677d5a
>
> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 99:
> 
>> 97:     // Binding
>> 98:     private SocketAddress localAddress; // null => unbound
>> 99:
> 
> See my previous comment about parameterization.

I think this change (parameterizing the SocketChannelImpl and Server) would be too disruptive for the benefit it
provides.

> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 152:
> 
>> 150:         this.family = family;
>> 151:         this.fdVal = IOUtil.fdVal(fd);
>> 152:     }
> 
> If you introduced:
> private static FileDescriptor socketFor(ProtocolFamily family) throws IOException ...
> and
> private SocketChannelImpl(SelectorProvider sp, ProtocolFamily family, FileDescriptor fd) throws IOException {
>       super(sp);
>       this.family = family;
>       this.fd = fd;
>       this.fdVal = IOUtil.fdVal(fd);
>  }
> then you could move all the checking to `socketFor(ProtocolFamilly)` and write this constructor as:
> SocketChannelImpl(SelectorProvider sp, ProtocolFamily family) throws IOException {
>     this(sp, family, sockectFor(family));
> }
> which would push all the validation to **before** the object gets constructed.

Good idea.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 16:23:14 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 16:23:14 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <AbVZii-dFK37Ro1lN-SZPjFJ7egAVfbCZLXvtG5iNmk=.11aeaf95-2d29-4867-920b-2bd8fefbd898@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
 <AbVZii-dFK37Ro1lN-SZPjFJ7egAVfbCZLXvtG5iNmk=.11aeaf95-2d29-4867-920b-2bd8fefbd898@github.com>
Message-ID: <AI5E22UCIn4-gY9YT_u-5ju9K7aBlQbuTyJstuSt8_A=.f96fe2f4-1303-4efd-b3c8-b78c830edcdb@github.com>

On Wed, 14 Oct 2020 13:17:01 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java line 63:
>> 
>>> 61:     /** Return the, possibly empty, set of extended socket options available. */
>>> 62:     public final Set<SocketOption<?>> unixOptions() { return unixOptions; }
>>> 63:
>> 
>> Could the name of the method - or alternatively its API doc comment - be improved to make it clear that these options
>> are **Unix Domain protocol** specific option (as opposed to Unix OS specific option). For instance, the field and
>> method could be named: `unixDomainOptions` instead of `unixOptions`?
>
> I think unixDomainOptions would be reasonable and the docs could be updated also to clearly define what each set is.

I changed it to unixDomainClientOptions to distinguish from server channel options, which there are none anyway.

>> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 267:
>> 
>>> 265:             HashSet<SocketOption<?>> set = new HashSet<>();
>>> 266:             set.add(StandardSocketOptions.SO_RCVBUF);
>>> 267:             return Collections.unmodifiableSet(set);
>> 
>> Wondering: should there be a call to `ExtendedSocketOptions` after line 266 here, even if that call just returns an
>> empty set?
>
> I suppose for consistency that would make sense, though it would be an empty set for now.

Actually, related to the last comment I just decided to make it clear the extended options are only for the client side
and it doesn't make sense to add all this code for a set of possible options that will be empty.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 16:29:27 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 16:29:27 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
Message-ID: <cdgRuy4ja3M-vmWk8YXjLFaNQAg2FzM4hVFOD0MKBZg=.f489b689-b55c-4425-acc8-5fdaae0b5c4e@github.com>

On Wed, 14 Oct 2020 12:24:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/def74ac0...7f677d5a
>
> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c line 65:
> 
>> 63:         if (namelen != 0) {
>> 64:             (*env)->SetByteArrayRegion(env, name, 0, namelen, (jbyte*)sa->sun_path);
>> 65:         }
> 
> Should the exception status be checked after calling `SetByteArrayRegion`?

I notice a lot of other code is not fussy about checking this, but it would look safer to check and return NULL in this
case.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 16:32:31 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 16:32:31 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <Gq0f9GPSAmrePe2JtGxexkVJQsQGvEmU9SqInrVHuTA=.681538d8-f18f-4df1-a827-8d5ce9920ded@github.com>
Message-ID: <DKUfu8JYvXJpWq4oAuG7PdQsKF9Z5NMW-oJAkRIdzZg=.5ce136a8-87d2-46db-aefa-985070e031da@github.com>

On Wed, 14 Oct 2020 12:28:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/1e93b2d3...7f677d5a
>
> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c line 76:
> 
>> 74:     sa->sun_family = AF_UNIX;
>> 75:     int ret;
>> 76:     const char* pname = (const char *)(*env)->GetByteArrayElements(env, path, NULL);
> 
> Should `pname == NULL` be checked?

A UnixDomainSocketAddress should always always have a path associated and therefore a byte array should always be
present, but again I think this is no harm for overall robustness.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 17:04:44 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 17:04:44 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v21]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <emzkBRQCCpbGOQzQ_XJ98rarMkggKl8pmkLpkaGLDng=.6258932a-389e-47b3-9729-eb53d8ad764c@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  src changes from Daniel's review. Tests will come later

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/7f677d5a..4bbbde32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=19-20

  Stats: 69 lines in 6 files changed: 41 ins; 13 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Wed Oct 14 17:04:53 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 17:04:53 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>
Message-ID: <byPJvNXgEgHzf9bM5JW0S8hM63ItI5hJluk8nupCo6c=.0c18ff83-1f58-44ab-8eff-7d95b3de8b81@github.com>

On Wed, 14 Oct 2020 13:56:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/fe5bf7d9...7f677d5a
>
> test/jdk/java/net/UnixDomainSocketAddress/LengthTest.java line 68:
> 
>> 66:                 {new String(new char[100]).replaceAll("\0", "x")},
>> 67:                 {new String(new char[namelen]).replaceAll("\0", "x")},
>> 68:                 {new String(new char[namelen-1]).replaceAll("\0", "x")},
> 
> What's the story with `namelen` ? AFAICS it is always equals to 100? Is it some left over?

No, it is testing a name length that is close to the maximum value. At one point I had a system property that indicates
the actual maximum length on a platform, but that was removed.

> test/jdk/java/nio/channels/unixdomain/Bind.java line 175:
> 
>> 173:         checkNormal(() -> {
>> 174:             client = SocketChannel.open(StandardProtocolFamily.UNIX);
>> 175:             client.bind(null);
> 
> Should there be a test that also verify that you could call:
> client.bind(UNNAMED);
> AFAIU that should be equivalent to `client.bind(null)` ?
> (same remark for the server side)

That would be true for the client side, and I'll add a test for it. But it is not allowed to bind explicitly to the
unnamed address on the server side. It doesn't make sense because an unnamed address means no socket file on the file
system.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 17:38:18 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 17:38:18 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>
Message-ID: <zIYjooZ_vxNvtaCDIOA8kvr2xQqRlH56v1JvgfOjS00=.e232ed49-5dd3-49b5-8863-34b103ce6da4@github.com>

On Wed, 14 Oct 2020 14:14:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/c064114d...7f677d5a
>
> test/jdk/java/nio/channels/unixdomain/Bind.java line 245:
> 
>> 243:                 client = SocketChannel.open(StandardProtocolFamily.UNIX);
>> 244:                 client.bind(cAddr);
>> 245:                 client.bind(cAddr);
> 
> Should there be a similar test where the first bind call is `client.bind(null)` ?
> Same for the server side?
> 
> Also maybe there should be a test where the two addresses are different?

so, testing multiple binds of the same socket, but using different addresses, which should also fail? I can add that no
problem.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 17:46:26 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 17:46:26 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v20]
In-Reply-To: <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <RFSCKoHzd5ssqlbL3sfdc3VZ_tiLCQ0EkAhWBVKYcsU=.c240886a-764d-4b34-9fb8-97d5e7c983b7@github.com>
 <tY8K4cs3ucQGqiPfEI50HsP2frKvPuT4WO1uggA4LPM=.fe8e2790-2a71-4231-9d77-d8eb2f432e3c@github.com>
Message-ID: <jkvXYQpVHV5uL9edooWjTd08GaHQvoNPQ690MNc7x_Q=.c4a6924a-a04f-4307-a38b-4ef120e9aa0f@github.com>

On Wed, 14 Oct 2020 14:21:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since
>> the last revision:
>>  - Merge branch 'master' into unixdomainchannels
>>  - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
>>    - removed the new Unix domain socket events and folded the behavior into the existing socket events
>>    - implemented other comments from Alan on Oct 11.
>>  - unixdomainchannels: updates from Chris's review 9 Oct 2020
>>  - unixdomainchannels:
>>    - updated property name
>>    - added JFR unit test
>>  - Merge branch 'master' into unixdomainchannels
>>  - - update after Alan's review on Oct 4
>>    - includes API change required by JDK-8251952
>>    - original CSR for the overall change will be resubmitted with
>>      all api changes consolidated based on this update
>>  - - simplified Copy.gmk to CAT source files directly
>>    - renamed net.properties source files to all be net.properties
>>  - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>>  - unixdomainchannels:
>>    (1) rename UnixDomainHelper to UnixDomainSocketsUtil
>>    (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
>>    (3) replace (2) with documented system/networking properties
>>    (4) Small update to UnixDomainSocketAddress API
>>    (5) CSR for (3) and (4) submitted at JDK-8253930
>>    (6) Update build to generate net.properties from shared net.properties.common
>>        plus platform specific additions.
>>  - Merge branch 'master' into unixdomainchannels
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/918de17d...7f677d5a
>
> test/jdk/java/nio/channels/unixdomain/Bind.java line 178:
> 
>> 176:             SocketAddress a = client.getLocalAddress();
>> 177:             assertAddress(a, nullAddr, "null address");
>> 178:             assertEquals(a, UNNAMED);
> 
> If after binding, the client's localAddress  is still unnamed, and if the file is not automatically deleted, then how
> do you find out which file to delete when you have finished with the socket? (I mean, in a real world application - not
> in this test). Or am I missing something?

The apiNote in SocketChannel.bind specifies that binding to an unnamed address does not create any socket file on the
filesystem. I'd expect this to be normal behavior for clients, precisely so they dont have to worry about cleaning up
the socket files after them.

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

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

From michaelm at openjdk.java.net  Wed Oct 14 18:23:31 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 18:23:31 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v22]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <HpRqmfZFtYjpXAmFwPks1eIUBtymnbx8qc9CnZO449Y=.3aa09f0c-8eb8-4813-9be9-b09c0139d270@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - test updates from Daniel's review 14 Oct 2020

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/4bbbde32..3859e611

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=20-21

  Stats: 85 lines in 5 files changed: 75 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Wed Oct 14 18:27:32 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 14 Oct 2020 18:27:32 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v23]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <xKk4gNfTYfUVK1oUZo8VP1nVBI9DVWDpWyC6X_o-VAI=.dc45042e-fe02-4dde-81ce-84c2a7af282d@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  fix white space error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/3859e611..8a545a7c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=21-22

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

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

From dfuchs at openjdk.java.net  Wed Oct 14 18:41:30 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 18:41:30 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v23]
In-Reply-To: <xKk4gNfTYfUVK1oUZo8VP1nVBI9DVWDpWyC6X_o-VAI=.dc45042e-fe02-4dde-81ce-84c2a7af282d@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <xKk4gNfTYfUVK1oUZo8VP1nVBI9DVWDpWyC6X_o-VAI=.dc45042e-fe02-4dde-81ce-84c2a7af282d@github.com>
Message-ID: <jN18bz9IFIjqeD1a4LhwU46utTQrEd9eWMIgmNyxHg4=.4e19de31-e4bf-401d-89c3-8820cf743e10@github.com>

On Wed, 14 Oct 2020 18:27:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix white space error

Marked as reviewed by dfuchs (Reviewer).

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 717:

> 715:             UnixDomainSockets.bind(fd, path);
> 716:         }
> 717:         if (usa == null || path.toString().equals("")) {

Maybe you could replace `path.toString().length() > 0` with `!path.toString().isEmpty()` and
`path.toString().equals("")` with `path.toString().isEmpty()`.

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

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

From michaelm at openjdk.java.net  Thu Oct 15 08:01:27 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 15 Oct 2020 08:01:27 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v24]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <T0BoHGl0Zzs9hRUy06xfsylrHOjyjNbfOM2D27OHmLI=.808ccd56-62e4-47bc-b497-a5a74de615f2@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - use String.isEmpty where appropriate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/8a545a7c..15dc94b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=22-23

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

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

From michaelm at openjdk.java.net  Thu Oct 15 08:01:28 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 15 Oct 2020 08:01:28 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v23]
In-Reply-To: <jN18bz9IFIjqeD1a4LhwU46utTQrEd9eWMIgmNyxHg4=.4e19de31-e4bf-401d-89c3-8820cf743e10@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <xKk4gNfTYfUVK1oUZo8VP1nVBI9DVWDpWyC6X_o-VAI=.dc45042e-fe02-4dde-81ce-84c2a7af282d@github.com>
 <jN18bz9IFIjqeD1a4LhwU46utTQrEd9eWMIgmNyxHg4=.4e19de31-e4bf-401d-89c3-8820cf743e10@github.com>
Message-ID: <Lz123nVVg8qYZAKTR_JYJPydVrWVL97eHbYN8cV-SDk=.9a678889-498a-4d45-b993-e14e35a4f52e@github.com>

On Wed, 14 Oct 2020 18:37:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix white space error
>
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 717:
> 
>> 715:             UnixDomainSockets.bind(fd, path);
>> 716:         }
>> 717:         if (usa == null || path.toString().equals("")) {
> 
> Maybe you could replace `path.toString().length() > 0` with `!path.toString().isEmpty()` and
> `path.toString().equals("")` with `path.toString().isEmpty()`.

Done

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

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

From dfuchs at openjdk.java.net  Thu Oct 15 08:45:15 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 15 Oct 2020 08:45:15 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v24]
In-Reply-To: <T0BoHGl0Zzs9hRUy06xfsylrHOjyjNbfOM2D27OHmLI=.808ccd56-62e4-47bc-b497-a5a74de615f2@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <T0BoHGl0Zzs9hRUy06xfsylrHOjyjNbfOM2D27OHmLI=.808ccd56-62e4-47bc-b497-a5a74de615f2@github.com>
Message-ID: <5FYFJCth6vooDwE9TMf4Bn3S0aTyFSbdTeIwvZouMAI=.e2516042-7bcc-469f-a421-ccaeac41a281@github.com>

On Thu, 15 Oct 2020 08:01:27 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - use String.isEmpty where appropriate

Marked as reviewed by dfuchs (Reviewer).

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

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

From candrews at integralblue.com  Thu Oct 15 16:22:30 2020
From: candrews at integralblue.com (Craig Andrews)
Date: Thu, 15 Oct 2020 12:22:30 -0400
Subject: Request: mechanism for making HttpRequest.Builder from HttpRequest
Message-ID: <6f1d1d235013be262404e8a500eeaace@integralblue.com>

Java's HttpClient relies on the builder pattern to produce immutable 
objects on which actual operations are done. However, it currently lacks 
a way to convert those working objects back to builders in order to 
mutate them.

For example, I'd like to take a java.net.http.HttpRequest and change it; 
for example, I'd like to add a header.  The first approach that came to 
my mind was to make the HttpRequest into a HttpRequest.Builder, add the 
header, then build the builder, like this:

	HttpRequest addHeader(final HttpRequest request, String name, String 
value) {
		return request.toBuilder().header(name, value).build();
	}

However, there is no HttpRequest.toBuilder() method.

As a workaround, I wrote a "httpRequestToBuilder" method:

	HttpRequest.Builder httpRequestToBuilder(final HttpRequest request) {
		final HttpRequest.Builder builder = HttpRequest.newBuilder();
		builder.expectContinue(request.expectContinue());
		request.headers().map().forEach((name, values) -> values.forEach(value 
-> builder.header(name, value)));
		builder.method(request.method(), 
request.bodyPublisher().orElseGet(BodyPublishers::noBody));
		request.timeout().ifPresent(builder::timeout);
		builder.uri(request.uri());
		request.version().ifPresent(builder::version);
		return builder;
	}

I think we can all agree that it's best for people to not have to write, 
test, and maintain such functions, especially as Java's HttpClient 
evolves in the future.

Will this group entertain the suggestion to add a toBuilder() method 
HttpRequest, or equivalent functionality?

I believe such a toBuilder() method would be helpful on 
java.net.http.HttpClient as well.

Thank you,
~Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201015/343a7aab/signature.asc>

From chris.hegarty at oracle.com  Thu Oct 15 16:36:51 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Oct 2020 17:36:51 +0100
Subject: Request: mechanism for making HttpRequest.Builder from HttpRequest
In-Reply-To: <6f1d1d235013be262404e8a500eeaace@integralblue.com>
References: <6f1d1d235013be262404e8a500eeaace@integralblue.com>
Message-ID: <69960BEF-318C-430C-B8A6-5878A64801DE@oracle.com>

Hi Craig,

> On 15 Oct 2020, at 17:22, Craig Andrews <candrews at integralblue.com> wrote:
> 
> Java's HttpClient relies on the builder pattern to produce immutable objects on which actual operations are done. However, it currently lacks a way to convert those working objects back to builders in order to mutate them.

I agree that such an API point would be useful. I filed an issue and proposed API sketch a while back. I have strong hope that it will make it to a Java release real soon.

https://bugs.openjdk.java.net/browse/JDK-8252304 - "Seed an HttpRequest.Builder from an existing HttpRequest?.

-Chris.

From michaelm at openjdk.java.net  Fri Oct 16 14:34:32 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 16 Oct 2020 14:34:32 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v25]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <lImjWfaPKoBbkjs7Ucaw3R6We3ymQ-T6LlhG8J42FxI=.a9df4361-e41e-488c-aa1f-a9e1874cb36c@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - added NullTest and fix in SocketChannel.open
  - updated test bug ids

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/15dc94b2..2d595423

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=23-24

  Stats: 63 lines in 8 files changed: 57 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From dfuchs at openjdk.java.net  Fri Oct 16 16:37:15 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 16 Oct 2020 16:37:15 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v25]
In-Reply-To: <lImjWfaPKoBbkjs7Ucaw3R6We3ymQ-T6LlhG8J42FxI=.a9df4361-e41e-488c-aa1f-a9e1874cb36c@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <lImjWfaPKoBbkjs7Ucaw3R6We3ymQ-T6LlhG8J42FxI=.a9df4361-e41e-488c-aa1f-a9e1874cb36c@github.com>
Message-ID: <Z5cnmN-JqIIGCu2qc9T8UaTJjqVpuGSh_X6IQMI5zTA=.075d5dfb-7ffb-40e2-b365-1b21179ea56d@github.com>

On Fri, 16 Oct 2020 14:34:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - added NullTest and fix in SocketChannel.open
>   - updated test bug ids

Marked as reviewed by dfuchs (Reviewer).

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

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

From pconcannon at openjdk.java.net  Sun Oct 18 17:06:26 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Sun, 18 Oct 2020 17:06:26 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v2]
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <rfx8xvq_78zx3QqksOpGgbYIuXgI6j411SQF-VPAjZQ=.06d81e04-cca0-479c-b7e9-41b064c9fde0@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 two additional commits
since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/610/files
  - new: https://git.openjdk.java.net/jdk/pull/610/files/df06f8cf..7878b878

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

  Stats: 303208 lines in 620 files changed: 296762 ins; 3969 del; 2477 mod
  Patch: https://git.openjdk.java.net/jdk/pull/610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/610/head:pull/610

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

From pconcannon at openjdk.java.net  Sun Oct 18 18:10:23 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Sun, 18 Oct 2020 18:10:23 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v3]
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <HMBJAnkdY7WfUzr_pBh7WI-C0pPBntjNPxiTSbh6R3Y=.a6eeb6b0-96d0-462b-ad20-6382ab7a1fcd@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/610/files
  - new: https://git.openjdk.java.net/jdk/pull/610/files/7878b878..ef5b9fa7

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

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

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

From pconcannon at openjdk.java.net  Sun Oct 18 18:10:26 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Sun, 18 Oct 2020 18:10:26 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v3]
In-Reply-To: <u46_TLScNFJZSOsyabac2AugF1gv3zGnkRqYjlfdO-w=.fa0717a0-2566-404e-9f74-51e033f049a1@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <u46_TLScNFJZSOsyabac2AugF1gv3zGnkRqYjlfdO-w=.fa0717a0-2566-404e-9f74-51e033f049a1@github.com>
Message-ID: <OJg47FAf4og3bSX-tFtfKx-fXQRzmZ0dznyXNv1-dek=.b8503a7a-0ace-46cf-aa98-86adb21ee06c@github.com>

On Mon, 12 Oct 2020 19:09:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 48:
> 
>> 46:
>> 47:     /**
>> 48:      */
> 
> If you're going to write a CSR, then you could as well provide the "Constructor for subclasses to call." comment...

Comment added. It can be viewed in commit:
https://github.com/openjdk/jdk/pull/610/commits/ef5b9fa75886007484f15d74ddf2529f4054ee66

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 81:
> 
>> 79:      *             the address
>> 80:      * @param backlog the socket backlog. If this value is less than or equal to
>> 81:      *               zero, then a system default value is used
> 
> There is more than one sentence here, and the second sentence is a full sentence so I believe you'll need a full-stop
> at the end.

Punctuation added. You can view the change in commit:
https://github.com/openjdk/jdk/pull/610/commits/ef5b9fa75886007484f15d74ddf2529f4054ee66

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsExchange.java line 43:
> 
>> 41:      * Constructor for subclasses to call.
>> 42:      */
>> 43:     protected HttpsExchange() {}
> 
> Ah. I guess this trivial change will require a CSR...

I've created a CSR to track these changes as suggested. You can view it here:
https://bugs.openjdk.java.net/browse/JDK-8254968

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 60:
> 
>> 58:      * {@link #setHttpsConfigurator(HttpsConfigurator)}.
>> 59:      *
>> 60:      * @throws IOException if an I/O error occurs
> 
> Third change that will need to be listed in the CSR (filling out the @throws comment)

Change has been noted in CSR (https://bugs.openjdk.java.net/browse/JDK-8254968)

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 84:
> 
>> 82:      * @throws BindException if the server cannot bind to the requested address,
>> 83:      *          or if the server is already bound
>> 84:      * @throws IOException if an I/O error occurs
> 
> This one needs to be listed in the CSR too.

Change noted in CSR (https://bugs.openjdk.java.net/browse/JDK-8254968)

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

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

From michaelm at openjdk.java.net  Mon Oct 19 10:27:28 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 10:27:28 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v26]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <LQYlsNeJt1Idl4x1YnsSSi9yR4Bv9emYHI1PrzqZ_Kc=.72ee5aed-e6d1-4caf-9e66-4500053f6e9a@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - Alan's review patch from Oct 18
  - Reverted changes to JFR unit tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/2d595423..d0ae1348

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=24-25

  Stats: 764 lines in 21 files changed: 203 ins; 344 del; 217 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Mon Oct 19 12:31:57 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 12:31:57 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v27]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <WNFkBC8yMImGYzYx5Qx465P4MRqP7B9FV3c0_Lra_bg=.fd47552e-bdc3-4a16-b460-a501a1d3100d@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since
the last revision:

 - Merge branch 'master' into unixdomainchannels
 - - Alan's review patch from Oct 18
   - Reverted changes to JFR unit tests
 - - added NullTest and fix in SocketChannel.open
   - updated test bug ids
 - - use String.isEmpty where appropriate
 - fix white space error
 - - test updates from Daniel's review 14 Oct 2020
 - src changes from Daniel's review. Tests will come later
 - Merge branch 'master' into unixdomainchannels
 - - reorganised the channel impls back into SocketChannelImpl and ServerSocketChannelImpl
   - removed the new Unix domain socket events and folded the behavior into the existing socket events
   - implemented other comments from Alan on Oct 11.
 - unixdomainchannels: updates from Chris's review 9 Oct 2020
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/8d61d09d...eca95d86

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/d0ae1348..eca95d86

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=25-26

  Stats: 301287 lines in 667 files changed: 296118 ins; 3174 del; 1995 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From pconcannon at openjdk.java.net  Mon Oct 19 15:33:25 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 19 Oct 2020 15:33:25 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v4]
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <IhsJH4QFm0AOj_6xBM0kj6uYwqjSyObDwWGM-ukM12Y=.01fd7067-8639-4b87-99c0-3087938cdeb2@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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-8253474
 - 8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/610/files
  - new: https://git.openjdk.java.net/jdk/pull/610/files/ef5b9fa7..e02bb1ae

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

  Stats: 2169 lines in 170 files changed: 965 ins; 898 del; 306 mod
  Patch: https://git.openjdk.java.net/jdk/pull/610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/610/head:pull/610

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

From dfuchs at openjdk.java.net  Mon Oct 19 15:51:27 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 19 Oct 2020 15:51:27 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v4]
In-Reply-To: <IhsJH4QFm0AOj_6xBM0kj6uYwqjSyObDwWGM-ukM12Y=.01fd7067-8639-4b87-99c0-3087938cdeb2@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <IhsJH4QFm0AOj_6xBM0kj6uYwqjSyObDwWGM-ukM12Y=.01fd7067-8639-4b87-99c0-3087938cdeb2@github.com>
Message-ID: <Dwz5eVrxcyEuk3SvQClqOnKnFfTiLGaX7fA1hz_fJh8=.ba86d96e-6014-4a0a-9af0-284f3aa785d9@github.com>

On Mon, 19 Oct 2020 15:33:25 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
>> HttpsServer' ?
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpsExchange`
>> `com.sun.net.httpserver.HttpsParameters`
>> `com.sun.net.httpserver.HttpsServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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-8253474
>  - 8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
>  - Merge remote-tracking branch 'origin/master' into JDK-8253474
>  - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

Marked as reviewed by dfuchs (Reviewer).

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

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

From michaelm at openjdk.java.net  Mon Oct 19 15:59:18 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 15:59:18 GMT
Subject: RFR: 8254967: com.sun.net.HttpsServer spins on TLS session close
Message-ID: <mtJHhMfgbfrfdXMilEA481Eegi67jULOxBM8c8ZUf7E=.e1ac2c7d-bd1c-46a8-8a62-5837534b1637@github.com>

This fixes a busy loop bug in the Http server which happens sometimes when an SSL connection is closed by the client.

There is no regression test as it is not easy to reproduce and the only effect is that one executor thread gets tied up.

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

Commit messages:
 - 8254967: com.sun.net.HttpsServer spins on TLS session close

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

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

From michaelm at openjdk.java.net  Mon Oct 19 16:02:20 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 16:02:20 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v4]
In-Reply-To: <IhsJH4QFm0AOj_6xBM0kj6uYwqjSyObDwWGM-ukM12Y=.01fd7067-8639-4b87-99c0-3087938cdeb2@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <IhsJH4QFm0AOj_6xBM0kj6uYwqjSyObDwWGM-ukM12Y=.01fd7067-8639-4b87-99c0-3087938cdeb2@github.com>
Message-ID: <BLAvyPtbp63tm9_s58m5urLuA5Tr3Hb3uapRQPsilBE=.e4a00e73-7b91-411a-9cc1-4743a11442ab@github.com>

On Mon, 19 Oct 2020 15:33:25 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
>> HttpsServer' ?
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpsExchange`
>> `com.sun.net.httpserver.HttpsParameters`
>> `com.sun.net.httpserver.HttpsServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> 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-8253474
>  - 8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
>  - Merge remote-tracking branch 'origin/master' into JDK-8253474
>  - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsParameters.java line 39:

> 37:  * {@link HttpsConfigurator#configure(HttpsParameters)} for every incoming https
> 38:  * connection,in order to determine the parameters to use.
> 39:  *

looks like a space is missing between "connection,in"

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsParameters.java line 33:

> 31: import javax.net.ssl.SSLParameters;
> 32: //END_TIGER_EXCLUDE
> 33:

These TIGER EXCLUDE comments could be removed at this stage.

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

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

From dfuchs at openjdk.java.net  Mon Oct 19 16:32:16 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 19 Oct 2020 16:32:16 GMT
Subject: RFR: 8254967: com.sun.net.HttpsServer spins on TLS session close
In-Reply-To: <mtJHhMfgbfrfdXMilEA481Eegi67jULOxBM8c8ZUf7E=.e1ac2c7d-bd1c-46a8-8a62-5837534b1637@github.com>
References: <mtJHhMfgbfrfdXMilEA481Eegi67jULOxBM8c8ZUf7E=.e1ac2c7d-bd1c-46a8-8a62-5837534b1637@github.com>
Message-ID: <y9_-ibWbm3pHsn6S1kDmVedO0i4X-WYC-pPEhow3I5k=.c056094d-a6bc-498d-904d-46ccad7846ab@github.com>

On Mon, 19 Oct 2020 15:50:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> This fixes a busy loop bug in the Http server which happens sometimes when an SSL connection is closed by the client.
> 
> There is no regression test as it is not easy to reproduce and the only effect is that one executor thread gets tied up.

Marked as reviewed by dfuchs (Reviewer).

src/jdk.httpserver/share/classes/sun/net/httpserver/SSLStreams.java line 445:

> 443:         } finally {
> 444:             handshaking.unlock();
> 445:         }

Ok. The expectation is that doClosure() only involves sending a close acknowedged and not receiving anything. This is
probably correct if doClosure() is called on reception of close_notify. In which case the change looks reasonable. I
also see that a further expectation is that cycles of NEED_WRAP/NEED_UNWRAP only happen during the handshake, which is
hopefully true.

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

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

From michaelm at openjdk.java.net  Mon Oct 19 17:02:10 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 17:02:10 GMT
Subject: Integrated: 8254967: com.sun.net.HttpsServer spins on TLS session
 close
In-Reply-To: <mtJHhMfgbfrfdXMilEA481Eegi67jULOxBM8c8ZUf7E=.e1ac2c7d-bd1c-46a8-8a62-5837534b1637@github.com>
References: <mtJHhMfgbfrfdXMilEA481Eegi67jULOxBM8c8ZUf7E=.e1ac2c7d-bd1c-46a8-8a62-5837534b1637@github.com>
Message-ID: <e2NU52zHbM-BnZyZcbKtCgIHG-_9ibdlV-SVFTMr7Sw=.8be6db93-3e53-4779-935b-11ffa9e9652a@github.com>

On Mon, 19 Oct 2020 15:50:32 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> This fixes a busy loop bug in the Http server which happens sometimes when an SSL connection is closed by the client.
> 
> There is no regression test as it is not easy to reproduce and the only effect is that one executor thread gets tied up.

This pull request has now been integrated.

Changeset: 953e472d
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/953e472d
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8254967: com.sun.net.HttpsServer spins on TLS session close

Reviewed-by: dfuchs

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

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

From pconcannon at openjdk.java.net  Mon Oct 19 17:33:30 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 19 Oct 2020 17:33:30 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v5]
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <LButyueFRd4LgOcEpsXxdS8uHhq9sVDniVwLFpV5P-E=.d5a31d6e-22a8-4bb2-ad8d-b6eae75c04a4@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 five additional commits
since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/610/files
  - new: https://git.openjdk.java.net/jdk/pull/610/files/e02bb1ae..94689aee

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

  Stats: 1048 lines in 125 files changed: 698 ins; 99 del; 251 mod
  Patch: https://git.openjdk.java.net/jdk/pull/610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/610/head:pull/610

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

From pconcannon at openjdk.java.net  Mon Oct 19 17:36:25 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 19 Oct 2020 17:36:25 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v6]
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <MUblS1S6mjXT7UkKbeQYL4nMe2OTioQzTK-37hlscIc=.006aaa33-969c-4c46-991f-bc0d84aae128@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8253474: Fixed typo; removed TIGER macro/comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/610/files
  - new: https://git.openjdk.java.net/jdk/pull/610/files/94689aee..45f45182

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=610&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=610&range=04-05

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

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

From pconcannon at openjdk.java.net  Mon Oct 19 17:36:28 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 19 Oct 2020 17:36:28 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v4]
In-Reply-To: <BLAvyPtbp63tm9_s58m5urLuA5Tr3Hb3uapRQPsilBE=.e4a00e73-7b91-411a-9cc1-4743a11442ab@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <IhsJH4QFm0AOj_6xBM0kj6uYwqjSyObDwWGM-ukM12Y=.01fd7067-8639-4b87-99c0-3087938cdeb2@github.com>
 <BLAvyPtbp63tm9_s58m5urLuA5Tr3Hb3uapRQPsilBE=.e4a00e73-7b91-411a-9cc1-4743a11442ab@github.com>
Message-ID: <A7tIF9gp0eIUB2Yj5IbXO9Oj57dBLN6ppbBdmOldJ98=.c220482c-8d78-429f-b4ec-1870e0f798c7@github.com>

On Mon, 19 Oct 2020 15:58:04 GMT, Michael McMahon <michaelm 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 four additional commits
>> since the last revision:
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253474
>>  - 8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
>>  - Merge remote-tracking branch 'origin/master' into JDK-8253474
>>  - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsParameters.java line 33:
> 
>> 31: import javax.net.ssl.SSLParameters;
>> 32: //END_TIGER_EXCLUDE
>> 33:
> 
> These TIGER EXCLUDE comments could be removed at this stage.

TIGER comments removed in commit
https://github.com/openjdk/jdk/pull/610/commits/45f451829c30339a10f03377a78b17b7291be82f

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsParameters.java line 39:
> 
>> 37:  * {@link HttpsConfigurator#configure(HttpsParameters)} for every incoming https
>> 38:  * connection,in order to determine the parameters to use.
>> 39:  *
> 
> looks like a space is missing between "connection,in"

Typo fixed in https://github.com/openjdk/jdk/pull/610/commits/45f451829c30339a10f03377a78b17b7291be82f

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

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

From dfuchs at openjdk.java.net  Mon Oct 19 17:45:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 19 Oct 2020 17:45:12 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v6]
In-Reply-To: <MUblS1S6mjXT7UkKbeQYL4nMe2OTioQzTK-37hlscIc=.006aaa33-969c-4c46-991f-bc0d84aae128@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <MUblS1S6mjXT7UkKbeQYL4nMe2OTioQzTK-37hlscIc=.006aaa33-969c-4c46-991f-bc0d84aae128@github.com>
Message-ID: <AwFvauqo_KU8E-iPqX4K8jp1ZdK56vyWr_8hJpEm4N4=.c7c0e60e-2635-40d1-a445-f0e1ec8a6479@github.com>

On Mon, 19 Oct 2020 17:36:25 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
>> HttpsServer' ?
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpsExchange`
>> `com.sun.net.httpserver.HttpsParameters`
>> `com.sun.net.httpserver.HttpsServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253474: Fixed typo; removed TIGER macro/comments

Marked as reviewed by dfuchs (Reviewer).

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

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

From michaelm at openjdk.java.net  Mon Oct 19 18:11:10 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 18:11:10 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v6]
In-Reply-To: <MUblS1S6mjXT7UkKbeQYL4nMe2OTioQzTK-37hlscIc=.006aaa33-969c-4c46-991f-bc0d84aae128@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
 <MUblS1S6mjXT7UkKbeQYL4nMe2OTioQzTK-37hlscIc=.006aaa33-969c-4c46-991f-bc0d84aae128@github.com>
Message-ID: <Hccw1ev-A62MSJOb_6lhX1ZaVvCdh1vQo9jVvhpU5dk=.77ea38fc-8f60-4c5d-b5a1-f9faa277a3b0@github.com>

On Mon, 19 Oct 2020 17:36:25 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
>> HttpsServer' ?
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpsExchange`
>> `com.sun.net.httpserver.HttpsParameters`
>> `com.sun.net.httpserver.HttpsServer`
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253474: Fixed typo; removed TIGER macro/comments

Marked as reviewed by michaelm (Reviewer).

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

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

From michaelm at openjdk.java.net  Mon Oct 19 22:13:40 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 19 Oct 2020 22:13:40 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v28]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  final feedback from Alan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/eca95d86..36623a45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=27
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=26-27

  Stats: 191 lines in 9 files changed: 30 ins; 100 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From alanb at openjdk.java.net  Tue Oct 20 07:22:39 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 20 Oct 2020 07:22:39 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v28]
In-Reply-To: <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>
Message-ID: <zYaJzzZlRIih1y7ECUv3dBeeNMqOoteBuy33NavOrqU=.c9c3c34a-0916-4f78-b7a8-b27d0f2aad58@github.com>

On Mon, 19 Oct 2020 22:13:40 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final feedback from Alan

I've done several detailed passes over the implementation changes. All my comments/changes have been incorporated into
the latest patch. The high-level summary is that it now looks like this features has been there from the start.

I did a "light pass" over the tests but don't have cycles to go through every line. The coverage seems good but some
tests will need cleanup. I think Daniel is doing a detail pass on the tests.

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

Marked as reviewed by alanb (Reviewer).

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

From pconcannon at openjdk.java.net  Tue Oct 20 10:04:32 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Oct 2020 10:04:32 GMT
Subject: RFR: 8253474: Javadoc clean up in HttpsExchange, HttpsParameters,
 and HttpsServer [v7]
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <7y6arkt9DW3SID8XgxryFV0iGXSXcgSIs8X0-tPEs-U=.2452b471-eaa3-498f-b6ce-038af256d9f9@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and
> HttpsServer' ?
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer`
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 seven additional
commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Fixed typo; removed TIGER macro/comments
 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Comment added to default constructor; fixed punctuation in create(InetSocketAddress, int)
 - Merge remote-tracking branch 'origin/master' into JDK-8253474
 - 8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/610/files
  - new: https://git.openjdk.java.net/jdk/pull/610/files/45f45182..d79f03fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=610&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=610&range=05-06

  Stats: 26889 lines in 294 files changed: 17258 ins; 8055 del; 1576 mod
  Patch: https://git.openjdk.java.net/jdk/pull/610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/610/head:pull/610

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

From dfuchs at openjdk.java.net  Tue Oct 20 10:41:22 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 20 Oct 2020 10:41:22 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v28]
In-Reply-To: <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>
Message-ID: <TL6gL3Q1yOcQ4hfIsAEZWwb_crM59qaeHj8HnF18Np4=.ab77fdd3-fbe8-453f-aa39-cbc5f41db3c0@github.com>

On Mon, 19 Oct 2020 22:13:40 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final feedback from Alan

The tests mostly look good to me. There's a general cleanup needed to make sure channels get closed properly in case of
exception (that is - use try-with-resources whenever possible).

test/jdk/java/net/UnixDomainSocketAddress/AddressTest.java line 43:

> 41: public class AddressTest {
> 42:
> 43:     static UnixDomainSocketAddress addr;

This static seems to be unused?

test/jdk/java/net/UnixDomainSocketAddress/AddressTest.java line 29:

> 27:  * @compile ../../nio/file/spi/TestProvider.java AddressTest.java
> 28:  * @run testng/othervm AddressTest
> 29:  */

Could add `@summary` - IIUC this test checks that a Path that doesn't come from the build in filesystem is rejected by
`UnixDomainSocketAddress`?

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 85:

> 83:         sc2.close();
> 84:         Files.delete(addr.getPath());
> 85:         ssc.close();

Should this use nested try-with-resources to close `ssc` and `sc2`?

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 107:

> 105:         sc2.close();
> 106:         ssc.close();
> 107:         return sc1;

Here again nested try-with-resources could be used to close sc2 and ssc.

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 136:

> 134:         ssc.close();
> 135:         InetSocketAddress isa = new InetSocketAddress(InetAddress.getLocalHost(), port);
> 136:         return SocketChannel.open(isa);

dito.

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 144:

> 142:         var addr = ssc.getLocalAddress();
> 143:         launch(className, null, null, Util.getFD(ssc));
> 144:         ssc.close();

Use try-with-resource?

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 170:

> 168:                                                             String[] options,
> 169:                                                             String... args)
> 170:             throws IOException {

Using try-with-resource or try-finally to make sure `dc` is closed properly should be envisaged.

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTest.java line 172:

> 170:         /*
> 171:          * Launch service with a SocketChannel (tcp nowait)
> 172:          */

try-with-resources or try-finally could be used in this file too to ensure that everything gets properly closed.

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixDomainChannelTest.java line 56:

> 54:                     ByteBuffer buf = ByteBuffer.wrap(result.getBytes(ISO_8859_1));
> 55:                     sc.write(buf);
> 56:                 }

Should the test fail if `channel` is not an instance of `SocketChannel`? Or at least print some kind of debug
information? Do we want to verify that it's a Unix Domain Socket Channel - e.g. by looking at the local address?
Same question for the server socket case below...

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixDomainChannelTest.java line 78:

> 76:     // Test with a named connected socket
> 77:     private static void test1() throws Exception {
> 78:         ServerSocketChannel listener = ServerSocketChannel.open(UNIX);

Maybe try with resources or try-finally could be used to ensure that all channels are closed.

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixSocketTest.java line 53:

> 51:     public static class Child2 {
> 52:         public static void main(String[] args) throws Exception {
> 53:             ServerSocketChannel server = (ServerSocketChannel)System.inheritedChannel();

Maybe use try-with-resources

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixSocketTest.java line 41:

> 39:     public static class Child1 {
> 40:         public static void main(String[] args) throws Exception {
> 41:             SocketChannel chan = (SocketChannel)System.inheritedChannel();

try-with-resources?

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixSocketTest.java line 68:

> 66:
> 67:     public static void main(String args[]) throws Exception {
> 68:         SocketChannel sc = Launcher.launchWithUnixSocketChannel("UnixSocketTest$Child1");

try-with-resources?

test/jdk/java/nio/channels/unixdomain/Bind.java line 118:

> 116:                 client.close();
> 117:             if (accept1 != null)
> 118:                 accept1.close();

Maybe each of these `close()` calls should be in its own try-catch.

test/jdk/java/nio/channels/unixdomain/Bind.java line 132:

> 130:     static void assertAddress(SocketAddress a, UnixDomainSocketAddress a1, String s) {
> 131:         if (!(a instanceof UnixDomainSocketAddress)) {
> 132:             throw new RuntimeException("wrong address type");

It would be useful to which wrong address type was observed.

test/jdk/java/nio/channels/unixdomain/Bind.java line 136:

> 134:         UnixDomainSocketAddress ua = (UnixDomainSocketAddress)a;
> 135:         if (!a.equals(a1))
> 136:             throw new RuntimeException("this is not the " + s + " address");

Could you consider turning this test into a `testng` test so that asssertEquals can be used?
Alternatively if you want to retain the ability to run the test as a standalone java program out of the repository then
consider modifying the assertXxxx methods so that the exception message prints both parts: `<what>` is not equal to
`<what>`

test/jdk/java/nio/channels/unixdomain/Bind.java line 140:

> 138:
> 139:     static void assertEquals(Object a, Object b) {
> 140:         if (!a.equals(b))

Should this call Objects.equals instead?

test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 61:

> 59:             System.out.println("The socketChannel is : expected Null " + socketChannel);
> 60:             // exception could be thrown otherwise
> 61:         }

Do we have/need a test that goes the whole way down? Register for OP_CONNECT with a selector and wait for the connect
to finish?

test/jdk/java/nio/channels/unixdomain/Security.java line 127:

> 125:         final UnixDomainSocketAddress saddr = UnixDomainSocketAddress.of(servername);
> 126:         final ServerSocketChannel server = ServerSocketChannel.open(UNIX);
> 127:         final SocketChannel client = SocketChannel.open(UNIX);

Maybe try-with-resources should be used and a finally too to ensure that the file is deleted...

test/jdk/java/nio/channels/unixdomain/Security.java line 145:

> 143:         final UnixDomainSocketAddress saddr = UnixDomainSocketAddress.of(servername);
> 144:         final ServerSocketChannel server = ServerSocketChannel.open(UNIX);
> 145:         final SocketChannel client = SocketChannel.open(UNIX);

Same remark as above

test/jdk/java/nio/channels/unixdomain/Security.java line 163:

> 161:         s1.bind(saddr);
> 162:         var s2 = ServerSocketChannel.open(UNIX);
> 163:         s2.bind(null);

same remark as above

test/jdk/java/nio/channels/unixdomain/SocketOptions.java line 59:

> 57:         s.bind(null);
> 58:         UnixDomainSocketAddress addr = (UnixDomainSocketAddress)s.getLocalAddress();
> 59:         SocketChannel c = SocketChannel.open(addr);

try-with-resources?

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

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

From michaelm at openjdk.java.net  Tue Oct 20 11:42:02 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 11:42:02 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v29]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <z3Ar2avOFqmrApkbeDbZCqYsrlus-Q9uJZYOc1N33A0=.030ec0f2-aff6-4a0e-be26-5f68cdd4cd77@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since
the last revision:

 - Merge branch 'master' into unixdomainchannels
 - final feedback from Alan
 - Merge branch 'master' into unixdomainchannels
 - - Alan's review patch from Oct 18
   - Reverted changes to JFR unit tests
 - - added NullTest and fix in SocketChannel.open
   - updated test bug ids
 - - use String.isEmpty where appropriate
 - fix white space error
 - - test updates from Daniel's review 14 Oct 2020
 - src changes from Daniel's review. Tests will come later
 - Merge branch 'master' into unixdomainchannels
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/73958dea...053bffee

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/36623a45..053bffee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=28
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=27-28

  Stats: 27994 lines in 425 files changed: 18001 ins; 8154 del; 1839 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Tue Oct 20 13:21:18 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 13:21:18 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v28]
In-Reply-To: <TL6gL3Q1yOcQ4hfIsAEZWwb_crM59qaeHj8HnF18Np4=.ab77fdd3-fbe8-453f-aa39-cbc5f41db3c0@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>
 <TL6gL3Q1yOcQ4hfIsAEZWwb_crM59qaeHj8HnF18Np4=.ab77fdd3-fbe8-453f-aa39-cbc5f41db3c0@github.com>
Message-ID: <kqeQXiA-QwUOjgrqc2pCd1SjIJKCFtWP173qbEMkiZQ=.0a4c1972-ff05-4730-a1df-04c4d6d42ad3@github.com>

On Tue, 20 Oct 2020 10:28:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   final feedback from Alan
>
> test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 61:
> 
>> 59:             System.out.println("The socketChannel is : expected Null " + socketChannel);
>> 60:             // exception could be thrown otherwise
>> 61:         }
> 
> Do we have/need a test that goes the whole way down? Register for OP_CONNECT with a selector and wait for the connect
> to finish?

Yes, the IOExchanges test covers many different scenarios around that

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

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

From michaelm at openjdk.java.net  Tue Oct 20 13:37:30 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 13:37:30 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v28]
In-Reply-To: <TL6gL3Q1yOcQ4hfIsAEZWwb_crM59qaeHj8HnF18Np4=.ab77fdd3-fbe8-453f-aa39-cbc5f41db3c0@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <8qXt688DkV_bcls1a6fa1n3McvwPfVrg4GoXgkg2Pcs=.4def0893-b1d8-4a10-a5ea-5a90cad3ac64@github.com>
 <TL6gL3Q1yOcQ4hfIsAEZWwb_crM59qaeHj8HnF18Np4=.ab77fdd3-fbe8-453f-aa39-cbc5f41db3c0@github.com>
Message-ID: <q4l9v95XHvelOriBuM24ud97Rdyi3HTvGFGiR4_zMWs=.b0cf1c59-8067-4dbc-baf9-cb5eaf0b0d70@github.com>

On Tue, 20 Oct 2020 10:36:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   final feedback from Alan
>
> test/jdk/java/nio/channels/unixdomain/SocketOptions.java line 59:
> 
>> 57:         s.bind(null);
>> 58:         UnixDomainSocketAddress addr = (UnixDomainSocketAddress)s.getLocalAddress();
>> 59:         SocketChannel c = SocketChannel.open(addr);
> 
> try-with-resources?

Thanks. Made all these suggested try with resources changes.

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

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

From michaelm at openjdk.java.net  Tue Oct 20 13:44:37 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 13:44:37 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v30]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <BDUOvyW_GqtcdXd7JrCwhkwCdXMuMIqMD0MUi_i-ztE=.6bd40d3a-8c4e-4412-98c1-2ba81c8a4de6@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  update from Daniel's test comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/053bffee..cc106a7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=29
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=28-29

  Stats: 140 lines in 4 files changed: 19 ins; 2 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Tue Oct 20 13:52:41 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 13:52:41 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v31]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <YDMsW-YXQk6uelRyQTpmpq0ZeQ4hKCACziQh1fZkqH0=.fa81bbbc-d098-44a8-8f5b-185326ad0bd2@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  forgot to stage updated test files in last commit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/cc106a7d..3594e4b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=30
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=29-30

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

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

From dfuchs at openjdk.java.net  Tue Oct 20 14:05:25 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 20 Oct 2020 14:05:25 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v31]
In-Reply-To: <YDMsW-YXQk6uelRyQTpmpq0ZeQ4hKCACziQh1fZkqH0=.fa81bbbc-d098-44a8-8f5b-185326ad0bd2@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <YDMsW-YXQk6uelRyQTpmpq0ZeQ4hKCACziQh1fZkqH0=.fa81bbbc-d098-44a8-8f5b-185326ad0bd2@github.com>
Message-ID: <6QSz5qS9tPOYNRB-73CndYoroOXkuVUptlMf3peq988=.d174e499-7f09-4ed7-9e4b-08d952f327d4@github.com>

On Tue, 20 Oct 2020 13:52:41 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgot to stage updated test files in last commit

test/jdk/java/net/UnixDomainSocketAddress/AddressTest.java line 45:

> 43:  * if given a Path that does not originate from system default
> 44:  * file system.
> 45:  */

I was thinking to put that in a `@summary` just after `@test` above ...

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 85:

> 83:                 launch(className, null, null, Util.getFD(sc2));
> 84:             }
> 85:             Files.delete(addr.getPath());

should that be:
try (...) {
} finally {
    Files.deleteIfExists(addr.getPath);
}

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

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

From michaelm at openjdk.java.net  Tue Oct 20 14:14:19 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 14:14:19 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v31]
In-Reply-To: <6QSz5qS9tPOYNRB-73CndYoroOXkuVUptlMf3peq988=.d174e499-7f09-4ed7-9e4b-08d952f327d4@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <YDMsW-YXQk6uelRyQTpmpq0ZeQ4hKCACziQh1fZkqH0=.fa81bbbc-d098-44a8-8f5b-185326ad0bd2@github.com>
 <6QSz5qS9tPOYNRB-73CndYoroOXkuVUptlMf3peq988=.d174e499-7f09-4ed7-9e4b-08d952f327d4@github.com>
Message-ID: <xv3Wx0PPGbctijZDIwwB5Ka7eQhsOdz_tIRnYoa4dkI=.41605c25-636c-4be1-9b8c-7b9441a345b2@github.com>

On Tue, 20 Oct 2020 13:59:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   forgot to stage updated test files in last commit
>
> test/jdk/java/net/UnixDomainSocketAddress/AddressTest.java line 45:
> 
>> 43:  * if given a Path that does not originate from system default
>> 44:  * file system.
>> 45:  */
> 
> I was thinking to put that in a `@summary` just after `@test` above ...

I was going to put it there, but I think it's too much text for an @summary imo

> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java line 85:
> 
>> 83:                 launch(className, null, null, Util.getFD(sc2));
>> 84:             }
>> 85:             Files.delete(addr.getPath());
> 
> should that be:
> try (...) {
> } finally {
>     Files.deleteIfExists(addr.getPath);
> }

You're right. Thanks

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

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

From michaelm at openjdk.java.net  Tue Oct 20 14:21:42 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 20 Oct 2020 14:21:42 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v32]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <LaM9jcyJpuMiO_11qMyplXW5-0YbkJjPzb0lPvOWsZ0=.1b964e5e-b87e-4cbc-8f09-6de8a46d572e@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  further test update from Daniel

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/3594e4b0..e07522b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=31
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=30-31

  Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From dfuchs at openjdk.java.net  Tue Oct 20 18:31:28 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 20 Oct 2020 18:31:28 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v32]
In-Reply-To: <LaM9jcyJpuMiO_11qMyplXW5-0YbkJjPzb0lPvOWsZ0=.1b964e5e-b87e-4cbc-8f09-6de8a46d572e@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <LaM9jcyJpuMiO_11qMyplXW5-0YbkJjPzb0lPvOWsZ0=.1b964e5e-b87e-4cbc-8f09-6de8a46d572e@github.com>
Message-ID: <Eggakz2k7ZmBV7cPUMOGA_gMmag7rDgByx4q0iZA424=.667e4010-fd1e-4eb1-a3b8-428d3b478d35@github.com>

On Tue, 20 Oct 2020 14:21:42 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   further test update from Daniel

Marked as reviewed by dfuchs (Reviewer).

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

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

From iignatyev at openjdk.java.net  Tue Oct 20 23:50:17 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 20 Oct 2020 23:50:17 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format
Message-ID: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>

Hi all,

could you please review this small patch?

according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format:
>    time-val = 14DIGIT [ "." 1*DIGIT ]
> 
>    The leading, mandatory, fourteen digits are to be interpreted as, in
>    order from the leftmost, four digits giving the year, with a range of
>    1000--9999, two digits giving the month of the year, with a range of
>    01--12, two digits giving the day of the month, with a range of
>    01--31, two digits giving the hour of the day, with a range of
>    00--23, two digits giving minutes past the hour, with a range of
>    00--59, and finally, two digits giving seconds past the minute, with
>    a range of 00--60 (with 60 being used only at a leap second). Years
>    in the tenth century, and earlier, cannot be expressed. This is not
>    considered a serious defect of the protocol.
> 
>    The optional digits, which are preceded by a period, give decimal
>    fractions of a second. These may be given to whatever precision is
>    appropriate to the circumstance, however implementations MUST NOT add
>    precision to time-vals where that precision does not exist in the
>    underlying value being transmitted.
> 
>    Symbolically, a time-val may be viewed as
> 
>   YYYYMMDDHHMMSS.sss
> 
>    The "." and subsequent digits ("sss") are optional. However the "."
>    MUST NOT appear unless at least one following digit also appears.
> 

`MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and
doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.

`FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM
response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.

testing:
* [ ] tier1
* [ ] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`

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

Commit messages:
 - 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong datetime format

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

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

From chegar at openjdk.java.net  Wed Oct 21 09:24:03 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 21 Oct 2020 09:24:03 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v32]
In-Reply-To: <LaM9jcyJpuMiO_11qMyplXW5-0YbkJjPzb0lPvOWsZ0=.1b964e5e-b87e-4cbc-8f09-6de8a46d572e@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <LaM9jcyJpuMiO_11qMyplXW5-0YbkJjPzb0lPvOWsZ0=.1b964e5e-b87e-4cbc-8f09-6de8a46d572e@github.com>
Message-ID: <ipgOVAn1c36GCfy03_POwbJcMfca4x5uadBS7tdRFfI=.4b501ce0-acc3-484d-ab74-7479a31c6b4f@github.com>

On Tue, 20 Oct 2020 14:21:42 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
>> 
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
>> 
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
>> 
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   further test update from Daniel

test/jdk/java/net/UnixDomainSocketAddress/LengthTest.java line 55:

> 53:         catch (IOException | UnsupportedOperationException e) {
> 54:             supported = false;
> 55:             out.println("Unix domain channels not supported. Test not run.");

`SkipException` can be used to avoid the boolean and the subsequent checks in all test scenario methods. e.g.

throw new org.testng.SkipException("Unix domain channels not supported");

This pattern can be used in all tests at are optional - based on platform support.

Additionally, if UOE is thrown from SocketChannel.open(UNIX), then I assume that ServerSocketChannel.open(UNIX) should also throw UOE. This can be asserted in the catch.

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

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

From pconcannon at openjdk.java.net  Wed Oct 21 10:09:57 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Oct 2020 10:09:57 GMT
Subject: Integrated: 8253474: Javadoc clean up in HttpsExchange,
 HttpsParameters, and HttpsServer
In-Reply-To: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
References: <72RS_QHbr24jV_zcyNf0m1RSjsFREiLQTjDzYjqxfMo=.aa21b5ec-480e-472c-834c-181926948679@github.com>
Message-ID: <97OdvsnR6bG_GQPpmY3F9DwjLguhVV8q3WOJbPPgrQE=.27d80fbe-f5e4-4a1b-8c9d-88ad199deb27@github.com>

On Mon, 12 Oct 2020 13:37:04 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253474: 'Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpsExchange`
> `com.sun.net.httpserver.HttpsParameters`
> `com.sun.net.httpserver.HttpsServer` 
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: da97ab5c
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/da97ab5c
Stats:     124 lines in 3 files changed: 16 ins; 21 del; 87 mod

8253474: Javadoc clean up in HttpsExchange, HttpsParameters, and HttpsServer

Reviewed-by: dfuchs, michaelm

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

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

From michaelm at openjdk.java.net  Wed Oct 21 10:22:11 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 21 Oct 2020 10:22:11 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v33]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <MHS5Ot6upyDypbyovSfXdoaqgSAMLxW_uWv9mkwAvMs=.8513faef-0cfd-41b0-8eb7-784b1494d17d@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
> 
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
> 
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
> 
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  updated one error in review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/e07522b5..368fa8bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=32
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=31-32

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

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

From dfuchs at openjdk.java.net  Wed Oct 21 10:28:05 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 21 Oct 2020 10:28:05 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v33]
In-Reply-To: <MHS5Ot6upyDypbyovSfXdoaqgSAMLxW_uWv9mkwAvMs=.8513faef-0cfd-41b0-8eb7-784b1494d17d@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <MHS5Ot6upyDypbyovSfXdoaqgSAMLxW_uWv9mkwAvMs=.8513faef-0cfd-41b0-8eb7-784b1494d17d@github.com>
Message-ID: <i1-gr-PwkhrdOExOIcie3rKbHgKI27hv-QVl9gzn9sY=.98d1f64d-b220-4cc6-b88b-f183f321d0ad@github.com>

On Wed, 21 Oct 2020 10:22:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
>> 
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
>> 
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
>> 
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated one error in review

Marked as reviewed by dfuchs (Reviewer).

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

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

From michaelm at openjdk.java.net  Wed Oct 21 11:05:24 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 21 Oct 2020 11:05:24 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v32]
In-Reply-To: <ipgOVAn1c36GCfy03_POwbJcMfca4x5uadBS7tdRFfI=.4b501ce0-acc3-484d-ab74-7479a31c6b4f@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <LaM9jcyJpuMiO_11qMyplXW5-0YbkJjPzb0lPvOWsZ0=.1b964e5e-b87e-4cbc-8f09-6de8a46d572e@github.com>
 <ipgOVAn1c36GCfy03_POwbJcMfca4x5uadBS7tdRFfI=.4b501ce0-acc3-484d-ab74-7479a31c6b4f@github.com>
Message-ID: <s1CdxMA-tlGSnPbNS4SEXgG-AlmFZ4TFBYp3qbxEj90=.0acdd9a1-2f6c-4997-a176-18320accf9ed@github.com>

On Wed, 21 Oct 2020 09:20:47 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   further test update from Daniel
>
> test/jdk/java/net/UnixDomainSocketAddress/LengthTest.java line 55:
> 
>> 53:         catch (IOException | UnsupportedOperationException e) {
>> 54:             supported = false;
>> 55:             out.println("Unix domain channels not supported. Test not run.");
> 
> `SkipException` can be used to avoid the boolean and the subsequent checks in all test scenario methods. e.g.
> 
> throw new org.testng.SkipException("Unix domain channels not supported");
> 
> This pattern can be used in all tests at are optional - based on platform support.
> 
> Additionally, if UOE is thrown from SocketChannel.open(UNIX), then I assume that ServerSocketChannel.open(UNIX) should also throw UOE. This can be asserted in the catch.

Actually, tests of the address class should pass on all platforms. The check dated back to when the test needed to know the exact maximum length of an address on the platform. I'll just remove the check.

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

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

From jlahoda at openjdk.java.net  Wed Oct 21 13:20:25 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 21 Oct 2020 13:20:25 GMT
Subject: RFR: 8255124: KeepAliveStreamCleaner may crash with
 =?UTF-8?B?amF2YS5sYW5nLklsbGVnYWxNb25pdOKApg==?=
Message-ID: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>

?orStateException: current thread is not owner

The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)

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

Commit messages:
 - Adding bug number to the test.
 - 8255124: KeepAliveStreamCleaner may crash with java.lang.IllegalMonitorStateException: current thread is not owner

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

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

From alanb at openjdk.java.net  Wed Oct 21 13:45:21 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 21 Oct 2020 13:45:21 GMT
Subject: RFR: 8255124: KeepAliveStreamCleaner may crash with
 =?UTF-8?B?amF2YS5sYW5nLklsbGVnYWxNb25pdOKApg==?=
In-Reply-To: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
References: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
Message-ID: <QWJIxl-ZBAbS-0IwU1cqEjBJbfCqOPxWVC50Fc-ovQA=.78988763-30b7-4318-a112-8de202dc0bf9@github.com>

On Wed, 21 Oct 2020 13:12:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> ?orStateException: current thread is not owner
> 
> The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)

Marked as reviewed by alanb (Reviewer).

test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 143:

> 141:         }
> 142:         if (!uncaught.isEmpty()) {
> 143:             throw new AssertionError("Unhandled exception:", uncaught.get(0));

The existing test throws RuntimeException when it fails, maybe this case should do the same.

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

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

From michaelm at openjdk.java.net  Wed Oct 21 16:31:06 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 21 Oct 2020 16:31:06 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v34]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <2lvuEMtBzkE0BkQJ3yby7Ic2GfZiswB2HQLFAdkwCH4=.f834208a-7272-4d62-86f2-69ce67273be2@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
> 
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
> 
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
> 
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:

 - Merge branch 'master' into unixdomainchannels
 - updated one error in review
 - further test update from Daniel
 - forgot to stage updated test files in last commit
 - update from Daniel's test comments
 - Merge branch 'master' into unixdomainchannels
 - final feedback from Alan
 - Merge branch 'master' into unixdomainchannels
 - - Alan's review patch from Oct 18
   - Reverted changes to JFR unit tests
 - - added NullTest and fix in SocketChannel.open
   - updated test bug ids
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/7e8abfed...01d7cf53

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/368fa8bc..01d7cf53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=33
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=32-33

  Stats: 10690 lines in 229 files changed: 8396 ins; 1287 del; 1007 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From chegar at openjdk.java.net  Wed Oct 21 16:43:43 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 21 Oct 2020 16:43:43 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v34]
In-Reply-To: <2lvuEMtBzkE0BkQJ3yby7Ic2GfZiswB2HQLFAdkwCH4=.f834208a-7272-4d62-86f2-69ce67273be2@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <2lvuEMtBzkE0BkQJ3yby7Ic2GfZiswB2HQLFAdkwCH4=.f834208a-7272-4d62-86f2-69ce67273be2@github.com>
Message-ID: <cckaogXPba7sxWoQVfy58CoyJo_L-TZRC_1N1eHXRo0=.cebc5c35-9fa9-487b-937b-dd2ed14f0703@github.com>

On Wed, 21 Oct 2020 16:31:06 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
>> 
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
>> 
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
>> 
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Merge branch 'master' into unixdomainchannels
>  - updated one error in review
>  - further test update from Daniel
>  - forgot to stage updated test files in last commit
>  - update from Daniel's test comments
>  - Merge branch 'master' into unixdomainchannels
>  - final feedback from Alan
>  - Merge branch 'master' into unixdomainchannels
>  - - Alan's review patch from Oct 18
>    - Reverted changes to JFR unit tests
>  - - added NullTest and fix in SocketChannel.open
>    - updated test bug ids
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/8c9391a4...01d7cf53

Changes requested by chegar (Reviewer).

test/jdk/java/nio/channels/unixdomain/Bind.java line 51:

> 49:         if (!supported()) {
> 50:             System.out.println("Unix domain channels not supported");
> 51:             return;

Here it would be better to throw the `jtreg.SkippedException`, rather than silently returning.  Same comment for any other tests that check supported-ness before continuing to execute.

test/jdk/java/nio/channels/unixdomain/Bind.java line 66:

> 64:             SocketChannel.open(StandardProtocolFamily.UNIX).close();
> 65:         } catch (UnsupportedOperationException e) {
> 66:             return false;

In this case `ServerSocketChannel.open(UNIX)` should also throw UOE.

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

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

From jlahoda at openjdk.java.net  Wed Oct 21 16:45:27 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 21 Oct 2020 16:45:27 GMT
Subject: RFR: 8255124: KeepAliveStreamCleaner may crash with
 =?UTF-8?B?amF2YS5sYW5nLklsbGVnYWxNb25pdOKApg==?= [v2]
In-Reply-To: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
References: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
Message-ID: <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>

> ?orStateException: current thread is not owner
> 
> The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  When the test fails, throw RuntimeException instead of AssertionError, as suggested by alanb

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/782/files
  - new: https://git.openjdk.java.net/jdk/pull/782/files/17f69560..143aa185

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

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

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

From alanb at openjdk.java.net  Wed Oct 21 16:45:27 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 21 Oct 2020 16:45:27 GMT
Subject: RFR: 8255124: KeepAliveStreamCleaner may crash with
 =?UTF-8?B?amF2YS5sYW5nLklsbGVnYWxNb25pdOKApg==?= [v2]
In-Reply-To: <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>
References: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
 <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>
Message-ID: <iO7xhRayXYyrslZHd7RXIL8jc0sbd9pQelv7KiLo5GA=.0c29a0cc-0756-4ca1-a43e-6ca822b896ab@github.com>

On Wed, 21 Oct 2020 16:42:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> ?orStateException: current thread is not owner
>> 
>> The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   When the test fails, throw RuntimeException instead of AssertionError, as suggested by alanb

Marked as reviewed by alanb (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Oct 21 17:04:21 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 21 Oct 2020 17:04:21 GMT
Subject: RFR: 8255124: KeepAliveStreamCleaner may crash with
 =?UTF-8?B?amF2YS5sYW5nLklsbGVnYWxNb25pdOKApg==?= [v2]
In-Reply-To: <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>
References: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
 <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>
Message-ID: <Dst3sbvOY-z8LR2MylIs-_N-Yd6YIEdIoz6-J9vrqZg=.6001e846-7885-4203-a1d9-8600ad9d27e1@github.com>

On Wed, 21 Oct 2020 16:45:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> ?orStateException: current thread is not owner
>> 
>> The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   When the test fails, throw RuntimeException instead of AssertionError, as suggested by alanb

Marked as reviewed by chegar (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Oct 21 17:04:44 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 21 Oct 2020 17:04:44 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v34]
In-Reply-To: <2lvuEMtBzkE0BkQJ3yby7Ic2GfZiswB2HQLFAdkwCH4=.f834208a-7272-4d62-86f2-69ce67273be2@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <2lvuEMtBzkE0BkQJ3yby7Ic2GfZiswB2HQLFAdkwCH4=.f834208a-7272-4d62-86f2-69ce67273be2@github.com>
Message-ID: <T3cQhI8GWYToYQBIQGpcw9LEj5zvn4SI9aCosWbI3Ws=.f7faf8ef-8ae2-4bdf-b9ac-fccd41153877@github.com>

On Wed, 21 Oct 2020 16:31:06 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
>> 
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
>> 
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
>> 
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Merge branch 'master' into unixdomainchannels
>  - updated one error in review
>  - further test update from Daniel
>  - forgot to stage updated test files in last commit
>  - update from Daniel's test comments
>  - Merge branch 'master' into unixdomainchannels
>  - final feedback from Alan
>  - Merge branch 'master' into unixdomainchannels
>  - - Alan's review patch from Oct 18
>    - Reverted changes to JFR unit tests
>  - - added NullTest and fix in SocketChannel.open
>    - updated test bug ids
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/62cfdb45...01d7cf53

Changes requested by chegar (Reviewer).

test/jdk/java/nio/channels/unixdomain/policy1 line 1:

> 1: grant {

It is often the case that a copyright and license header is added to such policy files, policy1, policy2, policy3

test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 59:

> 57:             serverSocketChannel.bind(null);
> 58:             SocketChannel socketChannel = serverSocketChannel.accept();
> 59:             System.out.println("The socketChannel is : expected Null " + socketChannel);

The null-ness of the returned socket channel be asserted, regardless of whether or not a prior version of the code threw an exception.

test/jdk/java/nio/channels/unixdomain/IOExchanges.java line 49:

> 47: 
> 48: public class IOExchanges {
> 49:     static boolean supported = true;

This should really be `unixDomainSupported` or some such, to indication that it us used to seed the set of protocol families to test with; IP-only, or IP+Unix.  When I wrote this test originally, the intent was that it could operate with channels of different protocol types, IP, rsocket, and now Unix. Happy to see that it is finally being integrated. Maybe update the copyright year range to start at 2018, see https://cr.openjdk.java.net/~chegar/rsocket/IOExchanges/test/jdk/jdk/net/RdmaSockets/rsocket/SocketChannel/IOExchanges.java.html

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

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

From dfuchs at openjdk.java.net  Wed Oct 21 19:05:12 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 21 Oct 2020 19:05:12 GMT
Subject: RFR: 8255124: KeepAliveStreamCleaner may crash with
 =?UTF-8?B?amF2YS5sYW5nLklsbGVnYWxNb25pdOKApg==?= [v2]
In-Reply-To: <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>
References: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
 <7Z4qjpPWgcSl9AqrVDmuqBUOPKdXQ3Bysi_Mmd09OIw=.0a30cfad-389a-4b13-b2ed-13d7e235c6a8@github.com>
Message-ID: <d6iDNLSVtbXUm3gNvY3B5vTW4ZoIwDsQ1KjgCP0Xobo=.d52ac961-92db-467a-90c1-a6dcbf83fc76@github.com>

On Wed, 21 Oct 2020 16:45:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> ?orStateException: current thread is not owner
>> 
>> The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   When the test fails, throw RuntimeException instead of AssertionError, as suggested by alanb

Marked as reviewed by dfuchs (Reviewer).

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

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

From jlahoda at openjdk.java.net  Thu Oct 22 07:35:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 22 Oct 2020 07:35:13 GMT
Subject: Integrated: 8255124: KeepAliveStreamCleaner may crash with
 java.lang.IllegalMonitorStateException: current thread is not owner
In-Reply-To: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
References: <kceKCmM64AmdJCmPDwTXQxPqSZon0sxLGU7KHo7w79Y=.a2144684-9d75-414c-a278-7f0548e825b8@github.com>
Message-ID: <wO76rJwspCc-syjECX373Kp4rVMWWmzIymfu6BqM_68=.b10391ba-6e6f-4c3e-8891-ec612d7b534a@github.com>

On Wed, 21 Oct 2020 13:12:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> ?orStateException: current thread is not owner
> 
> The KeepAliveStreamCleaner is calling Condition.wait (i.e. the Object.wait variant), should presumably be calling Condition.await. (NetBeans is producing warnings on the line as well.)

This pull request has now been integrated.

Changeset: 211bb62a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/211bb62a
Stats:     12 lines in 2 files changed: 10 ins; 0 del; 2 mod

8255124: KeepAliveStreamCleaner may crash with java.lang.IllegalMonitorStateException: current thread is not owner

Reviewed-by: alanb, chegar, dfuchs

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

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

From michaelm at openjdk.java.net  Thu Oct 22 08:06:33 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 22 Oct 2020 08:06:33 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v34]
In-Reply-To: <cckaogXPba7sxWoQVfy58CoyJo_L-TZRC_1N1eHXRo0=.cebc5c35-9fa9-487b-937b-dd2ed14f0703@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <2lvuEMtBzkE0BkQJ3yby7Ic2GfZiswB2HQLFAdkwCH4=.f834208a-7272-4d62-86f2-69ce67273be2@github.com>
 <cckaogXPba7sxWoQVfy58CoyJo_L-TZRC_1N1eHXRo0=.cebc5c35-9fa9-487b-937b-dd2ed14f0703@github.com>
Message-ID: <V_Wihk7GPzVLRINq8EQ0gsdo6zmDH43yVLxsElam4Gk=.982f154a-ea5b-4aad-8636-d7747b438fa8@github.com>

On Wed, 21 Oct 2020 16:38:16 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into unixdomainchannels
>>  - updated one error in review
>>  - further test update from Daniel
>>  - forgot to stage updated test files in last commit
>>  - update from Daniel's test comments
>>  - Merge branch 'master' into unixdomainchannels
>>  - final feedback from Alan
>>  - Merge branch 'master' into unixdomainchannels
>>  - - Alan's review patch from Oct 18
>>    - Reverted changes to JFR unit tests
>>  - - added NullTest and fix in SocketChannel.open
>>    - updated test bug ids
>>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/d3e47796...01d7cf53
>
> test/jdk/java/nio/channels/unixdomain/Bind.java line 51:
> 
>> 49:         if (!supported()) {
>> 50:             System.out.println("Unix domain channels not supported");
>> 51:             return;
> 
> Here it would be better to throw the `jtreg.SkippedException`, rather than silently returning.  Same comment for any other tests that check supported-ness before continuing to execute.

Ok

> test/jdk/java/nio/channels/unixdomain/Bind.java line 66:
> 
>> 64:             SocketChannel.open(StandardProtocolFamily.UNIX).close();
>> 65:         } catch (UnsupportedOperationException e) {
>> 66:             return false;
> 
> In this case `ServerSocketChannel.open(UNIX)` should also throw UOE.

I'll add a specific test that checks if `SocketChannel.open(UNIX)` throws UOE than `ServerSocketChannel.open(UNIX)` should also.

> test/jdk/java/nio/channels/unixdomain/policy1 line 1:
> 
>> 1: grant {
> 
> It is often the case that a copyright and license header is added to such policy files, policy1, policy2, policy3

OK

> test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 59:
> 
>> 57:             serverSocketChannel.bind(null);
>> 58:             SocketChannel socketChannel = serverSocketChannel.accept();
>> 59:             System.out.println("The socketChannel is : expected Null " + socketChannel);
> 
> The null-ness of the returned socket channel be asserted, regardless of whether or not a prior version of the code threw an exception.

OK

> test/jdk/java/nio/channels/unixdomain/IOExchanges.java line 49:
> 
>> 47: 
>> 48: public class IOExchanges {
>> 49:     static boolean supported = true;
> 
> This should really be `unixDomainSupported` or some such, to indication that it us used to seed the set of protocol families to test with; IP-only, or IP+Unix.  When I wrote this test originally, the intent was that it could operate with channels of different protocol types, IP, rsocket, and now Unix. Happy to see that it is finally being integrated. Maybe update the copyright year range to start at 2018, see https://cr.openjdk.java.net/~chegar/rsocket/IOExchanges/test/jdk/jdk/net/RdmaSockets/rsocket/SocketChannel/IOExchanges.java.html

Ok, thanks for review!

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

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

From michaelm at openjdk.java.net  Thu Oct 22 08:14:31 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 22 Oct 2020 08:14:31 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v35]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <kIVPvKsvadaUws4d8NQcpr9v6Q5qPAYzwkpyny7t8Nc=.df5cdede-e590-4ba4-94ba-c50fbe23541a@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
> 
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
> 
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
> 
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - fixed 32 bit Linux build error
  - test updates from Chris

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/01d7cf53..c01c3c9b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=34
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=33-34

  Stats: 128 lines in 8 files changed: 72 ins; 24 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From chegar at openjdk.java.net  Thu Oct 22 08:29:28 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 22 Oct 2020 08:29:28 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v35]
In-Reply-To: <kIVPvKsvadaUws4d8NQcpr9v6Q5qPAYzwkpyny7t8Nc=.df5cdede-e590-4ba4-94ba-c50fbe23541a@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <kIVPvKsvadaUws4d8NQcpr9v6Q5qPAYzwkpyny7t8Nc=.df5cdede-e590-4ba4-94ba-c50fbe23541a@github.com>
Message-ID: <NgL9rpouIjzOL4CDYHvS7RaUoKpkjzhXzBV3UfGON5c=.609f94de-32c0-47a0-91c7-4e1c34a94b55@github.com>

On Thu, 22 Oct 2020 08:14:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
>> 
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
>> 
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
>> 
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - fixed 32 bit Linux build error
>   - test updates from Chris

Marked as reviewed by chegar (Reviewer).

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

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

From dfuchs at openjdk.java.net  Thu Oct 22 10:36:11 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 22 Oct 2020 10:36:11 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format
In-Reply-To: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
Message-ID: <cyxEikZZJIKevjVRkqxhEwLNRHiZXAqhLxsNNBtR4q0=.bd2354b5-0a91-4b0c-bf09-deb73dd27e40@github.com>

On Tue, 20 Oct 2020 23:14:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch?
> 
> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>> 
>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>    order from the leftmost, four digits giving the year, with a range of 
>>    1000--9999, two digits giving the month of the year, with a range of 
>>    01--12, two digits giving the day of the month, with a range of 
>>    01--31, two digits giving the hour of the day, with a range of 
>>    00--23, two digits giving minutes past the hour, with a range of 
>>    00--59, and finally, two digits giving seconds past the minute, with 
>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>    considered a serious defect of the protocol. 
>> 
>>    The optional digits, which are preceded by a period, give decimal 
>>    fractions of a second. These may be given to whatever precision is 
>>    appropriate to the circumstance, however implementations MUST NOT add 
>>    precision to time-vals where that precision does not exist in the 
>>    underlying value being transmitted. 
>> 
>>    Symbolically, a time-val may be viewed as 
>> 
>>   YYYYMMDDHHMMSS.sss 
>> 
>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>    MUST NOT appear unless at least one following digit also appears. 
>> 
> 
> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
> 
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
> 
> testing:
> * [x] tier1
> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`

Hi Igor, is this testable - and if so shouldn't there be a test?
best regards,
-- daniel

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

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

From pconcannon at openjdk.java.net  Thu Oct 22 14:42:19 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Oct 2020 14:42:19 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator
Message-ID: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>

Hi,

Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?

This fix is set of formatting changes intended to clean up the javadoc of the following classes :

`com.sun.net.httpserver.HttpHandler`
`com.sun.net.httpserver.HttpPrincipal`
`com.sun.net.httpserver.HttpContext`
`com.sun.net.httpserver.HttpsConfigurator` 

This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)

Kind regards,
Patrick

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

Commit messages:
 - 8253473: Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator

Changes: https://git.openjdk.java.net/jdk/pull/810/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=810&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253473
  Stats: 127 lines in 4 files changed: 26 ins; 8 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk/pull/810.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/810/head:pull/810

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

From iignatyev at openjdk.java.net  Thu Oct 22 16:07:11 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 22 Oct 2020 16:07:11 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format
In-Reply-To: <cyxEikZZJIKevjVRkqxhEwLNRHiZXAqhLxsNNBtR4q0=.bd2354b5-0a91-4b0c-bf09-deb73dd27e40@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <cyxEikZZJIKevjVRkqxhEwLNRHiZXAqhLxsNNBtR4q0=.bd2354b5-0a91-4b0c-bf09-deb73dd27e40@github.com>
Message-ID: <sEn5XfJ3l_xPHseV0wpN8hxW1USVl743V93JVQ6yWak=.aba22db6-1194-4aae-8733-48ebb0235460@github.com>

On Thu, 22 Oct 2020 10:33:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Igor, is this testable - and if so shouldn't there be a test?
> best regards,
> -- daniel

Hi Daniel,

it's testable and originally I planned to add a new test, however upon checking the existing mock ftp-servers, I realized that none of them support MLSx commands, and adding that support doesn't seem to be justified for such a trivial fix. With that being said, I can create a test for this if you believe it's necessary.

-- Igor

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

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

From jjg at openjdk.java.net  Thu Oct 22 17:29:21 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 22 Oct 2020 17:29:21 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
Message-ID: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>

The change is (just) to remove legacy usages of a JDK-private custom tag.

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

Commit messages:
 - JDK-8255262: Remove use of legacy custom @spec tag

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

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

From lancea at openjdk.java.net  Thu Oct 22 17:35:15 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 22 Oct 2020 17:35:15 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <YqDdpupjEAA42B4PFVQOO5Chtneb-DXRonDYRk0g1oU=.84fb141b-90cd-4c59-a0ca-e2e749898547@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

looks fine

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

Marked as reviewed by lancea (Reviewer).

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

From iris at openjdk.java.net  Thu Oct 22 17:46:16 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 22 Oct 2020 17:46:16 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <-NCS5lF0mdeaDq1CyQYTrh0gGVozPafltjNYsEpO488=.d795b2ec-acc2-4c06-8434-757b2095e386@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Nice clean-up.

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

Marked as reviewed by iris (Reviewer).

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

From mr at openjdk.java.net  Thu Oct 22 17:46:15 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 22 Oct 2020 17:46:15 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <IBnKE7sN9xlVAuD9BAutsshS8xqFrfZiksTR1Vy7KYs=.c10a9cd1-b81a-491d-85ba-fa5785b224eb@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

As the creator of these tags many moons ago, I approve this change.

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

Marked as reviewed by mr (Lead).

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

From darcy at openjdk.java.net  Thu Oct 22 17:46:18 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Oct 2020 17:46:18 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <5hlum1g6yK7pF3TkDMBvYSlK0Ca3bVh1VM3XJUVAvCk=.93e60ef2-400c-4775-a4c5-1f290e14ed57@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by darcy (Reviewer).

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

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

From alanb at openjdk.java.net  Thu Oct 22 17:46:17 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 22 Oct 2020 17:46:17 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <TOmCzg8UsQNgcxFkhfFIrZ3pPjnJQR_wRxMmuQ5z1tc=.82fb45d2-9a57-42ed-b7bc-bffc6a0ffcac@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by alanb (Reviewer).

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

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

From mchung at openjdk.java.net  Thu Oct 22 17:56:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Oct 2020 17:56:16 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <CfzmVDcf7nrnyFKDthPyHgl0oxzB3mhVX-O_HeNK4ak=.ad190ae9-cdad-4ecf-a831-025ca3449893@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by mchung (Reviewer).

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

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

From jjg at openjdk.java.net  Thu Oct 22 19:49:22 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 22 Oct 2020 19:49:22 GMT
Subject: Integrated: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <AF8Qx0S97zH-OBwiR9XmXmR9CBm12YhuYY2pfk2Ab7A=.76dafd63-a12a-403a-b0c4-df482c607f3b@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

This pull request has now been integrated.

Changeset: 0aa3c925
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0aa3c925
Stats:     209 lines in 69 files changed: 0 ins; 209 del; 0 mod

8255262: Remove use of legacy custom @spec tag

Reviewed-by: lancea, mr, iris, alanb, darcy, mchung

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

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

From github.com+10482586+erik1iu at openjdk.java.net  Fri Oct 23 03:27:17 2020
From: github.com+10482586+erik1iu at openjdk.java.net (Eric Liu)
Date: Fri, 23 Oct 2020 03:27:17 GMT
Subject: RFR: 8254871: Remove unnecessary string copy in NetworkInterface.c
Message-ID: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>

A small improvement to avoid extra string copy.

[Tests]
Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
No new failure found.

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

Commit messages:
 - 8254871: Remove unnecessary string copy in NetworkInterface.c

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

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

From redestad at openjdk.java.net  Fri Oct 23 08:03:51 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 23 Oct 2020 08:03:51 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <UFtn8VaJM1cAXrMBv_n7vga1ebhNfBjEjowMz_hEPyE=.0e65792f-4bc6-486c-94c9-dcc3d25f23c4@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

Filed [8255299](https://bugs.openjdk.java.net/browse/JDK-8255299) for this. Prefix the name of the PR with "8255299: " and it should pass checks.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct 23 08:03:51 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 23 Oct 2020 08:03:51 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
Message-ID: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>

As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
public class AtomicBenchmark {
  @Benchmark
  public Object defaultValue() {
    return new AtomicInteger();
  }
  @Benchmark
  public Object explicitValue() {
    return new AtomicInteger(0);
  }
}
THis benchmark demonstrates that `explicitValue()` is much slower:
Benchmark                      Mode  Cnt   Score   Error  Units
AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.

I've tested the changes locally, both tier1 and tier 2 are ok. 

Could one create an issue for tracking this?

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

Commit messages:
 - 8255299: Drop explicit zeroing at instantiation of Atomic* objects

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

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

From redestad at openjdk.java.net  Fri Oct 23 08:08:35 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 23 Oct 2020 08:08:35 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <a7akNKOUo7C8Zp2oI7gWoNrY82jsAbjvlcSSjzghGIs=.56787fcd-8758-47ca-89bd-a74ba7f1a7b6@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

Marked as reviewed by redestad (Reviewer).

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

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

From serb at openjdk.java.net  Fri Oct 23 08:17:40 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 23 Oct 2020 08:17:40 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

The changes in src/java.desktop looks fine.

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

Marked as reviewed by serb (Reviewer).

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

From dfuchs at openjdk.java.net  Fri Oct 23 09:14:43 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 09:14:43 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <PG8nxD4Mf9_jJpCgRj_pRrvUuT38qRaK0CoGpcm8y4U=.9e282356-0e4b-4034-ac6b-ca5afaa69424@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

src/java.base/share/classes/sun/net/ResourceManager.java line 65:

> 63:         } catch (NumberFormatException e) {}
> 64:         maxSockets = defmax;
> 65:         numSockets = new AtomicInteger();

Changes in sun/net look good to me.

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

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

From dfuchs at openjdk.java.net  Fri Oct 23 09:17:36 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 09:17:36 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>
Message-ID: <JbMPcYdgEa-E-congqKtykPOp2tbK5NT5cN9NwPzdKY=.92bcae3c-6514-48cb-b102-551c7a798e6f@github.com>

On Fri, 23 Oct 2020 08:15:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @BenchmarkMode(value = Mode.AverageTime)
>> public class AtomicBenchmark {
>>   @Benchmark
>>   public Object defaultValue() {
>>     return new AtomicInteger();
>>   }
>>   @Benchmark
>>   public Object explicitValue() {
>>     return new AtomicInteger(0);
>>   }
>> }
>> THis benchmark demonstrates that `explicitValue()` is much slower:
>> Benchmark                      Mode  Cnt   Score   Error  Units
>> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
>> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
>> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
>> 
>> I've tested the changes locally, both tier1 and tier 2 are ok. 
>> 
>> Could one create an issue for tracking this?
>
> The changes in src/java.desktop looks fine.

Changes to `java.logging` and `java.net.http` also look good to me.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct 23 09:59:41 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 23 Oct 2020 09:59:41 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <PG8nxD4Mf9_jJpCgRj_pRrvUuT38qRaK0CoGpcm8y4U=.9e282356-0e4b-4034-ac6b-ca5afaa69424@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <PG8nxD4Mf9_jJpCgRj_pRrvUuT38qRaK0CoGpcm8y4U=.9e282356-0e4b-4034-ac6b-ca5afaa69424@github.com>
Message-ID: <jxy-a6J40FvSQDynQJ6JCGy0jvQYXzpMPzE5jOsiCOM=.0b371e3c-1370-42be-9af2-29f43b73aef8@github.com>

On Fri, 23 Oct 2020 09:12:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @BenchmarkMode(value = Mode.AverageTime)
>> public class AtomicBenchmark {
>>   @Benchmark
>>   public Object defaultValue() {
>>     return new AtomicInteger();
>>   }
>>   @Benchmark
>>   public Object explicitValue() {
>>     return new AtomicInteger(0);
>>   }
>> }
>> THis benchmark demonstrates that `explicitValue()` is much slower:
>> Benchmark                      Mode  Cnt   Score   Error  Units
>> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
>> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
>> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
>> 
>> I've tested the changes locally, both tier1 and tier 2 are ok. 
>> 
>> Could one create an issue for tracking this?
>
> src/java.base/share/classes/sun/net/ResourceManager.java line 65:
> 
>> 63:         } catch (NumberFormatException e) {}
>> 64:         maxSockets = defmax;
>> 65:         numSockets = new AtomicInteger();
> 
> Changes in sun/net look good to me.

@dfuch Could you then sponsor this PR?

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

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

From iignatyev at openjdk.java.net  Fri Oct 23 17:29:58 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 17:29:58 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v2]
In-Reply-To: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
Message-ID: <LlkmVp0mQNeEPtyeQDm57eWvR5jvlsZqrEXsZvkA-54=.d8cc178c-4770-4b2e-9f46-5c36fca6a9e2@github.com>

> Hi all,
> 
> could you please review this small patch?
> 
> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>> 
>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>    order from the leftmost, four digits giving the year, with a range of 
>>    1000--9999, two digits giving the month of the year, with a range of 
>>    01--12, two digits giving the day of the month, with a range of 
>>    01--31, two digits giving the hour of the day, with a range of 
>>    00--23, two digits giving minutes past the hour, with a range of 
>>    00--59, and finally, two digits giving seconds past the minute, with 
>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>    considered a serious defect of the protocol. 
>> 
>>    The optional digits, which are preceded by a period, give decimal 
>>    fractions of a second. These may be given to whatever precision is 
>>    appropriate to the circumstance, however implementations MUST NOT add 
>>    precision to time-vals where that precision does not exist in the 
>>    underlying value being transmitted. 
>> 
>>    Symbolically, a time-val may be viewed as 
>> 
>>   YYYYMMDDHHMMSS.sss 
>> 
>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>    MUST NOT appear unless at least one following digit also appears. 
>> 
> 
> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
> 
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
> 
> testing:
> * [x] tier1
> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  added test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/776/files
  - new: https://git.openjdk.java.net/jdk/pull/776/files/a2867539..7a1c0505

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

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

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

From iignatyev at openjdk.java.net  Fri Oct 23 17:37:36 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 17:37:36 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format
In-Reply-To: <sEn5XfJ3l_xPHseV0wpN8hxW1USVl743V93JVQ6yWak=.aba22db6-1194-4aae-8733-48ebb0235460@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <cyxEikZZJIKevjVRkqxhEwLNRHiZXAqhLxsNNBtR4q0=.bd2354b5-0a91-4b0c-bf09-deb73dd27e40@github.com>
 <sEn5XfJ3l_xPHseV0wpN8hxW1USVl743V93JVQ6yWak=.aba22db6-1194-4aae-8733-48ebb0235460@github.com>
Message-ID: <CHkZtS8aZGMR9cpmITFF1jKRtoBkFT1Y5G-V5E_j6Sc=.0c2d130f-b47d-48a4-b85b-2c2b046e2931@github.com>

On Thu, 22 Oct 2020 16:04:56 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi Igor, is this testable - and if so shouldn't there be a test?
>> best regards,
>> -- daniel
>
>> Hi Igor, is this testable - and if so shouldn't there be a test?
>> best regards,
>> -- daniel
> 
> Hi Daniel,
> 
> it's testable and originally I planned to add a new test, however upon checking the existing mock ftp-servers, I realized that none of them support MLSx commands, and adding that support doesn't seem to be justified for such a trivial fix. With that being said, I can create a test for this if you believe it's necessary.
> 
> -- Igor

I took another stab on the test and it turned out to be easier than I originally anticipated. I, however, decided to take a safer approach and don't use FtpServer` from `test/jdk/sun/net/www/ftptest` test-library, and instead introduced a test-specific mock server in the test code. I'm running the test multiple times on `{windows,linux,macosx}-x64` to check how stable it's in our environment, so far there are no failures.

-- Igor

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

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

From iignatyev at openjdk.java.net  Fri Oct 23 17:50:51 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 17:50:51 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v3]
In-Reply-To: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
Message-ID: <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>

> Hi all,
> 
> could you please review this small patch?
> 
> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>> 
>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>    order from the leftmost, four digits giving the year, with a range of 
>>    1000--9999, two digits giving the month of the year, with a range of 
>>    01--12, two digits giving the day of the month, with a range of 
>>    01--31, two digits giving the hour of the day, with a range of 
>>    00--23, two digits giving minutes past the hour, with a range of 
>>    00--59, and finally, two digits giving seconds past the minute, with 
>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>    considered a serious defect of the protocol. 
>> 
>>    The optional digits, which are preceded by a period, give decimal 
>>    fractions of a second. These may be given to whatever precision is 
>>    appropriate to the circumstance, however implementations MUST NOT add 
>>    precision to time-vals where that precision does not exist in the 
>>    underlying value being transmitted. 
>> 
>>    Symbolically, a time-val may be viewed as 
>> 
>>   YYYYMMDDHHMMSS.sss 
>> 
>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>    MUST NOT appear unless at least one following digit also appears. 
>> 
> 
> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
> 
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
> 
> testing:
> * [x] tier1
> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  use only filename in assert message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/776/files
  - new: https://git.openjdk.java.net/jdk/pull/776/files/7a1c0505..9b69cf91

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

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

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

From dfuchs at openjdk.java.net  Fri Oct 23 18:07:41 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 18:07:41 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v3]
In-Reply-To: <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
Message-ID: <co8D2cImABhr33FV0KLf-aMi6bmCK-t_EHLtp_qNNdE=.1b782190-8e54-4166-80eb-7cd6e859a6c8@github.com>

On Fri, 23 Oct 2020 17:50:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch?
>> 
>> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>>> 
>>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>>    order from the leftmost, four digits giving the year, with a range of 
>>>    1000--9999, two digits giving the month of the year, with a range of 
>>>    01--12, two digits giving the day of the month, with a range of 
>>>    01--31, two digits giving the hour of the day, with a range of 
>>>    00--23, two digits giving minutes past the hour, with a range of 
>>>    00--59, and finally, two digits giving seconds past the minute, with 
>>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>>    considered a serious defect of the protocol. 
>>> 
>>>    The optional digits, which are preceded by a period, give decimal 
>>>    fractions of a second. These may be given to whatever precision is 
>>>    appropriate to the circumstance, however implementations MUST NOT add 
>>>    precision to time-vals where that precision does not exist in the 
>>>    underlying value being transmitted. 
>>> 
>>>    Symbolically, a time-val may be viewed as 
>>> 
>>>   YYYYMMDDHHMMSS.sss 
>>> 
>>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>>    MUST NOT appear unless at least one following digit also appears. 
>>> 
>> 
>> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
>> 
>> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
>> 
>> testing:
>> * [x] tier1
>> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use only filename in assert message

Thanks for adding a test Igor!
If that passes on all platform then this looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

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

From dfuchs at openjdk.java.net  Fri Oct 23 18:33:35 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 18:33:35 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <JbMPcYdgEa-E-congqKtykPOp2tbK5NT5cN9NwPzdKY=.92bcae3c-6514-48cb-b102-551c7a798e6f@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>
 <JbMPcYdgEa-E-congqKtykPOp2tbK5NT5cN9NwPzdKY=.92bcae3c-6514-48cb-b102-551c7a798e6f@github.com>
Message-ID: <N9NqqIta7gLw_c3VJ5vHhLnHsWRf3eD13DOqSmBdzbE=.62e9a338-5d19-45c2-bf2d-c0b106275340@github.com>

On Fri, 23 Oct 2020 09:14:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The changes in src/java.desktop looks fine.
>
> Changes to `java.logging` and `java.net.http` also look good to me.

Hi Sergey,

I'll give it some testing and sponsor it next week unless someone else steps up.

best regards,
-- daniel

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

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

From iignatyev at openjdk.java.net  Fri Oct 23 22:36:40 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 22:36:40 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v3]
In-Reply-To: <co8D2cImABhr33FV0KLf-aMi6bmCK-t_EHLtp_qNNdE=.1b782190-8e54-4166-80eb-7cd6e859a6c8@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
 <co8D2cImABhr33FV0KLf-aMi6bmCK-t_EHLtp_qNNdE=.1b782190-8e54-4166-80eb-7cd6e859a6c8@github.com>
Message-ID: <UXhpQy-OCLeCt6o1hCShnhse5d9_CGOlAIfcdulTAs4=.57b7577b-d347-4217-8e4c-df511fe96e55@github.com>

On Fri, 23 Oct 2020 18:05:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use only filename in assert message
>
> Thanks for adding a test Igor!
> If that passes on all platform then this looks good to me.

Thanks, Daniel.

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

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

From iignatyev at openjdk.java.net  Fri Oct 23 22:36:42 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 22:36:42 GMT
Subject: Integrated: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format
In-Reply-To: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
Message-ID: <_64eWZAoOmBBz_dTGK3eXUHLQfCVYmzD0hePxS0o2d8=.a3bfbbe7-cdbe-4cec-909b-b3203aef2e92@github.com>

On Tue, 20 Oct 2020 23:14:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch?
> 
> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>> 
>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>    order from the leftmost, four digits giving the year, with a range of 
>>    1000--9999, two digits giving the month of the year, with a range of 
>>    01--12, two digits giving the day of the month, with a range of 
>>    01--31, two digits giving the hour of the day, with a range of 
>>    00--23, two digits giving minutes past the hour, with a range of 
>>    00--59, and finally, two digits giving seconds past the minute, with 
>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>    considered a serious defect of the protocol. 
>> 
>>    The optional digits, which are preceded by a period, give decimal 
>>    fractions of a second. These may be given to whatever precision is 
>>    appropriate to the circumstance, however implementations MUST NOT add 
>>    precision to time-vals where that precision does not exist in the 
>>    underlying value being transmitted. 
>> 
>>    Symbolically, a time-val may be viewed as 
>> 
>>   YYYYMMDDHHMMSS.sss 
>> 
>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>    MUST NOT appear unless at least one following digit also appears. 
>> 
> 
> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
> 
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
> 
> testing:
> * [x] tier1
> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`

This pull request has now been integrated.

Changeset: 6545e19f
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6545e19f
Stats:     242 lines in 2 files changed: 211 ins; 23 del; 8 mod

8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong datetime format

Reviewed-by: dfuchs

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

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

From alanb at openjdk.java.net  Sat Oct 24 08:15:40 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 24 Oct 2020 08:15:40 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v35]
In-Reply-To: <kIVPvKsvadaUws4d8NQcpr9v6Q5qPAYzwkpyny7t8Nc=.df5cdede-e590-4ba4-94ba-c50fbe23541a@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <kIVPvKsvadaUws4d8NQcpr9v6Q5qPAYzwkpyny7t8Nc=.df5cdede-e590-4ba4-94ba-c50fbe23541a@github.com>
Message-ID: <HUHWMNtT4ei9-1FFyWXBZNTbQ9bxAnvA1PAr6O-CcKA=.4b4648ff-f5b8-404c-9db2-2d6747f07d37@github.com>

On Thu, 22 Oct 2020 08:14:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
>> 
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
>> 
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
>> 
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - fixed 32 bit Linux build error
>   - test updates from Chris

src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java line 148:

> 146:         // Disable the Nagle algorithm so that the wakeup is more immediate
> 147:         SinkChannelImpl sink = (SinkChannelImpl)wakeupPipe.sink();
> 148:         wakeupSinkFd = ((SelChImpl)sink).getFDVal();

The "Disable the ..." comment can be removed as it's handled in PipeImpl now. "sink" can be removed so that wakeupSourceFd and wakeupSinkFd can be created the same way.

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

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

From prr at openjdk.java.net  Sat Oct 24 23:14:34 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 24 Oct 2020 23:14:34 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

client changes are fine

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

Marked as reviewed by prr (Reviewer).

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

From github.com+11685886+marcono1234 at openjdk.java.net  Sun Oct 25 00:38:36 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Sun, 25 Oct 2020 00:38:36 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v3]
In-Reply-To: <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
Message-ID: <UMoOnr4flvqwo6g1F_bd6sIBoZcSZlu6qK_QFgjpaks=.39bd39df-e1ab-435c-b79a-54f408d85e99@github.com>

On Fri, 23 Oct 2020 17:50:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small patch?
>> 
>> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>>> 
>>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>>    order from the leftmost, four digits giving the year, with a range of 
>>>    1000--9999, two digits giving the month of the year, with a range of 
>>>    01--12, two digits giving the day of the month, with a range of 
>>>    01--31, two digits giving the hour of the day, with a range of 
>>>    00--23, two digits giving minutes past the hour, with a range of 
>>>    00--59, and finally, two digits giving seconds past the minute, with 
>>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>>    considered a serious defect of the protocol. 
>>> 
>>>    The optional digits, which are preceded by a period, give decimal 
>>>    fractions of a second. These may be given to whatever precision is 
>>>    appropriate to the circumstance, however implementations MUST NOT add 
>>>    precision to time-vals where that precision does not exist in the 
>>>    underlying value being transmitted. 
>>> 
>>>    Symbolically, a time-val may be viewed as 
>>> 
>>>   YYYYMMDDHHMMSS.sss 
>>> 
>>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>>    MUST NOT appear unless at least one following digit also appears. 
>>> 
>> 
>> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
>> 
>> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
>> 
>> testing:
>> * [x] tier1
>> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use only filename in assert message

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1777:

> 1775:     }
> 1776: 
> 1777:     private static Date parseRfc3659TimeValue(String s) {

Shouldn't this method be synchronized because `SimpleDateFormat` is not thread-safe, but instances are stored in the static field `dateFormats`?
(Note though that this issue existed before as well)

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

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

From iignatyev at openjdk.java.net  Mon Oct 26 14:32:11 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Oct 2020 14:32:11 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v3]
In-Reply-To: <UMoOnr4flvqwo6g1F_bd6sIBoZcSZlu6qK_QFgjpaks=.39bd39df-e1ab-435c-b79a-54f408d85e99@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
 <UMoOnr4flvqwo6g1F_bd6sIBoZcSZlu6qK_QFgjpaks=.39bd39df-e1ab-435c-b79a-54f408d85e99@github.com>
Message-ID: <lKO0YDytmOC3-By6XhY4PDl7i1wW_F4wx2ZV_ymrGS4=.08a6b19f-a521-4150-bc89-cd56bb3a2022@github.com>

On Sun, 25 Oct 2020 00:35:20 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use only filename in assert message
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1777:
> 
>> 1775:     }
>> 1776: 
>> 1777:     private static Date parseRfc3659TimeValue(String s) {
> 
> Shouldn't this method be synchronized because `SimpleDateFormat` is not thread-safe, but instances are stored in the static field `dateFormats`?
> (Note though that this issue existed before as well)

thanks @Marcono1234, it indeed needs to be `synchronized`, I'll take care of fixing that.

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

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

From iignatyev at openjdk.java.net  Mon Oct 26 16:57:28 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Oct 2020 16:57:28 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not
 thread-safe manner
Message-ID: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>

Hi all,

could you please review this small and trivial fix?

`sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.

the problem was reported in #776

Thanks,
-- Igor

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

Commit messages:
 - 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner

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

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

From Matthew.Carter at microsoft.com  Mon Oct 26 21:31:07 2020
From: Matthew.Carter at microsoft.com (Mat Carter)
Date: Mon, 26 Oct 2020 21:31:07 +0000
Subject: RFR(s): Improving performance of Windows socket connect on the
 loopback adapter
In-Reply-To: <DM6PR21MB12892CC39A74478F22396BBEF5480@DM6PR21MB1289.namprd21.prod.outlook.com>
References: <DM6PR21MB1289F08C367F3FD97D5A5A68F57F0@DM6PR21MB1289.namprd21.prod.outlook.com>
 <DM6PR21MB1289F6141787A735C09C4D26F5780@DM6PR21MB1289.namprd21.prod.outlook.com>
 <cffd95eb-2171-1421-35a5-72fbcc8493d6@oracle.com>
 <DM6PR21MB12890FA878C252F590507AB1F5790@DM6PR21MB1289.namprd21.prod.outlook.com>
 <4e7c31b3-e8c4-7bc1-341c-927fc8292a8d@oracle.com>
 <DM6PR21MB128937A0CD9EE5471B9D000AF5760@DM6PR21MB1289.namprd21.prod.outlook.com>
 <05a54b93-0475-99a3-6b86-d41173806504@oracle.com>
 <DM6PR21MB128936D2049D2957E889F7D1F5760@DM6PR21MB1289.namprd21.prod.outlook.com>
 <628cac66-4872-4821-3a29-f8c25b1666f6@oracle.com>
 <DM6PR21MB1289B32B26785183649387E8F5770@DM6PR21MB1289.namprd21.prod.outlook.com>
 <b67a3c24-92f7-9966-17e3-a04bca375d98@oracle.com>
 <DM6PR21MB12899A6C2ADDE80106566DC2F5730@DM6PR21MB1289.namprd21.prod.outlook.com>
 <7a6cfe16-e126-4ef3-d22a-bcd7c0a18b8f@oracle.com>
 <DM6PR21MB12893CAD0CFD5D9142081BCFF54A0@DM6PR21MB1289.namprd21.prod.outlook.com>
 <6d808965-7eb3-ba20-2cb0-14b33ef32fe3@oracle.com>,
 <DM6PR21MB12892CC39A74478F22396BBEF5480@DM6PR21MB1289.namprd21.prod.outlook.com>
Message-ID: <CH2PR00MB0664E75D6877167B791363C88A191@CH2PR00MB0664.namprd00.prod.outlook.com>

Nikola has opened an issue to cover the loopback address range and we're preparing a patch:

https://bugs.openjdk.java.net/browse/JDK-8255264

We've identified some unit tests to include in the patch, does gtest/runtime/test_os_windows.cpp seem the appropriate location for them?

Patch (preview):


diff --git a/src/java.base/windows/native/libnet/net_util_md.h b/src/java.base/windows/native/libnet/net_util_md.h

index b76935db3de..2f873b6295e 100644

--- a/src/java.base/windows/native/libnet/net_util_md.h

+++ b/src/java.base/windows/native/libnet/net_util_md.h

@@ -90,24 +90,30 @@ struct ipv6bind {

 /**

  * With dual socket implementation the

  * IPv4 addresseses might be mapped as IPv6.

- * The IPv4 loopback adapter address will

- * be mapped as the following IPv6 ::ffff:127.0.0.1.

+ * The IPv4 loopback adapter address ranges (127.0.0.0 through 127.255.255.255) will

+ * be mapped as the following IPv6 ::ffff:127.0.0.0 through ::ffff:127.255.255.255.

  * For example, this is done by NET_InetAddressToSockaddr.

  */

 #define IN6_IS_ADDR_V4MAPPED_LOOPBACK(x) ( \

-    (((x)->s6_words[0] == 0)      &&  \

-     ((x)->s6_words[1] == 0)      &&  \

-     ((x)->s6_words[2] == 0)      &&  \

-     ((x)->s6_words[3] == 0)      &&  \

-     ((x)->s6_words[4] == 0)      &&  \

-     ((x)->s6_words[5] == 0xFFFF) &&  \

-     ((x)->s6_words[6] == 0x007F) &&  \

-     ((x)->s6_words[7] == 0x0100))    \

+    (((x)->s6_words[0] == 0)               &&  \

+     ((x)->s6_words[1] == 0)               &&  \

+     ((x)->s6_words[2] == 0)               &&  \

+     ((x)->s6_words[3] == 0)               &&  \

+     ((x)->s6_words[4] == 0)               &&  \

+     ((x)->s6_words[5] == 0xFFFF)          &&  \

+     (((x)->s6_words[6] & 0x00FF) == 0x007F)) \

+)

+

+/**

+ * Check for IPv4 loopback adapter address ranges (127.0.0.0 through 127.255.255.255)

+ */

+#define IN4_IS_ADDR_NETLONG_LOOPBACK(l) ( \

+    ((l & 0xFF000000) == 0x7F000000) \

 )



 #define IS_LOOPBACK_ADDRESS(x) ( \

     ((x)->sa.sa_family == AF_INET) ? \

-        (ntohl((x)->sa4.sin_addr.s_addr) == INADDR_LOOPBACK) : \

+        (IN4_IS_ADDR_NETLONG_LOOPBACK(ntohl((x)->sa4.sin_addr.s_addr))) : \

         ((IN6_IS_ADDR_LOOPBACK(&(x)->sa6.sin6_addr)) || \

          (IN6_IS_ADDR_V4MAPPED_LOOPBACK(&(x)->sa6.sin6_addr))) \

 )

Cheers
Mat
________________________________
From: net-dev <net-dev-retn at openjdk.java.net> on behalf of Nikola Grcevski <Nikola.Grcevski at microsoft.com>
Sent: Thursday, August 6, 2020 7:37 AM
To: Alan Bateman <Alan.Bateman at oracle.com>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>
Subject: RE: RFR(s): Improving performance of Windows socket connect on the loopback adapter

Yes, please.

Thank you,
Nikola

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: August 6, 2020 9:49 AM
To: Nikola Grcevski <Nikola.Grcevski at microsoft.com>; net-dev at openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter

On 04/08/2020 16:36, Nikola Grcevski wrote:
> Hi Alan,
>
>> What cheap is VerifyVersionInfoW? The check is done everytime but the overhead might be in the noise. Overall it looks good to me.
> I wrote a small benchmark to measure the overhead of the version check (attached below).
>
> On my SurfaceBook 2 running Windows 10 Build 19041, the version check
> measures about ~2.2us (micro seconds) on average, when the version matches.
>
> Elapsed time 2244us. (for 1,000 iterations)
>
> On a Windows 2016 Data Center Server the version check is much smaller
> ~0.13us (micro seconds) on average, when the version doesn't match.
>
> Elapsed time 128us. (for 1,000 iterations)
>
> I think the overhead is reasonably small compared to everything else. Please let me know if it's acceptable and if we can proceed.
>
>
Okay. So do you me to sponsor this?

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

From github.com+10482586+erik1iu at openjdk.java.net  Tue Oct 27 01:59:17 2020
From: github.com+10482586+erik1iu at openjdk.java.net (Eric Liu)
Date: Tue, 27 Oct 2020 01:59:17 GMT
Subject: RFR: 8254871: Remove unnecessary string copy in NetworkInterface.c
In-Reply-To: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
References: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
Message-ID: <SVcDjd_Ve3msulHkVpmLuUN3DERXEk2n5Rc4s7cJzgs=.8b8f56fa-edca-4690-af76-9d97eb9b809f@github.com>

On Fri, 23 Oct 2020 03:18:27 GMT, Eric Liu <github.com+10482586+erik1iu at openjdk.org> wrote:

> A small improvement to avoid extra string copy.
> 
> [Tests]
> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
> No new failure found.

@kimbarrett Could you help to take look at this trivial patch?

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

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

From michaelm at openjdk.java.net  Tue Oct 27 09:54:07 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 27 Oct 2020 09:54:07 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v36]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <u1beInTLwFpvpicISPVRxCkgoKT1fiJtPf6SfQ_nIQQ=.54d49efc-1eb4-46ec-a986-ffbd3c258fad@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
> 
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
> 
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
> 
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 39 additional commits since the last revision:

 - Merge branch 'master' into unixdomainchannels
 - tidy up WindowsSelectorImpl
 - - fixed 32 bit Linux build error
   - test updates from Chris
 - Merge branch 'master' into unixdomainchannels
 - updated one error in review
 - further test update from Daniel
 - forgot to stage updated test files in last commit
 - update from Daniel's test comments
 - Merge branch 'master' into unixdomainchannels
 - final feedback from Alan
 - ... and 29 more: https://git.openjdk.java.net/jdk/compare/03955742...1a8b3043

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/c01c3c9b..1a8b3043

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=34-35

  Stats: 27022 lines in 388 files changed: 22871 ins; 2823 del; 1328 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From dfuchs at openjdk.java.net  Tue Oct 27 10:37:26 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 27 Oct 2020 10:37:26 GMT
Subject: RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong
 datetime format [v3]
In-Reply-To: <lKO0YDytmOC3-By6XhY4PDl7i1wW_F4wx2ZV_ymrGS4=.08a6b19f-a521-4150-bc89-cd56bb3a2022@github.com>
References: <QRSr3GtccjP6Q4A3J_4fpMHMgQMDiG9T_KrxAlIgFag=.db5e6c34-a875-49f8-b1d1-957a3bdfd8d5@github.com>
 <dFW_ivEnsxW-BtZzT4xT9lZz3l6zTCO0DT83_9hXI90=.f20797c2-97f4-4de2-83ab-841226a10bb0@github.com>
 <UMoOnr4flvqwo6g1F_bd6sIBoZcSZlu6qK_QFgjpaks=.39bd39df-e1ab-435c-b79a-54f408d85e99@github.com>
 <lKO0YDytmOC3-By6XhY4PDl7i1wW_F4wx2ZV_ymrGS4=.08a6b19f-a521-4150-bc89-cd56bb3a2022@github.com>
Message-ID: <4ofYVweZdvn1N8D7DzZaKTlHDU6Ojvi4EC2_k3vyDd4=.d5765aae-fce4-42e3-8a70-9204c34089f8@github.com>

On Mon, 26 Oct 2020 14:29:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1777:
>> 
>>> 1775:     }
>>> 1776: 
>>> 1777:     private static Date parseRfc3659TimeValue(String s) {
>> 
>> Shouldn't this method be synchronized because `SimpleDateFormat` is not thread-safe, but instances are stored in the static field `dateFormats`?
>> (Note though that this issue existed before as well)
>
> thanks @Marcono1234, it indeed needs to be `synchronized`, I'll take care of fixing that.

@iignatev if you decide to log a followup a better alternative might be to use [DateTimeFormatter](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/time/format/DateTimeFormatter.html)

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

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

From michaelm at openjdk.java.net  Tue Oct 27 10:57:20 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 27 Oct 2020 10:57:20 GMT
Subject: RFR: 8254871: Remove unnecessary string copy in NetworkInterface.c
In-Reply-To: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
References: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
Message-ID: <Uwf2ykfneE4J2P6-6vTpM-llwNzYaAGTN2-h_pXIgoM=.afdc2829-d429-48c6-a237-73928c4187da@github.com>

On Fri, 23 Oct 2020 03:18:27 GMT, Eric Liu <github.com+10482586+erik1iu at openjdk.org> wrote:

> A small improvement to avoid extra string copy.
> 
> [Tests]
> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
> No new failure found.

src/java.base/unix/native/libnet/NetworkInterface.c line 232:

> 230:     // if it is virtual sub interface search with parent first.
> 231:     colonP = strchr(name_utf, ':');
> 232:     size_t limit = colonP != NULL ? (size_t)(colonP - name_utf) : strlen(name_utf);

name_utf is not guaranteed to be null terminated

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

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

From michaelm at openjdk.java.net  Tue Oct 27 12:15:16 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 27 Oct 2020 12:15:16 GMT
Subject: RFR: 8254871: Remove unnecessary string copy in NetworkInterface.c
In-Reply-To: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
References: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
Message-ID: <kmqH46N6tcjWhUkFtGYS4Yt6dEU6bjDZqIdWLaq7jH8=.e469e11f-eeb9-417e-9e10-48627b3dc08c@github.com>

On Fri, 23 Oct 2020 03:18:27 GMT, Eric Liu <github.com+10482586+erik1iu at openjdk.org> wrote:

> A small improvement to avoid extra string copy.
> 
> [Tests]
> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
> No new failure found.

LGTM

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

Marked as reviewed by michaelm (Reviewer).

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

From chegar at openjdk.java.net  Tue Oct 27 12:41:20 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 27 Oct 2020 12:41:20 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner
In-Reply-To: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
Message-ID: <jpdeJ_qFMt8FRW4cfm00aWxTVi01cmiQnc0pJVl8ei0=.acd81f9a-de40-4d5e-b2d9-1e7565ed02b2@github.com>

On Mon, 26 Oct 2020 16:51:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial fix?
> 
> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
> 
> the problem was reported in #776
> 
> Thanks,
> -- Igor

I would like to review this PR. Please await my comments.

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

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

From chegar at openjdk.java.net  Tue Oct 27 12:51:20 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 27 Oct 2020 12:51:20 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner
In-Reply-To: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
Message-ID: <ZYEW7RZXS8WjKGZkoN3iFrIvxYEMPGU162SMBABezQ8=.68c2d633-83b8-400a-96db-ccf03b2bed8e@github.com>

On Mon, 26 Oct 2020 16:51:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial fix?
> 
> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
> 
> the problem was reported in #776
> 
> Thanks,
> -- Igor

@iignatev Please evaluate using DateTimeFormatter, as suggested by @dfuch in https://bugs.openjdk.java.net/browse/JDK-8255405?focusedCommentId=14376774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14376774

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

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

From iignatyev at openjdk.java.net  Tue Oct 27 18:54:30 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Oct 2020 18:54:30 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v2]
In-Reply-To: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
Message-ID: <ekSCEhPRLbJT_6aALdfAK3ovmC_gyS6iWCNG2yU-Bvk=.d3a2da4c-9e06-4b62-a846-aab5c419725e@github.com>

> Hi all,
> 
> could you please review this small and trivial fix?
> 
> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
> 
> the problem was reported in #776
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with three additional commits since the last revision:

 - remove \n from MDTM response before parsing
 - added leading 0 to the test
 - use DateTimeFormatter instead of SimpleDateFormat

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/867/files
  - new: https://git.openjdk.java.net/jdk/pull/867/files/f684a9ce..a8e6d809

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

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

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

From iignatyev at openjdk.java.net  Tue Oct 27 18:57:17 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 27 Oct 2020 18:57:17 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner
In-Reply-To: <ZYEW7RZXS8WjKGZkoN3iFrIvxYEMPGU162SMBABezQ8=.68c2d633-83b8-400a-96db-ccf03b2bed8e@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ZYEW7RZXS8WjKGZkoN3iFrIvxYEMPGU162SMBABezQ8=.68c2d633-83b8-400a-96db-ccf03b2bed8e@github.com>
Message-ID: <MWhoP8qDibza5ntGlMF9-tB0RhiXnYdf3TWgtRNLmlM=.f3d18432-044b-47eb-921b-5515bb5d7f00@github.com>

On Tue, 27 Oct 2020 12:48:58 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial fix?
>> 
>> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
>> 
>> the problem was reported in #776
>> 
>> Thanks,
>> -- Igor
>
> @iignatev Please evaluate using DateTimeFormatter, as suggested by @dfuch in https://bugs.openjdk.java.net/browse/JDK-8255405?focusedCommentId=14376774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14376774

Hi Chris,

I've actually thought about `DateTimeFormatter` when I was fixing [8255078](https://bugs.openjdk.java.net/browse/JDK-8255078) / #776, but when I noticed `MDTMformats` and decided to reuse it. anyhow, I have updated `FtpClient` to use `DateTimeFormatter` instead of `SimpleDateFormat`. testing this, I realized that the test added by 8255078 didn't really produce the strings in accordance with RFC 3659; so this PR fixes that as well.

Thanks,
-- Igor

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue Oct 27 19:51:25 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 27 Oct 2020 19:51:25 GMT
Subject: RFR: 8255477: Remove unused method URL.set(String protocol,
 String host, int port, String file, String ref)
Message-ID: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>

Hello, while working with `java.net.URL` I've found unused package-private method `URL.set(String protocol, String host, int port, String file, String ref)` which can be safely removed from JDK. Testing: tier1, tier2

Could someone crate an issue for tracking of this simple change?

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

Commit messages:
 - 8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref)

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

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

From shade at openjdk.java.net  Tue Oct 27 19:51:25 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 19:51:25 GMT
Subject: RFR: 8255477: Remove unused method URL.set(String protocol,
 String host, int port, String file, String ref)
In-Reply-To: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
References: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
Message-ID: <iGSg3gmSAZM6m2E9SvQ3GjxZtxZwXEJUOPlEWLaRf2s=.c3d4d600-ea58-4a77-8adb-299484d063a4@github.com>

On Wed, 21 Oct 2020 06:52:42 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Hello, while working with `java.net.URL` I've found unused package-private method `URL.set(String protocol, String host, int port, String file, String ref)` which can be safely removed from JDK. Testing: tier1, tier2
> 
> Could someone crate an issue for tracking of this simple change?

Submitted [here](https://bugs.openjdk.java.net/browse/JDK-8255477), please try to update the PR title to "8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref)". Also, merge from master to get the test fixes, which should make the "Testing" all green.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue Oct 27 19:51:25 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 27 Oct 2020 19:51:25 GMT
Subject: RFR: 8255477: Remove unused method URL.set(String protocol,
 String host, int port, String file, String ref)
In-Reply-To: <iGSg3gmSAZM6m2E9SvQ3GjxZtxZwXEJUOPlEWLaRf2s=.c3d4d600-ea58-4a77-8adb-299484d063a4@github.com>
References: <2ZkVK3kx5hdQrNLKvDJxot05ahST1j79q4IiI8C87ww=.b4f7d781-b1cb-4400-9a61-945462ee5182@github.com>
 <iGSg3gmSAZM6m2E9SvQ3GjxZtxZwXEJUOPlEWLaRf2s=.c3d4d600-ea58-4a77-8adb-299484d063a4@github.com>
Message-ID: <wlNSLKe-eVPyZOuVeBIuUmzdlIum9WZLzUAToKAvVtY=.17a4e983-f92f-4e7e-bfde-6b1b8b416c1b@github.com>

On Tue, 27 Oct 2020 19:26:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hello, while working with `java.net.URL` I've found unused package-private method `URL.set(String protocol, String host, int port, String file, String ref)` which can be safely removed from JDK. Testing: tier1, tier2
>> 
>> Could someone crate an issue for tracking of this simple change?
>
> Submitted [here](https://bugs.openjdk.java.net/browse/JDK-8255477), please try to update the PR title to "8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref)". Also, merge from master to get the test fixes, which should make the "Testing" all green.

@shipilev thanks for filing the issue! Done.

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

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

From github.com+10482586+erik1iu at openjdk.java.net  Wed Oct 28 02:19:18 2020
From: github.com+10482586+erik1iu at openjdk.java.net (Eric Liu)
Date: Wed, 28 Oct 2020 02:19:18 GMT
Subject: Integrated: 8254871: Remove unnecessary string copy in
 NetworkInterface.c
In-Reply-To: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
References: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
Message-ID: <Ab9mFEb8zWdbF34Wqe1hHIc6rgvSrAzs-YN627jBq9U=.b142792d-d75a-498a-931a-cc48c0765da2@github.com>

On Fri, 23 Oct 2020 03:18:27 GMT, Eric Liu <github.com+10482586+erik1iu at openjdk.org> wrote:

> A small improvement to avoid extra string copy.
> 
> [Tests]
> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
> No new failure found.

This pull request has now been integrated.

Changeset: a804c6a6
Author:    Eric Liu <eric.c.liu at arm.com>
Committer: Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a804c6a6
Stats:     8 lines in 1 file changed: 0 ins; 5 del; 3 mod

8254871: Remove unnecessary string copy in NetworkInterface.c

Reviewed-by: michaelm

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 08:44:40 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 08:44:40 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <MTBEbVthFiMpd_eUkOsvckmhTQHZRu1DoYzEGXSnFuw=.ddea4ca1-57bd-4aab-8eb7-338c4057ec23@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

?????? ??????? 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 one additional commit since the last revision:

  8255299: Drop explicit zeroing at instantiation of Atomic* objects

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/818/files
  - new: https://git.openjdk.java.net/jdk/pull/818/files/c1fb362f..7dc646d0

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

  Stats: 4576 lines in 201 files changed: 2659 ins; 1135 del; 782 mod
  Patch: https://git.openjdk.java.net/jdk/pull/818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/818/head:pull/818

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 08:44:41 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 08:44:41 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
Message-ID: <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>

On Sat, 24 Oct 2020 23:12:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? 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 one additional commit since the last revision:
>> 
>>   8255299: Drop explicit zeroing at instantiation of Atomic* objects
>
> client changes are fine

Rebased onto master to have the fix introduced in https://github.com/openjdk/jdk/pull/778

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

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

From serb at openjdk.java.net  Wed Oct 28 08:52:19 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 28 Oct 2020 08:52:19 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
 <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
Message-ID: <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>

On Wed, 28 Oct 2020 08:40:02 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> client changes are fine
>
> Rebased onto master to have the fix introduced in https://github.com/openjdk/jdk/pull/778

FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 08:59:23 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 08:59:23 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
 <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
 <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>
Message-ID: <GPDSIE9rozDaZbs_94T4zgWxvK1adDtkHjlcP_m6_w4=.33980242-74dd-4993-98e1-c7bdd932d8be@github.com>

On Wed, 28 Oct 2020 08:49:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Rebased onto master to have the fix introduced in https://github.com/openjdk/jdk/pull/778
>
> FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.

@mrserb thanks for pointing this out!

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 11:13:14 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 11:13:14 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v2]
In-Reply-To: <ekSCEhPRLbJT_6aALdfAK3ovmC_gyS6iWCNG2yU-Bvk=.d3a2da4c-9e06-4b62-a846-aab5c419725e@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ekSCEhPRLbJT_6aALdfAK3ovmC_gyS6iWCNG2yU-Bvk=.d3a2da4c-9e06-4b62-a846-aab5c419725e@github.com>
Message-ID: <CQT2kAugqZu5pOvh5UosI0-zDA1KLtHJhkJX_rC2gKE=.e9f38b11-e3b8-4bcc-9f4c-59c685eda925@github.com>

On Tue, 27 Oct 2020 18:54:30 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial fix?
>> 
>> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
>> 
>> the problem was reported in #776
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove \n from MDTM response before parsing
>  - added leading 0 to the test
>  - use DateTimeFormatter instead of SimpleDateFormat

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1770:

> 1768:         try {
> 1769:             var d = LocalDateTime.parse(s, RFC3659_DATETIME_FORMAT);
> 1770:             result = Date.from(d.atZone(ZoneOffset.systemDefault()).toInstant());

Should this be ZoneOffset.UTC rather than System default? I thought the date returned by the server were supposed to be in GMT.

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

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

From michaelm at openjdk.java.net  Wed Oct 28 11:53:54 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 28 Oct 2020 11:53:54 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v35]
In-Reply-To: <HUHWMNtT4ei9-1FFyWXBZNTbQ9bxAnvA1PAr6O-CcKA=.4b4648ff-f5b8-404c-9db2-2d6747f07d37@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <kIVPvKsvadaUws4d8NQcpr9v6Q5qPAYzwkpyny7t8Nc=.df5cdede-e590-4ba4-94ba-c50fbe23541a@github.com>
 <HUHWMNtT4ei9-1FFyWXBZNTbQ9bxAnvA1PAr6O-CcKA=.4b4648ff-f5b8-404c-9db2-2d6747f07d37@github.com>
Message-ID: <6E6u4ynp2d1wjxI3uWQt0RRFmv4W4H4dn3hF94jYdhc=.84086bf2-cc0e-4e59-8014-594bab6dd47b@github.com>

On Sat, 24 Oct 2020 08:12:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - fixed 32 bit Linux build error
>>   - test updates from Chris
>
> src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java line 148:
> 
>> 146:         // Disable the Nagle algorithm so that the wakeup is more immediate
>> 147:         SinkChannelImpl sink = (SinkChannelImpl)wakeupPipe.sink();
>> 148:         wakeupSinkFd = ((SelChImpl)sink).getFDVal();
> 
> The "Disable the ..." comment can be removed as it's handled in PipeImpl now. "sink" can be removed so that wakeupSourceFd and wakeupSinkFd can be created the same way.

Thanks, I pushed that change yesterday.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 12:14:48 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 12:14:48 GMT
Subject: Integrated: 8255299: Drop explicit zeroing at instantiation of
 Atomic* objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <s9QN2M6WRG0kn77XHHkuyPHKav_igWzLtf7eJFU6GLQ=.5e596801-b62d-4e14-b969-e82096e9ab18@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

This pull request has now been integrated.

Changeset: 3c4fc793
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3c4fc793
Stats:     19 lines in 17 files changed: 0 ins; 3 del; 16 mod

8255299: Drop explicit zeroing at instantiation of Atomic* objects

Reviewed-by: redestad, serb, prr

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 12:14:47 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 12:14:47 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <GPDSIE9rozDaZbs_94T4zgWxvK1adDtkHjlcP_m6_w4=.33980242-74dd-4993-98e1-c7bdd932d8be@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
 <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
 <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>
 <GPDSIE9rozDaZbs_94T4zgWxvK1adDtkHjlcP_m6_w4=.33980242-74dd-4993-98e1-c7bdd932d8be@github.com>
Message-ID: <T0ZlHNLTHD35aWgX_xJfvtvz0V7wJ4uaP6WZXdccnmw=.4bb65e37-dd73-44f7-81bb-49d51dc9e14c@github.com>

On Wed, 28 Oct 2020 08:56:05 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.
>
> @mrserb thanks for pointing this out!

Thanks for updating with latest master changes Sergey! My tests were all green.

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

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

From ryadav at openjdk.java.net  Wed Oct 28 12:55:50 2020
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Wed, 28 Oct 2020 12:55:50 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v2]
In-Reply-To: <CQT2kAugqZu5pOvh5UosI0-zDA1KLtHJhkJX_rC2gKE=.e9f38b11-e3b8-4bcc-9f4c-59c685eda925@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ekSCEhPRLbJT_6aALdfAK3ovmC_gyS6iWCNG2yU-Bvk=.d3a2da4c-9e06-4b62-a846-aab5c419725e@github.com>
 <CQT2kAugqZu5pOvh5UosI0-zDA1KLtHJhkJX_rC2gKE=.e9f38b11-e3b8-4bcc-9f4c-59c685eda925@github.com>
Message-ID: <fZbQGLVANfk2arx6aLtNCrGlvInrLtG3U4uFCOEqsLk=.36368bf5-f391-4552-8fbc-1e41ea690497@github.com>

On Wed, 28 Oct 2020 11:10:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - remove \n from MDTM response before parsing
>>  - added leading 0 to the test
>>  - use DateTimeFormatter instead of SimpleDateFormat
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1770:
> 
>> 1768:         try {
>> 1769:             var d = LocalDateTime.parse(s, RFC3659_DATETIME_FORMAT);
>> 1770:             result = Date.from(d.atZone(ZoneOffset.systemDefault()).toInstant());
> 
> Should this be ZoneOffset.UTC rather than System default? I thought the date returned by the server were supposed to be in GMT.

ZoneOffset.UTC should return GMT as was the case with SimpleDateFormat before the changes.

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 14:35:49 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 14:35:49 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator
In-Reply-To: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
Message-ID: <C78QgE8BaYqH6jw1qzcuEThmq35NZElUsO20KRRkI5I=.f892a47e-a8fa-4bb8-8ec8-187282132f7f@github.com>

On Thu, 22 Oct 2020 14:33:11 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpHandler`
> `com.sun.net.httpserver.HttpPrincipal`
> `com.sun.net.httpserver.HttpContext`
> `com.sun.net.httpserver.HttpsConfigurator` 
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Changes requested by dfuchs (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 57:

> 55:      * and realm are equal to this object's username and realm. Returns {@code false}
> 56:      * otherwise.
> 57:      *

Isn't this missing an @param for `another` ?

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 78:

> 76:     public String getName() {
> 77:         return username;
> 78:     }

Can you log a follow-up bug about this? It seems that the implementation just returns `username`, not `realm:username`.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 100:

> 98:     /**
> 99:      * Returns a hashcode for this {@code HttpPrincipal}. This is calculated
> 100:      * as <code>(getUsername()+getRealm().hashCode()</code>.

There is a close parenthesis missing after `getRealm()`

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 14:47:45 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 14:47:45 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator
In-Reply-To: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
Message-ID: <t2EVJevamgKzR7k2DkdHS8JSH8xntK5MSn3YEfSPHNI=.a9d9743b-b946-4610-8521-93104df21b75@github.com>

On Thu, 22 Oct 2020 14:33:11 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpHandler`
> `com.sun.net.httpserver.HttpPrincipal`
> `com.sun.net.httpserver.HttpContext`
> `com.sun.net.httpserver.HttpsConfigurator` 
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Changes requested by dfuchs (Reviewer).

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 14:47:47 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 14:47:47 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator
In-Reply-To: <C78QgE8BaYqH6jw1qzcuEThmq35NZElUsO20KRRkI5I=.f892a47e-a8fa-4bb8-8ec8-187282132f7f@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <C78QgE8BaYqH6jw1qzcuEThmq35NZElUsO20KRRkI5I=.f892a47e-a8fa-4bb8-8ec8-187282132f7f@github.com>
Message-ID: <_Hmog9TIpBqwVn1joirF5MG4ycNi6izjp6pCxF5RaHs=.d6a1d140-3dcd-4211-9c57-728d402397ae@github.com>

On Wed, 28 Oct 2020 14:31:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpHandler`
>> `com.sun.net.httpserver.HttpPrincipal`
>> `com.sun.net.httpserver.HttpContext`
>> `com.sun.net.httpserver.HttpsConfigurator` 
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 100:
> 
>> 98:     /**
>> 99:      * Returns a hashcode for this {@code HttpPrincipal}. This is calculated
>> 100:      * as <code>(getUsername()+getRealm().hashCode()</code>.
> 
> There is a close parenthesis missing after `getRealm()`

Also `<code></code>` could be replaced with `{@code }`

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

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

From iignatyev at openjdk.java.net  Wed Oct 28 15:25:06 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Oct 2020 15:25:06 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v3]
In-Reply-To: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
Message-ID: <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>

> Hi all,
> 
> could you please review this small and trivial fix?
> 
> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
> 
> the problem was reported in #776
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:

 - use UTC TZ for RFC3659_DATETIME_FORMAT
 - run TestFtpTimeValue with different user.timezone

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/867/files
  - new: https://git.openjdk.java.net/jdk/pull/867/files/a8e6d809..322e04f3

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

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

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

From chegar at openjdk.java.net  Wed Oct 28 17:11:57 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Oct 2020 17:11:57 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v3]
In-Reply-To: <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
Message-ID: <xcyPkDklGPqJxoWDu1jx4bQiad6wnJab2fwGs2ZCwd0=.c6248c41-3797-4141-8f7b-e53e5d31bd5e@github.com>

On Wed, 28 Oct 2020 15:25:06 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial fix?
>> 
>> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
>> 
>> the problem was reported in #776
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use UTC TZ for RFC3659_DATETIME_FORMAT
>  - run TestFtpTimeValue with different user.timezone

Marked as reviewed by chegar (Reviewer).

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

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

From ryadav at openjdk.java.net  Wed Oct 28 17:11:58 2020
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Wed, 28 Oct 2020 17:11:58 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v3]
In-Reply-To: <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
Message-ID: <svAHXISNjybsFG3KPUhDcgO3VPRpCuYPcfMOEteCXZE=.6d31cfe2-130b-41cf-ae43-7327497996c3@github.com>

On Wed, 28 Oct 2020 15:25:06 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial fix?
>> 
>> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
>> 
>> the problem was reported in #776
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use UTC TZ for RFC3659_DATETIME_FORMAT
>  - run TestFtpTimeValue with different user.timezone

Marked as reviewed by ryadav (Committer).

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

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

From ryadav at openjdk.java.net  Wed Oct 28 17:11:58 2020
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Wed, 28 Oct 2020 17:11:58 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v3]
In-Reply-To: <xcyPkDklGPqJxoWDu1jx4bQiad6wnJab2fwGs2ZCwd0=.c6248c41-3797-4141-8f7b-e53e5d31bd5e@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
 <xcyPkDklGPqJxoWDu1jx4bQiad6wnJab2fwGs2ZCwd0=.c6248c41-3797-4141-8f7b-e53e5d31bd5e@github.com>
Message-ID: <SBFcGTWuH2td4P2hWw6_MX7TaJM6pRwUAaGAQAaf4f0=.6490dac2-281c-49db-848f-e1f8efd510fc@github.com>

On Wed, 28 Oct 2020 17:07:04 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - use UTC TZ for RFC3659_DATETIME_FORMAT
>>  - run TestFtpTimeValue with different user.timezone
>
> Marked as reviewed by chegar (Reviewer).

LGTM!

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

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

From msheppar at openjdk.java.net  Wed Oct 28 17:12:45 2020
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Wed, 28 Oct 2020 17:12:45 GMT
Subject: RFR: 8254871: Remove unnecessary string copy in NetworkInterface.c
In-Reply-To: <kmqH46N6tcjWhUkFtGYS4Yt6dEU6bjDZqIdWLaq7jH8=.e469e11f-eeb9-417e-9e10-48627b3dc08c@github.com>
References: <4rQBIS4QJBkljc6pKNc0zIFQ4YdjE0jmb2eIFFuzZJw=.055d328a-6bb4-4aea-91b6-371020c43df6@github.com>
 <kmqH46N6tcjWhUkFtGYS4Yt6dEU6bjDZqIdWLaq7jH8=.e469e11f-eeb9-417e-9e10-48627b3dc08c@github.com>
Message-ID: <sBOO4i24o6wPl2-I7pVqcALdZJZhKb-n694YON6yunk=.ab290b25-8a10-4dc9-a7e0-53480528a0b0@github.com>

On Tue, 27 Oct 2020 12:12:47 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> A small improvement to avoid extra string copy.
>> 
>> [Tests]
>> Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1.
>> No new failure found.
>
> LGTM

In the original the copy would appear to be a way of enforcing that the supplied name is not greater than the max IF name size (IFNAMSIZ), 
so in the updated version if limit >= IFNAMSIZ is there any point in performing the search? As it is unlikely to match a returned interface name ?

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

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

From michaelm at openjdk.java.net  Wed Oct 28 17:29:53 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 28 Oct 2020 17:29:53 GMT
Subject: Integrated: 8245194: Unix domain socket channel implementation
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <O4GUFaWnWsCxZKjSIzxzgAVOBkQKH77KyEZuIGys_rs=.b425eda8-9fea-4a8a-9527-86b716cce03c@github.com>

On Mon, 7 Sep 2020 12:05:07 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more iterations before integrating.
> 
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So, I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a number points that require clarification to fully understand how this will work with relative, directly relative and drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That would leave WindowsPath unchanged.
> 
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to be useful by other components.
> 
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main issue is that class is that it means we end up with two classes with static factory methods doing the same thing). 
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

This pull request has now been integrated.

Changeset: 6bb7e45e
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6bb7e45e
Stats:     6187 lines in 74 files changed: 5040 ins; 722 del; 425 mod

8245194: Unix domain socket channel implementation

Reviewed-by: erikj, dfuchs, alanb, chegar

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 18:09:46 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 18:09:46 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v3]
In-Reply-To: <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
Message-ID: <8J1Wef8w5YNiZ4DAfNpqD32lG_4lE7sG-sQIX2k7asY=.a7a4dba4-f736-41c3-a3f1-b49ee00ac98f@github.com>

On Wed, 28 Oct 2020 15:25:06 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial fix?
>> 
>> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
>> 
>> the problem was reported in #776
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use UTC TZ for RFC3659_DATETIME_FORMAT
>  - run TestFtpTimeValue with different user.timezone

Marked as reviewed by dfuchs (Reviewer).

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

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

From michaelm at openjdk.java.net  Wed Oct 28 18:54:52 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 28 Oct 2020 18:54:52 GMT
Subject: RFR: 8255555: Bad copyright headers in SocketChannelCompare.java
 SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java
Message-ID: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>

?nnelConnectionSetup.java UnixSocketChannelReadWrite.java

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

Commit messages:
 - 8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java

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

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

From dfuchs at openjdk.java.net  Wed Oct 28 19:04:49 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 19:04:49 GMT
Subject: RFR: 8255555: Bad copyright headers in SocketChannelCompare.java
 SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java
In-Reply-To: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>
References: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>
Message-ID: <OqkP8087u3bvo86C3CWzcWJ06RfgO1pOH3fF649wASo=.f739d6ec-0ff8-430f-8fb0-fec7674929ab@github.com>

On Wed, 28 Oct 2020 18:48:51 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> ?nnelConnectionSetup.java UnixSocketChannelReadWrite.java

Marked as reviewed by dfuchs (Reviewer).

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

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

From bpb at openjdk.java.net  Wed Oct 28 19:04:50 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 28 Oct 2020 19:04:50 GMT
Subject: RFR: 8255555: Bad copyright headers in SocketChannelCompare.java
 SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java
In-Reply-To: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>
References: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>
Message-ID: <L7bZc2MED2i-blSBhFolllDZopuM5eUNUtFO6mubbJ0=.4bab8cea-55b0-486e-a600-027c1a396ddd@github.com>

On Wed, 28 Oct 2020 18:48:51 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> ?nnelConnectionSetup.java UnixSocketChannelReadWrite.java

Marked as reviewed by bpb (Reviewer).

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

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

From michaelm at openjdk.java.net  Wed Oct 28 19:04:51 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 28 Oct 2020 19:04:51 GMT
Subject: Integrated: 8255555: Bad copyright headers in
 SocketChannelCompare.java SocketChannelConnectionSetup.java
 UnixSocketChannelReadWrite.java
In-Reply-To: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>
References: <pq5L0rEH0CqJXKivuwPvsd49yTnQy1FENseWUtYVvvY=.a376b40a-7416-4b57-a557-df4d83a02dee@github.com>
Message-ID: <HQIGZR346VFuODGXB9qmd0a_NdInEjdwvPeoU1ZtSNc=.0f6a467e-cb5d-4c87-9bc7-1ed493eb021c@github.com>

On Wed, 28 Oct 2020 18:48:51 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> ?nnelConnectionSetup.java UnixSocketChannelReadWrite.java

This pull request has now been integrated.

Changeset: 3f20612e
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f20612e
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8255555: Bad copyright headers in SocketChannelCompare.java SocketChannelConnectionSetup.java UnixSocketChannelReadWrite.java

Reviewed-by: dfuchs, bpb

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

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

From iignatyev at openjdk.java.net  Wed Oct 28 23:57:47 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Oct 2020 23:57:47 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v3]
In-Reply-To: <8J1Wef8w5YNiZ4DAfNpqD32lG_4lE7sG-sQIX2k7asY=.a7a4dba4-f736-41c3-a3f1-b49ee00ac98f@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ZJ3htcG463VI8SDoBDo3SVzhK0okn1E65krVmlTjouU=.cdfbc6c7-4c07-4b0a-95a4-06299f3b8cd1@github.com>
 <8J1Wef8w5YNiZ4DAfNpqD32lG_4lE7sG-sQIX2k7asY=.a7a4dba4-f736-41c3-a3f1-b49ee00ac98f@github.com>
Message-ID: <KbnGIpnsNhDeTI2mfSZMl0nvkbvDAEOw4v0uBfm-z9E=.e5c1a613-100c-44ee-b2f1-8fd2a62fb5bc@github.com>

On Wed, 28 Oct 2020 18:07:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - use UTC TZ for RFC3659_DATETIME_FORMAT
>>  - run TestFtpTimeValue with different user.timezone
>
> Marked as reviewed by dfuchs (Reviewer).

Daniel, Rahul, Chris, thank you for your reviews!

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

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

From iignatyev at openjdk.java.net  Wed Oct 28 23:57:49 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Oct 2020 23:57:49 GMT
Subject: RFR: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in
 not thread-safe manner [v2]
In-Reply-To: <fZbQGLVANfk2arx6aLtNCrGlvInrLtG3U4uFCOEqsLk=.36368bf5-f391-4552-8fbc-1e41ea690497@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
 <ekSCEhPRLbJT_6aALdfAK3ovmC_gyS6iWCNG2yU-Bvk=.d3a2da4c-9e06-4b62-a846-aab5c419725e@github.com>
 <CQT2kAugqZu5pOvh5UosI0-zDA1KLtHJhkJX_rC2gKE=.e9f38b11-e3b8-4bcc-9f4c-59c685eda925@github.com>
 <fZbQGLVANfk2arx6aLtNCrGlvInrLtG3U4uFCOEqsLk=.36368bf5-f391-4552-8fbc-1e41ea690497@github.com>
Message-ID: <XdaV24dUMYAGewznTiNxbw7B2T2DDIEywy3pslSY9-U=.c2100123-be24-4a26-be8d-2bd65b18b8df@github.com>

On Wed, 28 Oct 2020 12:52:41 GMT, Rahul Yadav <ryadav at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1770:
>> 
>>> 1768:         try {
>>> 1769:             var d = LocalDateTime.parse(s, RFC3659_DATETIME_FORMAT);
>>> 1770:             result = Date.from(d.atZone(ZoneOffset.systemDefault()).toInstant());
>> 
>> Should this be ZoneOffset.UTC rather than System default? I thought the date returned by the server were supposed to be in GMT.
>
> ZoneOffset.UTC should return GMT as was the case with SimpleDateFormat before the changes.

right,  thanks for spotting that! I don't know what I was thinking when used `systemDefault` here and when was also got tricked by my own test ??

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

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

From iignatyev at openjdk.java.net  Wed Oct 28 23:57:49 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 28 Oct 2020 23:57:49 GMT
Subject: Integrated: 8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat
 in not thread-safe manner
In-Reply-To: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
References: <_s9kBGVyBScGsOd8i-QI__8O6fsZGCUx3it_c95XDD0=.8c1f3449-b215-409f-b37f-11b403839a4a@github.com>
Message-ID: <hotGSsKxP-gDrPOn_oND7MhG2fG89Uo6UDotrDKcDnY=.74d1737f-2e97-40ad-9a3a-517389f16710@github.com>

On Mon, 26 Oct 2020 16:51:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial fix?
> 
> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat` which are shared among all instances of `FtpClient`. the fact that `SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe as well. the patch makes the only usage of `dateFormats` array, `parseRfc3659TimeValue` method, `synchronized`.
> 
> the problem was reported in #776
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 7e305ad1
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e305ad1
Stats:     37 lines in 2 files changed: 4 ins; 16 del; 17 mod

8255405: sun/net/ftp/imp/FtpClient uses SimpleDateFormat in not thread-safe manner

Reviewed-by: chegar, ryadav, dfuchs

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

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

From thomas.fox at seitenbau.com  Thu Oct 29 05:51:56 2020
From: thomas.fox at seitenbau.com (Thomas Fox)
Date: Thu, 29 Oct 2020 06:51:56 +0100 (CET)
Subject: Contract of the javax.net.ssl.X509KeyManager.chooseClientAlias method
Message-ID: <1837609034.806146.1603950716490.JavaMail.zimbra@seitenbau.com>

Hello,

I have a question regarding the contract of the method javax.net.ssl.X509KeyManager.chooseClientAlias(String[] keyType, Principal[] issuers, Socket socket). This method gets called by SSL code on a client when a SSL connection is opened to a server, the server requests client authentication and the client wants to choose which one of the available keys is used for the authentication. 
The question is whether the SSL code should pass all possible key types in the argument keyType, or should it pass only one (probably the favoured key type???) in the argument keyType?
The javadoc of the argument says "keyType - the key algorithm type name(s), ordered with the most-preferred key type first.", which leaves a little room to interpretation (is it "all allowed key algorithm type name(s)" or "a subset of all allowed key algorithm type name(s)"?)

Background is that the argument keyType passed by the SSL code is different between (A) openjdk 8u272 TLSv1.2 on the one hand and (B) openjdk 8u272 TLSv1.1, openjdk 8u265 TLSv1.1 and openjdk 8u265 TLSv1.2 on the other hand. In the former case (A), ["EC"] is passed as keyType, whereas in the latter case (B), ["RSA", "DSA", "EC"] is passed as key type, with no other changes except from JDK and TLS version. The question is if the behavior (A) is a bug (see [1]), because it does not contain the key types "RSA" and "DSA".

One implementation (Apache HttpClient 4.5.13 org.apache.http.conn.ssl.SSLContextBuilder.KeyManagerDelegate, [2]) uses the passed key types to find matching keys (it iterates over the passed key types and asks a delegate KeyManger for aliases for that key type). In case (1) this strategy fails if the keystore only contains a RSA key because RSA keys are never queried, although the RSA key can be used to authenticate to the server.
If (A) were correct, how could the implementation guess that it can also return a RSA key?

    Thanks,
	
	    Thomas

[1] https://github.com/AdoptOpenJDK/openjdk-support/issues/200
[2] https://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/conn/ssl/SSLContextBuilder.html#L221
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5461 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20201029/8f9806e2/smime.p7s>

From pconcannon at openjdk.java.net  Thu Oct 29 10:29:02 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 29 Oct 2020 10:29:02 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v2]
In-Reply-To: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
Message-ID: <zk8rBhkCojjAMjQWz9MlFu1SR0AsoAH5Rvkkn2BIgRU=.4f22bec7-49c9-46ca-a90a-a4a1a93058bf@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpHandler`
> `com.sun.net.httpserver.HttpPrincipal`
> `com.sun.net.httpserver.HttpContext`
> `com.sun.net.httpserver.HttpsConfigurator` 
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> 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 two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8253473
 - 8253473: Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/810/files
  - new: https://git.openjdk.java.net/jdk/pull/810/files/4aec796b..63633fa4

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

  Stats: 16121 lines in 564 files changed: 8952 ins; 5270 del; 1899 mod
  Patch: https://git.openjdk.java.net/jdk/pull/810.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/810/head:pull/810

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

From pconcannon at openjdk.java.net  Thu Oct 29 11:01:59 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 29 Oct 2020 11:01:59 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
Message-ID: <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpHandler`
> `com.sun.net.httpserver.HttpPrincipal`
> `com.sun.net.httpserver.HttpContext`
> `com.sun.net.httpserver.HttpsConfigurator` 
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8253473: Updated the @param for HttpPrincipal::getName; fixed @code tags

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/810/files
  - new: https://git.openjdk.java.net/jdk/pull/810/files/63633fa4..d8b93d01

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

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

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

From pconcannon at openjdk.java.net  Thu Oct 29 11:02:01 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 29 Oct 2020 11:02:01 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <C78QgE8BaYqH6jw1qzcuEThmq35NZElUsO20KRRkI5I=.f892a47e-a8fa-4bb8-8ec8-187282132f7f@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <C78QgE8BaYqH6jw1qzcuEThmq35NZElUsO20KRRkI5I=.f892a47e-a8fa-4bb8-8ec8-187282132f7f@github.com>
Message-ID: <9Vp98Sn7kKGxWWPwcFs7H4iEKx-dBExfHG6JV7vkoT8=.6e3fff0a-e347-4c04-bead-ad89775439ca@github.com>

On Wed, 28 Oct 2020 14:27:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253473: Updated the @param for HttpPrincipal::getName; fixed @code tags
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 57:
> 
>> 55:      * and realm are equal to this object's username and realm. Returns {@code false}
>> 56:      * otherwise.
>> 57:      *
> 
> Isn't this missing an @param for `another` ?

Well spotted. @param added in commit d8b93d01021d696f9f5272b1e6b34750dc36bcbf

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 78:
> 
>> 76:     public String getName() {
>> 77:         return username;
>> 78:     }
> 
> Can you log a follow-up bug about this? It seems that the implementation just returns `username`, not `realm:username`.

I've created an issue for this as requested: https://bugs.openjdk.java.net/browse/JDK-8255584

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

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

From pconcannon at openjdk.java.net  Thu Oct 29 11:02:01 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 29 Oct 2020 11:02:01 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <_Hmog9TIpBqwVn1joirF5MG4ycNi6izjp6pCxF5RaHs=.d6a1d140-3dcd-4211-9c57-728d402397ae@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <C78QgE8BaYqH6jw1qzcuEThmq35NZElUsO20KRRkI5I=.f892a47e-a8fa-4bb8-8ec8-187282132f7f@github.com>
 <_Hmog9TIpBqwVn1joirF5MG4ycNi6izjp6pCxF5RaHs=.d6a1d140-3dcd-4211-9c57-728d402397ae@github.com>
Message-ID: <PY6ssxzk2F0vwYJGUz3KgkEfK2ND7MeWO0z-Ly7epQs=.e9a275e0-b08e-47ff-a265-158b18e64fda@github.com>

On Wed, 28 Oct 2020 14:44:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 100:
>> 
>>> 98:     /**
>>> 99:      * Returns a hashcode for this {@code HttpPrincipal}. This is calculated
>>> 100:      * as <code>(getUsername()+getRealm().hashCode()</code>.
>> 
>> There is a close parenthesis missing after `getRealm()`
>
> Also `<code></code>` could be replaced with `{@code }`

Closing parenthesis added and code tag changed in commit: d8b93d01021d696f9f5272b1e6b34750dc36bcbf

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

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

From dfuchs at openjdk.java.net  Thu Oct 29 11:10:50 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Oct 2020 11:10:50 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>
Message-ID: <E9w5cA5ewQg0qXrLB27LK2_puVcFB_t7-YyenaG5fcw=.e50865e6-5d9e-48e9-8473-e12fc0584f89@github.com>

On Thu, 29 Oct 2020 11:01:59 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpHandler`
>> `com.sun.net.httpserver.HttpPrincipal`
>> `com.sun.net.httpserver.HttpContext`
>> `com.sun.net.httpserver.HttpsConfigurator` 
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253473: Updated the @param for HttpPrincipal::getName; fixed @code tags

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 58:

> 56:      * otherwise.
> 57:      *
> 58:      * @param another the object to compare this instance of {@code HttpPrincipal} against

And that might require a CSR...

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

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

From dfuchs at openjdk.java.net  Thu Oct 29 11:16:46 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Oct 2020 11:16:46 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>
Message-ID: <lSyRvfJCaHHSWsYqB_ZHJ1J4SPD16gRWQFgr5Wq03EA=.a03bb163-5273-4e7f-99bd-115f4069126f@github.com>

On Thu, 29 Oct 2020 11:01:59 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
>> 
>> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
>> 
>> `com.sun.net.httpserver.HttpHandler`
>> `com.sun.net.httpserver.HttpPrincipal`
>> `com.sun.net.httpserver.HttpContext`
>> `com.sun.net.httpserver.HttpsConfigurator` 
>> 
>> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253473: Updated the @param for HttpPrincipal::getName; fixed @code tags

Marked as reviewed by dfuchs (Reviewer).

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

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

From pconcannon at openjdk.java.net  Thu Oct 29 12:10:47 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 29 Oct 2020 12:10:47 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <E9w5cA5ewQg0qXrLB27LK2_puVcFB_t7-YyenaG5fcw=.e50865e6-5d9e-48e9-8473-e12fc0584f89@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>
 <E9w5cA5ewQg0qXrLB27LK2_puVcFB_t7-YyenaG5fcw=.e50865e6-5d9e-48e9-8473-e12fc0584f89@github.com>
Message-ID: <VbnOpOFabP0N8nSB2cJp3AmwNEN8KS1TbSbqpDpOGq8=.e43c531e-24f5-4f75-96d2-6df5b4a25a94@github.com>

On Thu, 29 Oct 2020 11:07:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8253473: Updated the @param for HttpPrincipal::getName; fixed @code tags
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 58:
> 
>> 56:      * otherwise.
>> 57:      *
>> 58:      * @param another the object to compare this instance of {@code HttpPrincipal} against
> 
> And that might require a CSR...

I've created a CSR as requested: https://bugs.openjdk.java.net/browse/JDK-8255594

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

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

From dfuchs at openjdk.java.net  Thu Oct 29 15:11:43 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 29 Oct 2020 15:11:43 GMT
Subject: RFR: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator  [v3]
In-Reply-To: <VbnOpOFabP0N8nSB2cJp3AmwNEN8KS1TbSbqpDpOGq8=.e43c531e-24f5-4f75-96d2-6df5b4a25a94@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
 <3O0dWIvOyklVxvuj-1_1L5MhGoX-h1h-EsuZww_A05U=.876089f3-c654-40a1-90f3-f0e1777c9d42@github.com>
 <E9w5cA5ewQg0qXrLB27LK2_puVcFB_t7-YyenaG5fcw=.e50865e6-5d9e-48e9-8473-e12fc0584f89@github.com>
 <VbnOpOFabP0N8nSB2cJp3AmwNEN8KS1TbSbqpDpOGq8=.e43c531e-24f5-4f75-96d2-6df5b4a25a94@github.com>
Message-ID: <2KWchpn7a9ZMvnZyIlYxsoz8Rk3n_p_LLw08kBYxMF0=.1565312d-243c-4603-9578-527b265ad49d@github.com>

On Thu, 29 Oct 2020 12:07:59 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 58:
>> 
>>> 56:      * otherwise.
>>> 57:      *
>>> 58:      * @param another the object to compare this instance of {@code HttpPrincipal} against
>> 
>> And that might require a CSR...
>
> I've created a CSR as requested: https://bugs.openjdk.java.net/browse/JDK-8255594

CSR Reviewed.

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

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

From pconcannon at openjdk.java.net  Fri Oct 30 08:44:48 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 30 Oct 2020 08:44:48 GMT
Subject: Integrated: 8253473: Javadoc clean up in HttpHandler, HttpPrincipal,
 HttpContext, and HttpsConfigurator
In-Reply-To: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
References: <O2c8ES67vzic_FsOzdCGgnzP_DZDN6KQj5zRDRlwFpE=.4beb6851-7f9d-490d-9692-3bb3062a24af@github.com>
Message-ID: <cLUCk_g724cZ8vkVn9y_vlG81Ns4aH5tvf3Gpb1LcWc=.57eba2f2-3463-480f-860f-203f25164805@github.com>

On Thu, 22 Oct 2020 14:33:11 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my doc-only fix for JDK-8253473: 'Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator ' ?
> 
> This fix is set of formatting changes intended to clean up the javadoc of the following classes :
> 
> `com.sun.net.httpserver.HttpHandler`
> `com.sun.net.httpserver.HttpPrincipal`
> `com.sun.net.httpserver.HttpContext`
> `com.sun.net.httpserver.HttpsConfigurator` 
> 
> This issue is a sub-task of [JDK-8252822](https://bugs.openjdk.java.net/browse/JDK-8252822)
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: d1281915
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d1281915
Stats:     129 lines in 4 files changed: 27 ins; 8 del; 94 mod

8253473: Javadoc clean up in HttpHandler, HttpPrincipal, HttpContext, and HttpsConfigurator

Reviewed-by: dfuchs

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

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

From pconcannon at openjdk.java.net  Fri Oct 30 14:47:02 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 30 Oct 2020 14:47:02 GMT
Subject: RFR: 8255584: `HttpPrincipal::getName` returns incorrect name
Message-ID: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>

Hi,

Could someone please review my fix for JDK-8255584: '`HttpPrincipal::getName` returns incorrect name' ?
The specification for `HttpPrincipal::getName` reports that it should return the name of the HttpPrincipal in the format "realm:username". However, it currently returns the username only.

This fix updates the method to return the name in the correct format as specified by the javadoc. 

Kind regards,
Patrick

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

Commit messages:
 - 8255584: `HttpPrincipal::getName` returns incorrect name

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

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

From dfuchs at openjdk.java.net  Fri Oct 30 15:31:55 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 30 Oct 2020 15:31:55 GMT
Subject: RFR: 8255584: `HttpPrincipal::getName` returns incorrect name
In-Reply-To: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>
References: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>
Message-ID: <WBt0urODfkvfKLDliRdd-N4m0I9xARj4Cc5g4VMX9iA=.87a88c32-3ba1-4344-9de6-fa0d9494aaeb@github.com>

On Fri, 30 Oct 2020 14:41:18 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my fix for JDK-8255584: '`HttpPrincipal::getName` returns incorrect name' ?
> The specification for `HttpPrincipal::getName` reports that it should return the name of the HttpPrincipal in the format "realm:username". However, it currently returns the username only.
> 
> This fix updates the method to return the name in the correct format as specified by the javadoc. 
> 
> Kind regards,
> Patrick

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 78:

> 76:      */
> 77:     public String getName() {
> 78:         return String.format("%s:%s", username, realm);

Isn't it the opposite you should do Patrick :-) ?
:username```

test/jdk/com/sun/net/httpserver/HttpPrincipalTest.java line 44:

> 42:         assertEquals(principal.getUsername(), "test");
> 43:         assertEquals(principal.getRealm(), "123");
> 44:         assertEquals(principal.getName(), "test:123");

should be "123:test" here.

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

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

From pconcannon at openjdk.java.net  Fri Oct 30 15:57:11 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 30 Oct 2020 15:57:11 GMT
Subject: RFR: 8255584: `HttpPrincipal::getName` returns incorrect name [v2]
In-Reply-To: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>
References: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>
Message-ID: <8NMBf-oSOdGXZpu8vODFmq7Ap0Bb3QB16RLDcqlR4iE=.c871ad08-19a6-421c-aa41-fc8b3ed86bd6@github.com>

> Hi,
> 
> Could someone please review my fix for JDK-8255584: '`HttpPrincipal::getName` returns incorrect name' ?
> The specification for `HttpPrincipal::getName` reports that it should return the name of the HttpPrincipal in the format "realm:username". However, it currently returns the username only.
> 
> This fix updates the method to return the name in the correct format as specified by the javadoc. 
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8255584: fixed ordering of realm and username in name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/958/files
  - new: https://git.openjdk.java.net/jdk/pull/958/files/fa0f7173..2ad0c8d8

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

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

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

From pconcannon at openjdk.java.net  Fri Oct 30 15:57:12 2020
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 30 Oct 2020 15:57:12 GMT
Subject: RFR: 8255584: `HttpPrincipal::getName` returns incorrect name [v2]
In-Reply-To: <WBt0urODfkvfKLDliRdd-N4m0I9xARj4Cc5g4VMX9iA=.87a88c32-3ba1-4344-9de6-fa0d9494aaeb@github.com>
References: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>
 <WBt0urODfkvfKLDliRdd-N4m0I9xARj4Cc5g4VMX9iA=.87a88c32-3ba1-4344-9de6-fa0d9494aaeb@github.com>
Message-ID: <ftsxmQRsyxSggb1e22OmzjOYwQxEyVHLYleVs-4f5lo=.5267d2c9-9e3d-44fa-8368-137b37f1b7bd@github.com>

On Fri, 30 Oct 2020 15:28:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8255584: fixed ordering of realm and username in name
>
> test/jdk/com/sun/net/httpserver/HttpPrincipalTest.java line 44:
> 
>> 42:         assertEquals(principal.getUsername(), "test");
>> 43:         assertEquals(principal.getRealm(), "123");
>> 44:         assertEquals(principal.getName(), "test:123");
> 
> should be "123:test" here.

Fixed in commit 2ad0c8d8a0d21713b6b3cdbd59306fd4d57bf4d7

> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpPrincipal.java line 78:
> 
>> 76:      */
>> 77:     public String getName() {
>> 78:         return String.format("%s:%s", username, realm);
> 
> Isn't it the opposite you should do Patrick :-) ?
> :username```

Fixed in commit 2ad0c8d8a0d21713b6b3cdbd59306fd4d57bf4d7

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

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

From dfuchs at openjdk.java.net  Fri Oct 30 16:02:58 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 30 Oct 2020 16:02:58 GMT
Subject: RFR: 8255584: `HttpPrincipal::getName` returns incorrect name [v2]
In-Reply-To: <8NMBf-oSOdGXZpu8vODFmq7Ap0Bb3QB16RLDcqlR4iE=.c871ad08-19a6-421c-aa41-fc8b3ed86bd6@github.com>
References: <7x630n1O2XticE7fQwMDIzz53jxDhFBC5XnQ9HQ1glc=.e29c8787-bb2f-4244-b7f8-0efb47bbc2b2@github.com>
 <8NMBf-oSOdGXZpu8vODFmq7Ap0Bb3QB16RLDcqlR4iE=.c871ad08-19a6-421c-aa41-fc8b3ed86bd6@github.com>
Message-ID: <itqJ6680EefgMYG5md4rphQ2lQsIZIl_YpWaRUVhiJg=.8b5ef91c-ad33-4bce-84d5-446974a8d0a3@github.com>

On Fri, 30 Oct 2020 15:57:11 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my fix for JDK-8255584: '`HttpPrincipal::getName` returns incorrect name' ?
>> The specification for `HttpPrincipal::getName` reports that it should return the name of the HttpPrincipal in the format "realm:username". However, it currently returns the username only.
>> 
>> This fix updates the method to return the name in the correct format as specified by the javadoc. 
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255584: fixed ordering of realm and username in name

Marked as reviewed by dfuchs (Reviewer).

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

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

From andersonj16 at mymail.nku.edu  Sat Oct 31 00:15:23 2020
From: andersonj16 at mymail.nku.edu (Joshua Anderson)
Date: Sat, 31 Oct 2020 00:15:23 +0000
Subject: HttpClient InputStream general advice?
Message-ID: <C05E0FF5-574B-4046-9CD0-20D832609E4A@mymail.nku.edu>

To whom it may concern,

The new HttpClient looks promising and exciting. I?m currently writing a shared Java module or driver component that will be distributed via Maven and shared among many teams within my organization.

I have a concern regarding Http clients in general and hope you can provide some comments or general advice. The driver utility I?m writing has a feature which allows an interested party to request an InputStream which transmits bytes of information over the network both small and very large (think large binary file).

It looks like this:

InputStream m = client.payload(UUID id);

The concrete implementation of the InputStream, shown in the code above, comes from the Apache HttpClient library, which is irrelevant. Just note that the bytes coming from the InputStream are originating over the network from a HttpEntity (body) provided by the Apache HttpClient library.

Good developers and aware people usually know to always close an InputStream to cleanup and free resources and avoid a memory leaks. But unfortunately not everyone does this. Currently, if users of the Shared utility I?m writing, forget the close the provided InputStream, a connection leaks which eventually exhausts  all available connections inside a pool?leaving no resources to establish new connections (different then a program using all file descriptors and is instead is a maintained connection pool in Java).

Currently, I?m wrapping the original InputStream provided by the Http Client library with my own concrete class implementation of an InputStream that essentially keeps track of them internally. If the user invokes .close() on my wrapping InputStream implementation, I remove my reference (allowing garage collection to cleanup the objects) and I propagate that .close() to the original InputStream provided by the HttpEntity, which then frees up the connection to be further utilized.

Otherwise, If a client forgets to invoke .close() on the InputStream, I have a background task that periodically reviews the list of InputStream?s I?ve noted and tracked internally and evicts them cleaning up the held connection and releasing it to be utilized further.

Here is the question:

Is this checking and reviewing necessary? Should I have written a background task that reviews all InputStream?s created by the HttpClient and calls .close() if the user forgets. The intent here is to free up these resources. Without tracking and reviewing the InputsStream objects created by the HttpClient, If the user forgets to call .close() on the InputStream objects they request, it eventually affects the stability of the core library due to the fact it cannot get new Http connections to perform other work. What?s your take?

As always,
Best regard,
Joshua

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