From duke at openjdk.java.net  Tue Mar  1 02:52:12 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 1 Mar 2022 02:52:12 GMT
Subject: Withdrawn: 8057113: (fs) Path should have a method to obtain the
 filename extension
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <DkDaqRBPgsiyGr81nyDHR6jghfrapiFXQKZuoHDbI5M=.1c857c31-6a70-4e7e-a08b-78d4a0286e44@github.com>

On Fri, 29 Jan 2021 21:13:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`.
> 
> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.)
> 
> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension.
> 
> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero.
> 
> The behavior of the proposed method for some example cases is as:
> 
> 
> .              -> 
> ..             -> 
> .a.b           -> b
> ......         -> 
> .....a         -> a
> ....a.b        -> b
> ..foo          -> foo
> test.rb        -> rb
> a/b/d/test.rb  -> rb
> .a/b/d/test.rb -> rb
> foo.           -> 
> test           -> 
> .profile       -> 
> .profile.sh    -> sh
> ..foo          -> foo
> .....foo       -> foo
> .vimrc         -> 
> test.          -> 
> test..         -> 
> test...        -> 
> foo.tar.gz     -> gz
> foo.bar.       -> 
> image.jpg      -> jpg
> music.mp3      -> mp3
> video.mp4      -> mp4
> document.txt   -> txt
> foo.tar.gz     -> gz
> foo.bar.       ->

This pull request has been closed without being integrated.

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

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

From thartmann at openjdk.java.net  Thu Mar  3 14:29:59 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Mar 2022 14:29:59 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y)
In-Reply-To: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
Message-ID: <aQd0yGzg1q_eaME-Pco89RdSznIaVa-pe5T7F5k40hQ=.b9bc94e5-226a-4c99-bed6-d4d394538a49@github.com>

On Thu, 3 Mar 2022 11:24:04 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> There are two functions that check for equality.
> void ck(long x, long y): already throws a RuntimeException if we observe inequality
> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
> 
> Instead of the recursion, I now also throw a RuntimeException.
> 
> This can currently be triggered with
> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
> 
> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
> Ran some basic tests to ensure I didn't break things.

test/hotspot/jtreg/compiler/intrinsics/unsafe/ByteBufferTest.java line 219:

> 217: 
> 218:     void ck(double x, double y) {
> 219:         if (x == x && y == y && x != y) {

What are the `x == x` and `y == y` checks good for?

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

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

From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of
 lines
Message-ID: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>

Hi

I have reviewed the code for removing double semicolons at the end of lines

all the best
matteo

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

Commit messages:
 - Removed double semicolon at the end of lines

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

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

From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi

I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
Now: what is the next step?

This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.

ciao
matteo

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

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

From jwaters at openjdk.java.net  Fri Mar  4 16:56:26 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Fri, 4 Mar 2022 16:56:26 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
Message-ID: <lG5726a2a2WsQQRwKZ-SUq00bw3xlHNvLwgcYapsIY4=.d0ad6d98-14f6-4f55-b06c-fe24dc042505@github.com>

On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> Hi
> 
> I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
> Now: what is the next step?
> 
> This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.
> 
> ciao
> matteo

Hi @matteobaccan

The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry.

Cheers,
Julian

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

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

From lancea at openjdk.java.net  Fri Mar  4 17:07:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Mar 2022 17:07:59 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <e7XmpMjRNztZjXRaLS_7w4v_zyHgRMOWuaP-uvgHc8U=.1fabaeab-3387-4056-8b46-6851ef81c0d3@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

The changes look OK.  The copyright year probably should be updated as part of this PR

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

Marked as reviewed by lancea (Reviewer).

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

From duke at openjdk.java.net  Fri Mar  4 17:14:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 17:14:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Z5IUTXYy0jJDvo942sQbkENuPE1poTsr0KXGmlNjK-8=.4b7a9484-d07e-4582-8f09-532018f06875@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi Lance

I can make a second commit updating the copyright year

Tell me if this is necessary

ciao
matteo

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

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

From rriggs at openjdk.java.net  Fri Mar  4 17:20:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 17:20:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
And corresponding tests.
This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
If you had ask ahead of time, I would have suggested finding something with more value.

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

Changes requested by rriggs (Reviewer).

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

From ihse at openjdk.java.net  Fri Mar  4 17:50:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Mar 2022 17:50:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
Message-ID: <uclpoZxrJsB8HaLQGJ4mOFL-PlE1VkzzSiFYVX9Xu74=.cf93ab56-6689-4c02-aaed-db24b78811b5@github.com>

On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
> And corresponding tests.
> This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
> If you had ask ahead of time, I would have suggested finding something with more value.

@RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. 

I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area.

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

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

From prr at openjdk.java.net  Fri Mar  4 19:10:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:10:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <flAiYSlXjGXC4cguwLIZyH5aNm_n_wHhhiUVZLnQHOw=.55037371-dfc6-481a-965a-703b845542ad@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by prr (Reviewer).

Looks like  there's only one client source code file touched
Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here.

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

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

From rriggs at openjdk.java.net  Fri Mar  4 19:33:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 19:33:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <w6EtpBynowVBiw_b5nP_UIAIXBanT3tU4iu5g8_e4gM=.24ccf09a-048f-4308-ac77-a8412eb61b71@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by rriggs (Reviewer).

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

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

From iris at openjdk.java.net  Fri Mar  4 19:43:03 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 4 Mar 2022 19:43:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MATEadXGlyHBObaz0cYBJT19VmXa5Sk_VcaOKC_AtE8=.c1394e50-8bc7-44ab-bcec-8f3701295187@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice tidy of the code.

Is there anything that can be done to prevent re-introduction of this trivial problem?  Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace?

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

Marked as reviewed by iris (Reviewer).

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

From wetmore at openjdk.java.net  Fri Mar  4 19:56:03 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 19:56:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

LGTM also.  

Similar suggestion for updating copyrights.

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

Marked as reviewed by wetmore (Reviewer).

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

From darcy at openjdk.java.net  Fri Mar  4 21:23:30 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:23:30 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to SocketException
Message-ID: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>

Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.

Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

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

Commit messages:
 - JDK-8282686: Add constructors take a cause to SocketException

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

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

From darcy at openjdk.java.net  Fri Mar  4 21:33:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:33:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Fk4CQf_wtrFu81GCs38UEX3qnk9nz3DUkP7EZT37icU=.78ef4ece-fe43-4b9a-b4c4-393e7bf741cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by darcy (Reviewer).

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

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

From dholmes at openjdk.java.net  Sat Mar  5 05:52:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 5 Mar 2022 05:52:04 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

I eyeballed the diff file and all seems okay.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From jwaters at openjdk.java.net  Sat Mar  5 06:52:13 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Sat, 5 Mar 2022 06:52:13 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice, good work matteo

Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

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

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

From duke at openjdk.java.net  Sat Mar  5 07:22:03 2022
From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=)
Date: Sat, 5 Mar 2022 07:22:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <apFWxhCWJTH2dzbDsF-uJEef-Y6uhfH0gNI48VGHYwU=.8dfe6837-793d-466f-bb16-9f7fd53798d8@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code.

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

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

From alanb at openjdk.java.net  Sat Mar  5 09:50:03 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 5 Mar 2022 09:50:03 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <whh8xzBSXj_-Fvwx9HTLhxx_9HOu6nKFtEoufQjOFTo=.900c1c38-6603-414f-ae51-30f1acbc8304@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

This looks good, I just wonder if we should add a test for the new constructors. One of them will be tested by the usages in the JDK, the cause-only constructor may not be exercised by any code.

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

Marked as reviewed by alanb (Reviewer).

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

From xuelei at openjdk.java.net  Sat Mar  5 16:16:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 5 Mar 2022 16:16:55 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <6YOD-AAXJFwPkF-qNokBEUTyQaX2BnN4MIXPnuGng-4=.b1a042d3-b548-4fd4-bacf-45aa8f4cb315@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Looks good to me.  I may file a new RFE and use this constructor in the JSSE implementation.

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

Marked as reviewed by xuelei (Reviewer).

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

From lancea at openjdk.java.net  Sat Mar  5 16:48:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 5 Mar 2022 16:48:59 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <rUDb3aB5W3eMeDOo2bRpN4CyO7yJ3oqy0aI32FI0Kf0=.f56555df-131e-4be0-a972-c2b8494a65db@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Looks fine, would be worth including a couple of tests for coverage

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

Marked as reviewed by lancea (Reviewer).

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

From dfuchs at openjdk.java.net  Mon Mar  7 10:27:58 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 10:27:58 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <l0Yr3D_QlBy1O-AbjUUcmjNNwrCJ89imHf8CaLReDcY=.68c93ed3-66eb-4d37-b091-7cc5748c367c@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Marked as reviewed by dfuchs (Reviewer).

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

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

From erikj at openjdk.java.net  Mon Mar  7 13:44:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Mar 2022 13:44:05 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
Message-ID: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>

On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

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

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

From duke at openjdk.java.net  Mon Mar  7 15:17:31 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 7 Mar 2022 15:17:31 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption
Message-ID: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>

`List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.

In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
- `MethodHandles.longestParameterList()` never returns null
- parameter types are never null
- interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
- exceptions types of method signature are never null

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

Commit messages:
 - 8282662: Use List/Set.of() factory methods to save memory

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

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

From dfuchs at openjdk.java.net  Mon Mar  7 15:29:01 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 7 Mar 2022 15:29:01 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <1oi34GhExojhpCh4STwXlzAJVSkLi4Re1qd-0koYt4g=.6b0cd860-3171-4244-9143-772493e101bd@github.com>

On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

There's also another difference: they have different serial forms. From my cursory inspection it doesn't look like the returned list are put in serializable fields but it could be good to double check it.

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

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

From duke at openjdk.java.net  Mon Mar  7 15:57:05 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 7 Mar 2022 15:57:05 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <hRRWKoMQ7n6o6o6-5eMvJa3yGZlRI77md7cH-To2RCA=.9b986f16-caa5-44da-9d87-9deb0e731fb6@github.com>

On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it?

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

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

From redestad at openjdk.java.net  Mon Mar  7 16:09:58 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 7 Mar 2022 16:09:58 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption
In-Reply-To: <hRRWKoMQ7n6o6o6-5eMvJa3yGZlRI77md7cH-To2RCA=.9b986f16-caa5-44da-9d87-9deb0e731fb6@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <hRRWKoMQ7n6o6o6-5eMvJa3yGZlRI77md7cH-To2RCA=.9b986f16-caa5-44da-9d87-9deb0e731fb6@github.com>
Message-ID: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com>

On Mon, 7 Mar 2022 15:54:02 GMT, liach <duke at openjdk.java.net> wrote:

> Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it?

A good observation. In a couple of these places we could probably use `JavaUtilCollectionAccess.listFromTrustedArray` to avoid such copies.

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

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

From jwaters at openjdk.java.net  Mon Mar  7 16:24:00 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Mon, 7 Mar 2022 16:24:00 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
 <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
Message-ID: <WUgibFurfKq3h0sqZ2YDVuSbxl-gxhmgJPnoUPWpeX4=.7af5c5e5-a326-4708-9eb9-d64f41c9af7c@github.com>

On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
> 
> They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead

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

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

From lancea at openjdk.java.net  Mon Mar  7 16:43:08 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Mar 2022 16:43:08 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

What problem are you having editing the PR header?   You should be able to do so as the author of the PR

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

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

From kcr at openjdk.java.net  Mon Mar  7 16:52:07 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:52:07 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <OlXgsLnUYvaXKuqKPGlg36JcuDUmXp8jC-8P6Y2o35k=.e68e429a-72b7-4828-9ea6-2be0165d2cdf@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> What problem are you having editing the PR header? You should be able to do so as the author of the PR

Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image:

![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png)

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

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

From kcr at openjdk.java.net  Mon Mar  7 16:56:06 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:56:06 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <ya35_llZyJFaqTkVaOv3ybkki4iCaQUTO_PPCw8XaPg=.eb0e2be9-5ed0-4be8-8a14-47f573b6dbfb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

But as the JBS title and PR title now match, this is a moot point.

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

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

From ihse at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> What problem are you having editing the PR header?   You should be able to do so as the author of the PR

@LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

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

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

From kcr at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end
 of lines
In-Reply-To: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
 <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
Message-ID: <gU_j20iocr_5kNAxvBLGmM3fgGRXQdnmguOWyMdIe4E=.d980a805-e168-4a7d-b9d9-a1a09df4b870@github.com>

On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

Ah, that explains it then.

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

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

From darcy at openjdk.java.net  Mon Mar  7 17:43:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:43:50 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException [v2]
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <me1-5SYfE-dhCm6YgsUcTsES9NXaJUdy2TS-6kq5NmA=.3da0a169-5f9e-4619-94e8-2486704287cc@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Joe Darcy 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:

 - Add regression test.
 - Merge branch 'master' into JDK-8282686
 - JDK-8282686: Add constructors take a cause to SocketException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7705/files
  - new: https://git.openjdk.java.net/jdk/pull/7705/files/e65f9ae5..978b379d

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

  Stats: 8268 lines in 175 files changed: 6072 ins; 1565 del; 631 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7705/head:pull/7705

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

From darcy at openjdk.java.net  Mon Mar  7 17:55:45 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:55:45 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException [v3]
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7705/files
  - new: https://git.openjdk.java.net/jdk/pull/7705/files/978b379d..da863692

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

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

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

From darcy at openjdk.java.net  Mon Mar  7 17:55:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Mar 2022 17:55:47 GMT
Subject: Integrated: JDK-8282686: Add constructors taking a cause to
 SocketException
In-Reply-To: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
Message-ID: <yBSi4gMu54o8DdW3MM6OvlW9f3MrUc_geP-bOnS6KO8=.9f9f94a7-8656-4238-8386-c7888042e8b5@github.com>

On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
> 
> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688

This pull request has now been integrated.

Changeset: 1faa5c80
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1faa5c8092f8baec3ca08ed059653876ec46db46
Stats:     102 lines in 7 files changed: 77 ins; 12 del; 13 mod

8282686: Add constructors taking a cause to SocketException

Reviewed-by: alanb, xuelei, lancea, dfuchs

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

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

From alanb at openjdk.java.net  Mon Mar  7 19:44:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 7 Mar 2022 19:44:13 GMT
Subject: RFR: JDK-8282686: Add constructors taking a cause to
 SocketException [v3]
In-Reply-To: <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
References: <7gwCx0UrPrBy6YUPGKj8SdYmO4w_hwcQMN6fsFyiZKw=.5443158b-18c4-43bf-8e4d-b121dd92a256@github.com>
 <7c30P1-EudPq7xvujJD2pTymD40wSWhLtKdo4Eb_ScY=.7ffbd0bb-2122-48b7-82fb-25f9fd83ba85@github.com>
Message-ID: <qNKv9RySagX0mB9oLD3tYuHa7Ja6GcDHnIVg0VKyVRU=.c97d0d0a-6498-4a0a-a4a2-b8d6da6d2dac@github.com>

On Mon, 7 Mar 2022 17:55:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review this small API enhancement to add the usual constructors taking a cause to SocketException and then update uses of initiCause on creating SocketException to instead pass the cause via the constructor.
>> 
>> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282688
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve test.

Hmm, this seems to have been integrated without any Reviewer on the final commit. How did that happen?

test/jdk/java/net/SocketException/TestSocketExceptionCtor.java line 32:

> 30: import java.util.Objects;
> 31: 
> 32: public class TestSocketExceptionCtor {

I don't think this is a good name for the test because it tests mores than the constructors. So I think drop the suffix from the name.

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

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

From duke at openjdk.java.net  Mon Mar  7 21:37:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Mon, 7 Mar 2022 21:37:05 GMT
Subject: Integrated: 8282657: Code cleanup: removing double semicolons at the
 end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <IOsP6dA-9UbtLKUQwfdQE9Z6Lc6qO2iUIy_8Ywsk4Z0=.cbc4836e-3973-4cb3-bdb6-c413368ce9f5@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This pull request has now been integrated.

Changeset: ccad3923
Author:    Matteo Baccan <matteo.baccan at gmail.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9
Stats:     93 lines in 82 files changed: 0 ins; 0 del; 93 mod

8282657: Code cleanup: removing double semicolons at the end of lines

Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes

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

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

From duke at openjdk.java.net  Tue Mar  8 12:36:58 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 8 Mar 2022 12:36:58 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption
In-Reply-To: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <hRRWKoMQ7n6o6o6-5eMvJa3yGZlRI77md7cH-To2RCA=.9b986f16-caa5-44da-9d87-9deb0e731fb6@github.com>
 <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com>
Message-ID: <Yv5cpJRo2fvuLR2xMQKkl6nkjElhhU1wh8W96pPKsCQ=.7514efc2-6203-468e-870d-5f4b585b186d@github.com>

On Mon, 7 Mar 2022 16:06:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it?

Good point, I see risky changes in this PR:
- `ProxyGenerator`
- `Proxy`
- `MethodType`
- `FileTreeIterator`

As of `ProxyGenerator.ProxyMethod` at start-up time of my Spring Boot -based application there are 2696 invocations of `ProxyGenerator.ProxyMethod.generateMethod()` and 0 of them was for `exceptionTypes.length > 2`. This is expectable as the majority of the methods declare either 0, or 1-2 exceptions.

As of `Proxy.getProxyConstructor()` in my application I have 1417 invocations of `List.of()` and 599 of them are with `intfsArray.length > 2`. There were no invocations of `Proxy.defaultMethodHandle()` so I have no statistics.

For `MethodType` there were 0 invocations, and I have no statistics, but as of my experience most of the methods have 0-2 parameters.

In case of `FileTreeIterator` incoming vararg is always of length either 0 or 1, as `FileVisitOption` enum has only one item.

So I suggest to apply something like `intfsArray.length < 2 ? List.of(intfsArray) : Arrays.asList(intfsArray)` keeping the rest of the code as is.

What do you think?

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

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

From duke at openjdk.java.net  Tue Mar  8 14:35:12 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 8 Mar 2022 14:35:12 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com>

On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

Calling `Arrays.asList` vs `List.of` on a switch on the array length seems like an overkill for such a simple thing. Imo the safest changes are where we know the input array length is going to be 1 or 2.

src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70:

> 68:         throws IOException
> 69:     {
> 70:         this.walker = new FileTreeWalker(List.of(options), maxDepth);

Relates to https://bugs.openjdk.java.net/browse/JDK-8145048

src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java line 79:

> 77:                                     containerBeforeContainee(annotations, annoClass);
> 78: 
> 79:             result.addAll((indirectFirst ? 0 : 1), List.of(indirect));

This `indirect` is most likely to be of size > 2

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

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

From bpb at openjdk.java.net  Tue Mar  8 19:48:42 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 8 Mar 2022 19:48:42 GMT
Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw
 UnixException [v7]
In-Reply-To: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <JJOANSsFrB24Zhbtp7jH0KCLBDoctgczn3kSoS7ChiE=.df26b5bd-311a-401c-8e92-ab7833714405@github.com>

> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8280881: straggling s/null/e -> null/ in one place

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7467/files
  - new: https://git.openjdk.java.net/jdk/pull/7467/files/595bd975..0bc1ffd0

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

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

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

From bpb at openjdk.java.net  Tue Mar  8 19:48:45 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 8 Mar 2022 19:48:45 GMT
Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw
 UnixException [v6]
In-Reply-To: <9huvL2cyJtQVAdlrnr--UjXLeQy-ITs5bf5e1me_uAw=.03b6e1db-7a8e-4dba-85a7-e6687f44d24f@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <ABM14oJgzK2FgmTV2chrTGSCfBAa54XnMIH0_JcwCPA=.affd4200-f249-4580-9d4b-f375ca58ab57@github.com>
 <9huvL2cyJtQVAdlrnr--UjXLeQy-ITs5bf5e1me_uAw=.03b6e1db-7a8e-4dba-85a7-e6687f44d24f@github.com>
Message-ID: <5TB86y6iBk0B0W4TVqrGGCzZo2yi4nMVyBPzGsRmGkI=.2834d40e-6291-4198-94a5-03b7afbad879@github.com>

On Sun, 27 Feb 2022 18:13:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8280881: Suppress some more exceptions; remove no longer needed close()
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 189:
> 
>> 187:                 if (sfd >= 0) {
>> 188:                     source.getFileSystem().copyNonPosixAttributes(sfd, dfd);
>> 189:                     close(sfd, null);
> 
> This should be `close(sfd, e -> null);`

Fixed in commit 0bc1ffd.

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

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

From bpb at openjdk.java.net  Tue Mar  8 20:22:48 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 8 Mar 2022 20:22:48 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v2]
In-Reply-To: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
Message-ID: <jLMFmMbxAj2ulB-kLeF8beIUxRrFogqbn-BRftJqguQ=.dba7447a-bf74-4593-a4fb-e27cb4206e21@github.com>

> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8267820: Set permissions only, not owner nor group

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7627/files
  - new: https://git.openjdk.java.net/jdk/pull/7627/files/348c8867..beaf1754

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

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

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

From bpb at openjdk.java.net  Tue Mar  8 20:22:49 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 8 Mar 2022 20:22:49 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v2]
In-Reply-To: <LQUEmJprQJ5y54rbrVZ3OLcxQqFHd0s7-nv4mrLMEMg=.48e5e40e-0267-4d9f-ba2e-d86425bcd7f5@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
 <LQUEmJprQJ5y54rbrVZ3OLcxQqFHd0s7-nv4mrLMEMg=.48e5e40e-0267-4d9f-ba2e-d86425bcd7f5@github.com>
Message-ID: <ZPCcorMnLf9np-HeSU_kUNSYJ95Flz3md_3hAs0qKEo=.1ae4611c-7b80-4e22-98cd-533be6ce00fe@github.com>

On Sun, 27 Feb 2022 18:01:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267820: Set permissions only, not owner nor group
>
> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 164:
> 
>> 162:                         dstPosixView.setOwner(srcPosixAttrs.owner());
>> 163:                         dstPosixView.setGroup(srcPosixAttrs.group());
>> 164:                     } catch (ProviderMismatchException ignore) {
> 
> I don't think setOwner/setGroup can work here.  It may be possible to obtain a UserPrincipalLookupService from the target file system and use it to lookup the string representation of the source user/group but it may not be reliable. It's also likely that these setXXX will fail when the target file is on the default file system. Maybe it would be simpler to limit the copying to just POSIX file permissions.

So changed in commit beaf175.

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

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

From lancea at openjdk.java.net  Tue Mar  8 21:00:07 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 8 Mar 2022 21:00:07 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v2]
In-Reply-To: <jLMFmMbxAj2ulB-kLeF8beIUxRrFogqbn-BRftJqguQ=.dba7447a-bf74-4593-a4fb-e27cb4206e21@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
 <jLMFmMbxAj2ulB-kLeF8beIUxRrFogqbn-BRftJqguQ=.dba7447a-bf74-4593-a4fb-e27cb4206e21@github.com>
Message-ID: <TPM1HWnQ5vnSe_lRISUr1xp3pCZ8Ha1D3rju7M5Fz4g=.3e0a7ab2-cfee-4cbb-b546-21b4ad6e2b24@github.com>

On Tue, 8 Mar 2022 20:22:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267820: Set permissions only, not owner nor group

Looks good to me

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

Marked as reviewed by lancea (Reviewer).

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

From alanb at openjdk.java.net  Wed Mar  9 08:22:10 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 9 Mar 2022 08:22:10 GMT
Subject: RFR: 8280881: (fs) UnixNativeDispatcher.close0 may throw
 UnixException [v7]
In-Reply-To: <JJOANSsFrB24Zhbtp7jH0KCLBDoctgczn3kSoS7ChiE=.df26b5bd-311a-401c-8e92-ab7833714405@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
 <JJOANSsFrB24Zhbtp7jH0KCLBDoctgczn3kSoS7ChiE=.df26b5bd-311a-401c-8e92-ab7833714405@github.com>
Message-ID: <MFrI0yOoFqeqGg40YDPg6d10EPuXs-sv5ksllkmK9rI=.f377fcd8-cd5f-456b-b095-6c0cf4707358@github.com>

On Tue, 8 Mar 2022 19:48:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280881: straggling s/null/e -> null/ in one place

Marked as reviewed by alanb (Reviewer).

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

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

From duke at openjdk.java.net  Wed Mar  9 08:35:45 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 9 Mar 2022 08:35:45 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v2]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <WdFAyr64fjT4pxqIUpMVMk5oB2qw8a6X6gsO8SO_SdI=.71b75d11-3426-4f99-945b-d4741eaa0fcd@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

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

  8282662: Revert dubious changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7729/files
  - new: https://git.openjdk.java.net/jdk/pull/7729/files/b31edfcd..5bbe8c4e

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

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

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

From alanb at openjdk.java.net  Wed Mar  9 08:40:07 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 9 Mar 2022 08:40:07 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v2]
In-Reply-To: <jLMFmMbxAj2ulB-kLeF8beIUxRrFogqbn-BRftJqguQ=.dba7447a-bf74-4593-a4fb-e27cb4206e21@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
 <jLMFmMbxAj2ulB-kLeF8beIUxRrFogqbn-BRftJqguQ=.dba7447a-bf74-4593-a4fb-e27cb4206e21@github.com>
Message-ID: <qqEHL2FoWcIZrDO-iwSBnhF9MAIOOs1NIDPQLkT80V0=.7db1a2ef-dee0-489a-adb4-f938e6e1bdc5@github.com>

On Tue, 8 Mar 2022 20:22:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267820: Set permissions only, not owner nor group

The change to CopyMoveHelper look okay. If you are doing another round of cleanup then one thing that could be improve is the naming. The parameters "source" and "target" but the variables switch to "src" and "dst" so a bit inconsistent.

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

Marked as reviewed by alanb (Reviewer).

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

From duke at openjdk.java.net  Wed Mar  9 09:02:00 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 9 Mar 2022 09:02:00 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v2]
In-Reply-To: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com>
Message-ID: <CcnD6iPShGe5Va7fXPuQgnjQz4mOXLhFulQk73EbZ_E=.44e35ff0-80fc-4439-9606-f946220d72b9@github.com>

On Tue, 8 Mar 2022 14:28:00 GMT, liach <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes
>
> src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java line 79:
> 
>> 77:                                     containerBeforeContainee(annotations, annoClass);
>> 78: 
>> 79:             result.addAll((indirectFirst ? 0 : 1), List.of(indirect));
> 
> This `indirect` is most likely to be of size > 2

I've reverted this along with the rest of dubious changes

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

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

From duke at openjdk.java.net  Wed Mar  9 09:41:05 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 9 Mar 2022 09:41:05 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v2]
In-Reply-To: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com>
Message-ID: <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com>

On Tue, 8 Mar 2022 14:27:23 GMT, liach <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes
>
> src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70:
> 
>> 68:         throws IOException
>> 69:     {
>> 70:         this.walker = new FileTreeWalker(List.of(options), maxDepth);
> 
> Relates to https://bugs.openjdk.java.net/browse/JDK-8145048

Should I keep it as is or revert along with the rest of dubious changes?

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

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

From duke at openjdk.java.net  Wed Mar  9 15:50:03 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 9 Mar 2022 15:50:03 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v2]
In-Reply-To: <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com>
 <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com>
Message-ID: <mGa8NwAv2LOiBAZDiM0XzP8yDbRj2RlYn6bU-HSAPMI=.c1f89cd2-0bc5-4000-99d3-fb287610ab10@github.com>

On Wed, 9 Mar 2022 09:37:30 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70:
>> 
>>> 68:         throws IOException
>>> 69:     {
>>> 70:         this.walker = new FileTreeWalker(List.of(options), maxDepth);
>> 
>> Relates to https://bugs.openjdk.java.net/browse/JDK-8145048
>
> Should I keep it as is or revert along with the rest of dubious changes?

probably keep it. this can be updated in the patch for that bug.

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

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

From duke at openjdk.java.net  Wed Mar  9 16:12:13 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 9 Mar 2022 16:12:13 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v2]
In-Reply-To: <WdFAyr64fjT4pxqIUpMVMk5oB2qw8a6X6gsO8SO_SdI=.71b75d11-3426-4f99-945b-d4741eaa0fcd@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <WdFAyr64fjT4pxqIUpMVMk5oB2qw8a6X6gsO8SO_SdI=.71b75d11-3426-4f99-945b-d4741eaa0fcd@github.com>
Message-ID: <ci_lIVxJalew4EMS3bgvOEe7XR4zB_Y8kUoXsiUmVXA=.64991cc1-e948-4662-af37-7b154cb2e00c@github.com>

On Wed, 9 Mar 2022 08:35:45 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert dubious changes

src/java.base/share/classes/java/lang/invoke/MethodType.java line 910:

> 908:         if (skipPos > myLen || myLen - skipPos > fullLen)
> 909:             return false;
> 910:         List<Class<?>> myList = List.of(ptypes);

imo should revert this one together with that proxy parameter one

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

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

From duke at openjdk.java.net  Thu Mar 10 08:52:17 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 10 Mar 2022 08:52:17 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v3]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

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

  8282662: Revert dubious changes in MethodType

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7729/files
  - new: https://git.openjdk.java.net/jdk/pull/7729/files/5bbe8c4e..e765c42a

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

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

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

From duke at openjdk.java.net  Thu Mar 10 08:52:19 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 10 Mar 2022 08:52:19 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v2]
In-Reply-To: <ci_lIVxJalew4EMS3bgvOEe7XR4zB_Y8kUoXsiUmVXA=.64991cc1-e948-4662-af37-7b154cb2e00c@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <WdFAyr64fjT4pxqIUpMVMk5oB2qw8a6X6gsO8SO_SdI=.71b75d11-3426-4f99-945b-d4741eaa0fcd@github.com>
 <ci_lIVxJalew4EMS3bgvOEe7XR4zB_Y8kUoXsiUmVXA=.64991cc1-e948-4662-af37-7b154cb2e00c@github.com>
Message-ID: <tClV_-I8wXl6bo15J594Mxnl4OaDx-gUXZW1p9p1ugU=.cf008dcb-e470-4257-87fa-7169587045ab@github.com>

On Wed, 9 Mar 2022 16:09:01 GMT, liach <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 910:
> 
>> 908:         if (skipPos > myLen || myLen - skipPos > fullLen)
>> 909:             return false;
>> 910:         List<Class<?>> myList = List.of(ptypes);
> 
> imo should revert this one together with that proxy parameter one

Reverted

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

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

From bpb at openjdk.java.net  Thu Mar 10 16:42:47 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 10 Mar 2022 16:42:47 GMT
Subject: Integrated: 8280881: (fs) UnixNativeDispatcher.close0 may throw
 UnixException
In-Reply-To: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
References: <QTajfcFmR-m_bFxWal0PW4g289G9L2ZI9M1A8R2EIFI=.ba6215a3-549e-4e39-b5f4-d0ae615f3c5a@github.com>
Message-ID: <cdqrIu7sphHO61lweCvUmsPXnOYCziES40hnMSw8xTg=.ae93daf3-f1e6-44bf-9be8-92f0da7d0dcd@github.com>

On Mon, 14 Feb 2022 21:21:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Re-specify `sun.nio.fs.UnixNativeDispatcher.close0()` to throw `sun.nio.fs.UnixException` and modify callers either to ignore it or to rethrow it as an `IOException`, as appropriate.

This pull request has now been integrated.

Changeset: e8a1ce00
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e8a1ce00b2981a698b4ba3e09a8b2d49d0051ccb
Stats:     71 lines in 10 files changed: 26 ins; 4 del; 41 mod

8280881: (fs) UnixNativeDispatcher.close0 may throw UnixException

Reviewed-by: alanb

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

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

From bpb at openjdk.java.net  Thu Mar 10 17:01:17 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 10 Mar 2022 17:01:17 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v3]
In-Reply-To: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
Message-ID: <n5LKQQWepoqwns_VtEvZNRaEMni6GJnMs2tOYA2PviI=.b34d2928-55e1-43bc-b38a-f9a8d5681cc8@github.com>

> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8267820: Change src to source, dst to target

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7627/files
  - new: https://git.openjdk.java.net/jdk/pull/7627/files/beaf1754..5de82f28

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

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

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

From alanb at openjdk.java.net  Thu Mar 10 17:30:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 10 Mar 2022 17:30:38 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v3]
In-Reply-To: <n5LKQQWepoqwns_VtEvZNRaEMni6GJnMs2tOYA2PviI=.b34d2928-55e1-43bc-b38a-f9a8d5681cc8@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
 <n5LKQQWepoqwns_VtEvZNRaEMni6GJnMs2tOYA2PviI=.b34d2928-55e1-43bc-b38a-f9a8d5681cc8@github.com>
Message-ID: <QOtvD7FF2WV70sxFDevW9X0oBC4O1T78gITIs_49-6w=.43853aa8-1d1f-4f73-b3d2-eb3af1efb940@github.com>

On Thu, 10 Mar 2022 17:01:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267820: Change src to source, dst to target

Marked as reviewed by alanb (Reviewer).

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

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

From lancea at openjdk.java.net  Thu Mar 10 17:40:44 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 10 Mar 2022 17:40:44 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v3]
In-Reply-To: <n5LKQQWepoqwns_VtEvZNRaEMni6GJnMs2tOYA2PviI=.b34d2928-55e1-43bc-b38a-f9a8d5681cc8@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
 <n5LKQQWepoqwns_VtEvZNRaEMni6GJnMs2tOYA2PviI=.b34d2928-55e1-43bc-b38a-f9a8d5681cc8@github.com>
Message-ID: <va73repWaV_SrXhdRwvI7H1n4rFv9EqE6yWBgM_iaH4=.d890bffe-01dc-41ff-a2c9-9986d6ebd1df@github.com>

On Thu, 10 Mar 2022 17:01:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8267820: Change src to source, dst to target

Marked as reviewed by lancea (Reviewer).

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

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

From bpb at openjdk.java.net  Thu Mar 10 17:40:45 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 10 Mar 2022 17:40:45 GMT
Subject: RFR: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system [v3]
In-Reply-To: <QOtvD7FF2WV70sxFDevW9X0oBC4O1T78gITIs_49-6w=.43853aa8-1d1f-4f73-b3d2-eb3af1efb940@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
 <n5LKQQWepoqwns_VtEvZNRaEMni6GJnMs2tOYA2PviI=.b34d2928-55e1-43bc-b38a-f9a8d5681cc8@github.com>
 <QOtvD7FF2WV70sxFDevW9X0oBC4O1T78gITIs_49-6w=.43853aa8-1d1f-4f73-b3d2-eb3af1efb940@github.com>
Message-ID: <J7CO6SBP25KN1SvuvCRE46dl2NLAGDUbcc580Ua5jG0=.16825955-c3e3-4329-8772-39d3c8bb9bc8@github.com>

On Thu, 10 Mar 2022 17:27:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8267820: Change src to source, dst to target
>
> Marked as reviewed by alanb (Reviewer).

Thanks, @AlanBateman and @LanceAndersen.

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

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

From bpb at openjdk.java.net  Thu Mar 10 17:40:45 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 10 Mar 2022 17:40:45 GMT
Subject: Integrated: 8267820: (fs) Files.copy should attempt to copy POSIX
 attributes when target file in custom file system
In-Reply-To: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
References: <nu7MGFiRvdSKIEUAfsV1BFk0htQw0-1QLs15FrGzgmE=.2312b0f3-f2ab-42bd-9d97-649b41bba252@github.com>
Message-ID: <pgr_Yapx2lIcDC6o5qlIKWCBl_GCvis-0RWr9cV6rXk=.f8d20884-0406-41c9-a220-f98d8feab27d@github.com>

On Fri, 25 Feb 2022 23:31:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `java.nio.file.Files.copy()` copy POSIX attributes even if the target is from a different file system provided both the source and target file systems support such attributes.

This pull request has now been integrated.

Changeset: fdce97df
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fdce97df5f03d9aa37d85f271d08971ec47db01d
Stats:     63 lines in 5 files changed: 36 ins; 9 del; 18 mod

8267820: (fs) Files.copy should attempt to copy POSIX attributes when target file in custom file system

Reviewed-by: lancea, alanb

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

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

From duke at openjdk.java.net  Sun Mar 13 09:07:46 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Sun, 13 Mar 2022 09:07:46 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v16]
In-Reply-To: <OXd_pMr-eW6PviQpZSnYZgts-cZYyAZGr5sb77_041Y=.f32d9b10-ac08-42f2-8195-871ac895d9ff@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <OXd_pMr-eW6PviQpZSnYZgts-cZYyAZGr5sb77_041Y=.f32d9b10-ac08-42f2-8195-871ac895d9ff@github.com>
Message-ID: <tt9czbzytSjuyB1jT3ePdZKlLfTYxE2vAPxG0PcmdBM=.58eb1ab3-2305-4dda-a8d0-e64d46338d92@github.com>

On Sat, 25 Dec 2021 16:10:37 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - separate test class for each large file test
>  - Base class only contains utilities and helpers
>  - Renamed AbstractTransferTo to TransferToBase as it is not abstract

Please keep this PR open; I will continune work on it soon.

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

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

From duke at openjdk.java.net  Sun Mar 13 09:47:50 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Sun, 13 Mar 2022 09:47:50 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
Message-ID: <1UqhJ5m2labh0jwHTw6SRuda6mF_ku_ZC50cm5k_mIU=.2de4a743-caed-4d9b-b2f7-f79d0eba1e7f@github.com>

On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Draft: Eliminated duplicate code using lambda expressions
>  - Draft: Use blocking mode also for target channel

Please keep this PR open; I will continune work on it soon.

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

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

From redestad at openjdk.java.net  Thu Mar 17 16:17:21 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Mar 2022 16:17:21 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive
Message-ID: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>

Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.

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

Commit messages:
 - Exhaustively consume ASCII bytes in String.decodeASCII

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

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

From rriggs at openjdk.java.net  Thu Mar 17 16:50:35 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 17 Mar 2022 16:50:35 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive
In-Reply-To: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
Message-ID: <XaHkrMixc32up7WVdHp5RIEdQ3KGnPbHYqhK0_gPNaE=.dfb56033-2061-41b4-9890-c7a0fb092649@github.com>

On Thu, 17 Mar 2022 16:08:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.

In the test, it might be worth a comment that the 100_000 repeats is enough to warm up the compiler and use the intrinsic.

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

Marked as reviewed by rriggs (Reviewer).

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

From dcubed at openjdk.java.net  Thu Mar 17 18:29:41 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Mar 2022 18:29:41 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive
In-Reply-To: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
Message-ID: <uqDQnXs_zjDXYfBk8NAUP2MbA1sqrhC518whK8TL97g=.c5237c92-63f7-426a-84f9-d86f30e5fd59@github.com>

On Thu, 17 Mar 2022 16:08:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.

@cl4es - are you planning to integrate your fix today?

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

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

From redestad at openjdk.java.net  Thu Mar 17 19:47:14 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Mar 2022 19:47:14 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive [v2]
In-Reply-To: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
Message-ID: <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>

> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Add comment, remove redundant Arrays.fill

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7855/files
  - new: https://git.openjdk.java.net/jdk/pull/7855/files/aa0470cf..ef9fbaa7

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

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

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

From dcubed at openjdk.java.net  Thu Mar 17 20:19:30 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Mar 2022 20:19:30 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive [v2]
In-Reply-To: <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
 <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>
Message-ID: <effqXB_342c-4ggkYaTsFIAbOM4EEvl3dhHBGf3C5j0=.5602cff1-eadb-40aa-a0a6-16029a6db1de@github.com>

On Thu, 17 Mar 2022 19:47:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment, remove redundant Arrays.fill

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

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

From rriggs at openjdk.java.net  Thu Mar 17 20:53:35 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 17 Mar 2022 20:53:35 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive [v2]
In-Reply-To: <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
 <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>
Message-ID: <83sEBnnK_z8hNvRykey_s_asBttxq0i0KpGBfMI0kMQ=.00e19da5-8e92-48ec-b5e4-8d03fc2682e5@github.com>

On Thu, 17 Mar 2022 19:47:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment, remove redundant Arrays.fill

Marked as reviewed by rriggs (Reviewer).

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

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

From redestad at openjdk.java.net  Thu Mar 17 21:20:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Mar 2022 21:20:32 GMT
Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being
 exhaustive [v2]
In-Reply-To: <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
 <LZyFgr0EQGw3hm0xrZqvnLy2-xrApxiG-h6j-EWapoo=.b268915e-93a2-4e29-b7d4-a0e0418d1a63@github.com>
Message-ID: <Uno38gRqgdW1yK6q2x6faFN6GFS9SoRZwiuVZn9-9bc=.7f4e2d75-9b02-435a-8c0f-a95771b206f5@github.com>

On Thu, 17 Mar 2022 19:47:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment, remove redundant Arrays.fill

Thanks for reviews!

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

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

From redestad at openjdk.java.net  Thu Mar 17 21:20:33 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Mar 2022 21:20:33 GMT
Subject: Integrated: 8283325: US_ASCII decoder relies on String.decodeASCII
 being exhaustive
In-Reply-To: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
References: <rAWdo5oeX7ulzkaZLSDDhoL-5871JrvhzeA2RrAwVv0=.ce6e35b1-1e5f-4813-9fa5-c7af38454274@github.com>
Message-ID: <nMHgWCCjn0bv725R0eOBPJ82ntHImZSzZ5zihruG5MM=.bbac6ae7-f04f-4322-b7e3-7338fb0c5c57@github.com>

On Thu, 17 Mar 2022 16:08:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI.

This pull request has now been integrated.

Changeset: 002e3667
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/002e3667443d94e2303c875daf72cf1ccbbb0099
Stats:     61 lines in 2 files changed: 61 ins; 0 del; 0 mod

8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive

Reviewed-by: rriggs, dcubed

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

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

From duke at openjdk.java.net  Sun Mar 20 16:54:34 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Sun, 20 Mar 2022 16:54:34 GMT
Subject: RFR: 8279339: (ch) Input/Output streams returned by Channels
 factory methods don't support concurrent read/write ops [v2]
In-Reply-To: <CksFhHtz9xPEKLSz3WWC3-RCF4XuMw008zShHtssLAs=.44b118b0-cf5a-4fbe-84d1-e7838ae401e1@github.com>
References: <RHNKerh00Vpf_qrg-6MBHq4XybOOwHkL-3XjfjdL_Ds=.878d84ad-f478-42be-ab82-c234908535a0@github.com>
 <PVsB9_pKMxXZWOvKEHgijfyn9ngITA6nDd53-x2xtM0=.9c738ced-1211-42f6-a1d4-fe3b1bf9f67f@github.com>
 <CksFhHtz9xPEKLSz3WWC3-RCF4XuMw008zShHtssLAs=.44b118b0-cf5a-4fbe-84d1-e7838ae401e1@github.com>
Message-ID: <oLybLPivB-BjLcIeAVgQZ4MaZwZ7okLwR46tzdtDxoA=.5b2988e7-0186-42db-9c89-19f7effed3fc@github.com>

On Wed, 5 Jan 2022 18:18:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This looks good.  Thank you for addressing.
>> 
>> I typically use assertThrows vs expectThrows for consistency with the other assertXXX
>
>> I typically use assertThrows vs expectThrows for consistency with the other assertXXX
> 
> I've got into the habit of using expectThrows because tests will often need to check the exception cause (assertThrows is void). I don't mind changing it as either will work for this test.

Thanks a lot @AlanBateman for fixing this longstanding issue. I am pretty sure, @trishagee is not the only one really appreciating this fix! ????

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

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

From Alan.Bateman at oracle.com  Mon Mar 21 07:18:29 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 21 Mar 2022 07:18:29 +0000
Subject: Confusing startLock.wait()/finishLock.wait() calls in
 WindowsSelectorImpl
In-Reply-To: <CAF+DQ5epb+V-=g=QihjVS+GLtGR+fVbdH8V6u+tb4OzMWwOr4Q@mail.gmail.com>
References: <CAF+DQ5epb+V-=g=QihjVS+GLtGR+fVbdH8V6u+tb4OzMWwOr4Q@mail.gmail.com>
Message-ID: <663f676e-3d30-c07f-57a3-3fa19190b7ff@oracle.com>

Moving this to nio-dev. I don't disagree that the locking is hard to 
follow but note that this Selector implementation has not been used (by 
default) for a few releases. It may eventually be deleted but we 
continue to build/include it until there is more confident in the newer 
implementation.

-Alan

On 20/03/2022 20:53, Andrey Turbanov wrote:
> Hello.
> I found confusing calls to Object.wait() in 2 methods:
> 1. sun.nio.ch.WindowsSelectorImpl.StartLock#waitForStart
> https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java#L252
> 2. sun.nio.ch.WindowsSelectorImpl.FinishLock#waitForHelperThreads
> https://github.com/openjdk/jdk/blob/4df67426ed02f18af0757897acb28b636a317a91/src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java#L304
>
> Methods 'sun.nio.ch.WindowsSelectorImpl.FinishLock#waitForHelperThreads'
> and 'sun.nio.ch.WindowsSelectorImpl.StartLock#waitForStart'
> are synchronized. It means they are synchronized on 'this'.
> But, somewhy, this methods calls to 'wait()' via reference fields in
> outer class:
>
> private synchronized boolean waitForStart(SelectThread thread) {
>     ...
>    startLock.wait();
>
> private synchronized void waitForHelperThreads() {
>     ...
>    finishLock.wait();
>
>
> It seems confusing to me. I would expect that method 'wait()' to be
> called directly on 'this' too.
> For StartLock it even allows to mark it as a 'static' nested class
> (minus one redundant field).
> Is it intentional to call 'wait()' like this?
>
>
> Andrey Turbanov


From jpai at openjdk.java.net  Mon Mar 21 11:10:33 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 21 Mar 2022 11:10:33 GMT
Subject: RFR: 8280896: java/nio/file/Files/probeContentType/Basic.java
 fails on Windows 11
In-Reply-To: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>
References: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>
Message-ID: <qzxe1jeeGb4h2WG4h3sSy9v02mWRr33LSazVr1gH6iw=.f315a333-f62d-4f0c-8555-d5af220154fb@github.com>

On Thu, 3 Feb 2022 08:22:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test fails because actual content type `application/jar` is not in allowed list of types: `application/java-archive`, `application/x-java-archive`.
> But Amazon Corretto installer set this content type to Windows registry.
> ![???????????](https://user-images.githubusercontent.com/741251/152308738-58d790ea-167a-45c7-9e08-8d619c4f316d.png)
> I propose to add this value to expected list.
> Test always fails for me. After fix, test passes.  Windows 11.

Marked as reviewed by jpai (Committer).

This change looks fine to me. You'll however need a Reviewer for this to be approved.

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

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

From mcimadamore at openjdk.java.net  Mon Mar 21 16:36:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 16:36:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
Message-ID: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>

This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.

[1] - https://openjdk.java.net/jeps/424

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

Commit messages:
 - Fix TestLayouts on 32-bits
 - Update copyright
 - Drop unused imports in Reflection.java
 - Fix writeOversized for booleans
 - Revert changes to scopedMemoryAccess.cpp
 - Add TestUpcallStack to problem list
 - Revert changes to problem list
 - Revert to previous handshake logic
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282191
  Stats: 66428 lines in 364 files changed: 44012 ins; 19911 del; 2505 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From mcimadamore at openjdk.java.net  Mon Mar 21 16:36:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 16:36:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <kryJ_fSJC-0jqPpsShAthuqgVub9flb4Oa9Z5RdBO_8=.0c380640-2e40-4566-a01f-3e22db201fd3@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Here is a list of the main changes in this iteration.

#### java.lang.foreign

The API is now a **preview** API in `java.lang.foreign`. As such to be able to use the API, users must pass the `--enable-preview` flag accordingly, to `javac` and `java`.

Since the API now lives in `java.base`, we dropped the `MemoryHandles` class and moved all its var handle combinator methods under `MethodHandles`. We have also dropped the `MemorySegment::map` factory and replaced it with a new overload in `FileChannel`, which plays much better with custom file systems.

#### ResourceScope

The `ResourceScope` abstraction has been renamed to `MemorySession`. Aside from the naming difference (which also is reflected in some of the factories associated with `MemorySession`, another difference are that `MemorySession` now implements `SegmentAllocator` and can be used straight away to allocate segments. Finally, the fact that some sessions are not closeable is now reflected in the API (see `MemorySession::isCloseable`), and a method has been added to create a non-closeable *view* of the memory session.

#### Restricted methods

Addressing the feedback we have received during incubation, the mechanism to control access to restricted methods is now more permissive. Users can still use the `--enable-native-access` flag, to get a strict, opt-in behavior, in case they want to control which modules can access restricted methods in the foreign API. But if no flag is specified, access is allowed, with a runtime warning. Supporting this required some changes in `ModuleBootstrap` so that we could record the fact that we have seen an `--enable-native-access` flag (so that all checks in `Reflection.java` becomes constant).

#### Deterministic library loading/unloading

We have enhanced the `SymbolLookup` abstraction to provide a new symbol lookup, called *library lookup*. A library lookup is a symbol lookup built around a specific native library which is loaded/unloaded using dlopen/LoadLibrary. Library lookups are associated with memory sessions, so the library can be unloaded deterministically when the session is closed.

#### Memory layouts

All memory layout constants feature the expected alignment constraints. For instance, `JAVA_CHAR` is 2 byte aligned, `JAVA_INT` is 4 byte aligned, and so on.

#### Removed functionalities

As we moved the API in `java.base` we have dropped a number of API points which did not seem to add much value, based on the feedback received:

* `SequenceLayout`s now always have a bounded size. As a result, `MemoryLayout::byteSize` no longer returns an optional. A zero-length sequence can be used instead;
*  `NativeSymbol` has been dropped. At the end of the day, its role is undistinguishable from that of a memory segment with zero-length, so API (and users) should use zero-length segments instead;
* `MemorySession::keepAlive` - has been removed; in its place we have a simple, high-order method which executes an action (a  `Runnable`) while keeping the session alive (`MemorySession::whileAlive`);
* `MemoryLayout::map` only provides limited capabilities when rewriting layouts (e.g. it can only replace one layout at a time); as such we removed this API, and we might add something better at a later point.

#### Hotspot changes

While the Panama foreign repo contains several Hotspot changes which simplify and regularize the foreign function support, these changes are not included here, as we have discovered some intermittent instability in macosx-aarch64. We might attempt to integrate the hotspot changes at a later date.

Javadoc: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/javadoc/java.base/module-summary.html
Specdiff: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/specdiff_out/overview-summary.html

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

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

From jboes at openjdk.java.net  Mon Mar 21 16:36:45 2022
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 21 Mar 2022 16:36:45 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <1c6iI0BzRJEWKr5IDBEaZfw6CyXoJw1N5G54lDjpGYc=.52e24356-0cf0-4939-8a7f-776800511b51@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600:

> 598:      * @param elementLayout the source element layout. If the byte order associated with the layout is
> 599:      * different from the native order, a byte swap operation will be performed on each array element.
> 600:      * @return a fresh short array copy of this memory segment.

Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600:

> 598:      * @param elementLayout the source element layout. If the byte order associated with the layout is
> 599:      * different from the native order, a byte swap operation will be performed on each array element.
> 600:      * @return a fresh short array copy of this memory segment.

Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods?

src/java.base/share/classes/java/lang/foreign/package-info.java line 149:

> 147:  * provided:
> 148:  *
> 149:  * {@snippet lang=java :

missing leading space in comment on line 150 and 162

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986:

> 7984:      * <p>
> 7985:      * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values
> 7986:      * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type

... are the return *types* ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986:

> 7984:      * <p>
> 7985:      * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values
> 7986:      * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type

... are the return *types* ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035:

> 8033:      * @param pos the position of the first coordinate to be inserted
> 8034:      * @param values the series of bound coordinates to insert
> 8035:      * @return an adapter var handle which inserts an additional coordinates,

... which inserts additional coordinates, ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035:

> 8033:      * @param pos the position of the first coordinate to be inserted
> 8034:      * @param values the series of bound coordinates to insert
> 8035:      * @return an adapter var handle which inserts an additional coordinates,

... which inserts additional coordinates, ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151:

> 8149:      *
> 8150:      * @param target the var handle to invoke after the dummy coordinates are dropped
> 8151:      * @param pos position of first coordinate to drop (zero for the leftmost)

... of *the* first coordinate to drop ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151:

> 8149:      *
> 8150:      * @param target the var handle to invoke after the dummy coordinates are dropped
> 8151:      * @param pos position of first coordinate to drop (zero for the leftmost)

... of *the* first coordinate to drop ...

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

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

From erikj at openjdk.java.net  Mon Mar 21 17:24:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 21 Mar 2022 17:24:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Build changes look ok.

make/modules/java.base/Lib.gmk line 217:

> 215:       CXXFLAGS := $(CXXFLAGS_JDKLIB), \
> 216:       LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \
> 217:       LIBS := $(LIBCXX) -lc -lm -ldl, \

Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this:


LDFLAGS := $(LDFLAGS_JDKLIB), \
LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \


For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build.

I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time.

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

Marked as reviewed by erikj (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon Mar 21 17:40:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 17:40:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>
Message-ID: <HAMxnSS05k2YSLK8v7yX63AkjJQ2NxoI_X1N7HAac84=.416e196d-2f82-475f-a6bc-e70a68b6672a@github.com>

On Mon, 21 Mar 2022 17:16:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> make/modules/java.base/Lib.gmk line 217:
> 
>> 215:       CXXFLAGS := $(CXXFLAGS_JDKLIB), \
>> 216:       LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \
>> 217:       LIBS := $(LIBCXX) -lc -lm -ldl, \
> 
> Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this:
> 
> 
> LDFLAGS := $(LDFLAGS_JDKLIB), \
> LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 
> 
> For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build.
> 
> I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time.

Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments.

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

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

From bpb at openjdk.java.net  Mon Mar 21 18:33:30 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 21 Mar 2022 18:33:30 GMT
Subject: RFR: 8280896: java/nio/file/Files/probeContentType/Basic.java
 fails on Windows 11
In-Reply-To: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>
References: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>
Message-ID: <NX_GN99Qs8qGYF6zE-n_P2ZjQbHfni3a9319U6sMXl8=.9441342b-95e3-48df-83e1-709f8f3ebcd1@github.com>

On Thu, 3 Feb 2022 08:22:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test fails because actual content type `application/jar` is not in allowed list of types: `application/java-archive`, `application/x-java-archive`.
> But Amazon Corretto installer set this content type to Windows registry.
> ![???????????](https://user-images.githubusercontent.com/741251/152308738-58d790ea-167a-45c7-9e08-8d619c4f316d.png)
> I propose to add this value to expected list.
> Test always fails for me. After fix, test passes.  Windows 11.

Marked as reviewed by bpb (Reviewer).

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

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

From jvernee at openjdk.java.net  Mon Mar 21 19:29:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 21 Mar 2022 19:29:31 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <wGG7_ExHc55ht1LxABCOqJgSMyiDucJoE6EvyUAe08w=.683599a8-b916-427b-84c9-783212787c1b@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

src/java.base/share/classes/java/lang/foreign/CLinker.java line 176:

> 174:      * @param symbol the address of the target function.
> 175:      * @param function the function descriptor of the target function.
> 176:      * @return a new downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

Maybe drop the "new" from this. Since we want to do caching in the future.
Suggestion:

     * @return a downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

src/java.base/share/classes/java/lang/foreign/CLinker.java line 199:

> 197:      *
> 198:      * @param function the function descriptor of the target function.
> 199:      * @return a new downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

Suggestion:

     * @return a downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

src/java.base/share/classes/java/lang/foreign/MemoryAddress.java line 159:

> 157:      * Creates a memory address from the given long value.
> 158:      * @param value the long value representing a raw address.
> 159:      * @return a new memory address instance.

Similar here. A new address is not always returned.
Suggestion:

     * @return a memory address instance.

src/java.base/share/classes/java/lang/foreign/package-info.java line 230:

> 228:  * where {@code M1}, {@code M2}, {@code ... Mn} are module names (for the unnamed module, the special value {@code ALL-UNNAMED}
> 229:  * can be used). If this option is specified, access to restricted methods is only granted to the modules listed by that
> 230:  * option. If this option is not specified, access to restricted method is enabled for all modules, but

Suggestion:

 * option. If this option is not specified, access to restricted methods is enabled for all modules, but

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 53:

> (failed to retrieve contents of file, check the PR for context)
Keeping this static import would seem more readable here, instead of prefixing everything with `AArch64Architecture.`. (especially in the ABI definition below)

src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53:

> (failed to retrieve contents of file, check the PR for context)
Same here, I think keeping the static import for this would make things more readable.

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

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

From mcimadamore at openjdk.java.net  Mon Mar 21 21:25:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 21:25:31 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <wGG7_ExHc55ht1LxABCOqJgSMyiDucJoE6EvyUAe08w=.683599a8-b916-427b-84c9-783212787c1b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <wGG7_ExHc55ht1LxABCOqJgSMyiDucJoE6EvyUAe08w=.683599a8-b916-427b-84c9-783212787c1b@github.com>
Message-ID: <P1SAqwazgRHacbsYjBP6oTIvz2eoFZcP5LrfZZBs3ik=.d6efdfe6-4010-48f9-b49c-8ec1ec9cfd20@github.com>

On Mon, 21 Mar 2022 14:17:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Same here, I think keeping the static import for this would make things more readable.

Good catch. I think the IDE did that when I moved files across; I've fixed few of these, but there's more it seems.

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

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

From mcimadamore at openjdk.java.net  Tue Mar 22 10:11:47 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 10:11:47 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v2]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <KNk_5Hl0-npZKQkVMXB3cIvod6m9Q-iqdix-W15KTlE=.5dd42f08-240c-41bd-85c6-0879e455c2fc@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments
  * Use `new` instead of `fresh`
  * Drop use of `new` where caching might be used
  * Remove unused imports
  * Add static imports to make code more succint
  * Fix other typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/8e6017dc..6bb1b5c9

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

  Stats: 83 lines in 10 files changed: 2 ins; 7 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From mcimadamore at openjdk.java.net  Tue Mar 22 14:04:07 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 14:04:07 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v3]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UFcCDGmGctywrvTPliyg8WAi2bPIoPITm9BvDUXUF-4=.fa475bef-2d39-4407-9117-8a66c21673e3@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - rename syslookup lib on Windows
 - Add missing LIBS flag
 - Simplify syslookup build changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6bb1b5c9..4b2760d3

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

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

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

From mcimadamore at openjdk.java.net  Tue Mar 22 14:04:10 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 14:04:10 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v3]
In-Reply-To: <HAMxnSS05k2YSLK8v7yX63AkjJQ2NxoI_X1N7HAac84=.416e196d-2f82-475f-a6bc-e70a68b6672a@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>
 <HAMxnSS05k2YSLK8v7yX63AkjJQ2NxoI_X1N7HAac84=.416e196d-2f82-475f-a6bc-e70a68b6672a@github.com>
Message-ID: <DYTB_0p8zXdcTCKtoDmMtAjMs_ZXRwutO0uM7HiuHMM=.858b1ebe-8175-4a38-a7b2-94172e178277@github.com>

On Mon, 21 Mar 2022 17:36:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 217:
>> 
>>> 215:       CXXFLAGS := $(CXXFLAGS_JDKLIB), \
>>> 216:       LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \
>>> 217:       LIBS := $(LIBCXX) -lc -lm -ldl, \
>> 
>> Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this:
>> 
>> 
>> LDFLAGS := $(LDFLAGS_JDKLIB), \
>> LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
>> 
>> 
>> For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build.
>> 
>> I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time.
>
> Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments.

I've fixed the makefile as you suggested - I agree the result is much simpler. I've tested the changes on mac/linux/win and everything looks good.

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

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

From erikj at openjdk.java.net  Tue Mar 22 16:58:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Mar 2022 16:58:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v3]
In-Reply-To: <UFcCDGmGctywrvTPliyg8WAi2bPIoPITm9BvDUXUF-4=.fa475bef-2d39-4407-9117-8a66c21673e3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <UFcCDGmGctywrvTPliyg8WAi2bPIoPITm9BvDUXUF-4=.fa475bef-2d39-4407-9117-8a66c21673e3@github.com>
Message-ID: <qt6-Gdr9219leCluYNBRH9vil85lRVByDFiSukY6j2w=.82fceeec-10a3-4bb1-a6a6-f8e79e62546d@github.com>

On Tue, 22 Mar 2022 14:04:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - rename syslookup lib on Windows
>  - Add missing LIBS flag
>  - Simplify syslookup build changes

make/modules/java.base/Lib.gmk line 217:

> 215:       LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 216:       LIBS := $(LIBCXX), \
> 217:       LIBS_linux := -lc -lm -ldl, \

This looks much better, thanks! Now if you could just fix the indentation of the parameters to 4 spaces, it would be perfect.

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

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

From bpb at openjdk.java.net  Tue Mar 22 17:09:53 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 22 Mar 2022 17:09:53 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
Message-ID: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>

Seal subclassed buffer classes and make non-subclassed buffer classes final.

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

Commit messages:
 - 8283417: Update java.nio buffers to use sealed classes

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

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

From rriggs at openjdk.java.net  Tue Mar 22 17:48:33 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Mar 2022 17:48:33 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
Message-ID: <pBu84nVdmz2RtYA-NQqOrZoWvIb6267ZdpJix4s3IUE=.4ef66f01-cc05-4b4b-9782-5ed70cb46d21@github.com>

On Tue, 22 Mar 2022 17:02:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Seal subclassed buffer classes and make non-subclassed buffer classes final.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From mcimadamore at openjdk.java.net  Tue Mar 22 19:07:12 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 19:07:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v4]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UuTDMAAnrUzF27WaoqLM6y5gSA_F_NT_F1bTuamncQs=.eaa56a82-b6ed-429a-bf8f-42399c2b437f@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation in Lib.gmk

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/4b2760d3..7ec71f73

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

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

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

From darcy at openjdk.java.net  Tue Mar 22 20:08:31 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 22 Mar 2022 20:08:31 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
Message-ID: <igy4jvLo1C_L1JdZjF5O5N78dS-X9KxklCwG0lzP9AY=.3bf85900-5ea8-40e4-aedf-3f9f66be5ff0@github.com>

On Tue, 22 Mar 2022 17:02:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Seal subclassed buffer classes and make non-subclassed buffer classes final.

Looks fine to me.

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

Marked as reviewed by darcy (Reviewer).

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

From erikj at openjdk.java.net  Tue Mar 22 20:46:31 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Mar 2022 20:46:31 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v4]
In-Reply-To: <UuTDMAAnrUzF27WaoqLM6y5gSA_F_NT_F1bTuamncQs=.eaa56a82-b6ed-429a-bf8f-42399c2b437f@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <UuTDMAAnrUzF27WaoqLM6y5gSA_F_NT_F1bTuamncQs=.eaa56a82-b6ed-429a-bf8f-42399c2b437f@github.com>
Message-ID: <bQ9O-zsr_QE-KUCAfi5-5uah49CJmiX3UhJTdXjePyE=.2df45bf9-e268-43b3-ae46-d157939ab231@github.com>

On Tue, 22 Mar 2022 19:07:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation in Lib.gmk

Marked as reviewed by erikj (Reviewer).

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

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

From iris at openjdk.java.net  Tue Mar 22 21:23:37 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Mar 2022 21:23:37 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
Message-ID: <euYn3PbYmDAxxW7bvEnznKQGlX6tnDLlhFqM_6ZpJbU=.ed65ccc4-7840-4b35-8bac-c52ba243cfbf@github.com>

On Tue, 22 Mar 2022 17:02:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Seal subclassed buffer classes and make non-subclassed buffer classes final.

Marked as reviewed by iris (Reviewer).

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

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

From alanb at openjdk.java.net  Wed Mar 23 13:27:27 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Mar 2022 13:27:27 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
Message-ID: <KBC8s-mRZKWb0Ej9efVMfxYFTHQ28AzDnjKFOqg34Sw=.e7521a12-5c95-4741-a6d7-a5dfcafe41a0@github.com>

On Tue, 22 Mar 2022 17:02:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Seal subclassed buffer classes and make non-subclassed buffer classes final.

This change looks okay and has no real impact as buffer classes cannot be extended from code outside of the java.nio runtime package. An advantage of making the hierarchy sealed is that it will show up in the javadoc and that might those that show up periodically asking about extending these classes.

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

Marked as reviewed by alanb (Reviewer).

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

From mcimadamore at openjdk.java.net  Wed Mar 23 14:06:56 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 23 Mar 2022 14:06:56 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop redundant javadoc statements re. handling of nulls
  (handling of nulls is specified once and for all in the package javadoc)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/7ec71f73..c9bc9a70

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

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

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

From bpb at openjdk.java.net  Wed Mar 23 15:00:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 23 Mar 2022 15:00:36 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <KBC8s-mRZKWb0Ej9efVMfxYFTHQ28AzDnjKFOqg34Sw=.e7521a12-5c95-4741-a6d7-a5dfcafe41a0@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
 <KBC8s-mRZKWb0Ej9efVMfxYFTHQ28AzDnjKFOqg34Sw=.e7521a12-5c95-4741-a6d7-a5dfcafe41a0@github.com>
Message-ID: <h8a0EsgEfgLjVtPOm2zyPaYHuahexFWgQbp1StIoI0U=.173ca8f4-0285-457e-aa89-1468c41ed3f6@github.com>

On Wed, 23 Mar 2022 13:23:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change looks okay and has no real impact as buffer classes cannot be extended from code outside of the java.nio runtime package. An advantage of making the hierarchy sealed is that it will show up in the javadoc and that might those that show up periodically asking about extending these classes.

In this case then JDK-4850330 could be closed as a duplicate.

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

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

From lancea at openjdk.java.net  Wed Mar 23 17:49:46 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 23 Mar 2022 17:49:46 GMT
Subject: RFR: 8272477 : Additional cleanup of
 test/jdk/java/nio/file/spi/SetDefaultProvider.java
Message-ID: <LDs6Cs7lfpWDwTjVhS2egsdevMACb-OtZ9Gfrofnj6I=.d992d545-0ec9-49a9-a4b6-0110946ffe96@github.com>

Hi all,

Please review this minor cleanup to test/jdk/java/nio/file/spi/SetDefaultProvider.java

Best
Lance

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

Commit messages:
 - Minor cleanup of SetDefaultProvider.java

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

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

From bpb at openjdk.java.net  Wed Mar 23 18:00:28 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 23 Mar 2022 18:00:28 GMT
Subject: RFR: 8272477 : Additional cleanup of
 test/jdk/java/nio/file/spi/SetDefaultProvider.java
In-Reply-To: <LDs6Cs7lfpWDwTjVhS2egsdevMACb-OtZ9Gfrofnj6I=.d992d545-0ec9-49a9-a4b6-0110946ffe96@github.com>
References: <LDs6Cs7lfpWDwTjVhS2egsdevMACb-OtZ9Gfrofnj6I=.d992d545-0ec9-49a9-a4b6-0110946ffe96@github.com>
Message-ID: <z3SLshM9u3s1KqZ0z_CwYh_xYKRexoAdiX5zZBz1R6U=.5e2cfa1c-9b3d-49dd-af50-554d87baaa53@github.com>

On Wed, 23 Mar 2022 17:43:49 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this minor cleanup to test/jdk/java/nio/file/spi/SetDefaultProvider.java
> 
> Best
> Lance

+1

test/jdk/java/nio/file/spi/SetDefaultProvider.java line 193:

> 191:             if (Files.exists(m)) return m.toString();
> 192:         }
> 193:         assertFalse(true);

I especially like this statement.

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

Marked as reviewed by bpb (Reviewer).

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

From aturbanov at openjdk.java.net  Wed Mar 23 19:31:32 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 23 Mar 2022 19:31:32 GMT
Subject: Integrated: 8280896: java/nio/file/Files/probeContentType/Basic.java
 fails on Windows 11
In-Reply-To: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>
References: <O4DOw_7AWeIP4yDuQwYlcGBqWfwE_TfJM9iwN30NqmQ=.00280591-1bad-4739-8c39-298002a6a7e9@github.com>
Message-ID: <uSz6joRi0GCN6oq0s9BgSB-PCPIfc_tFITWnByA4nug=.d193988b-f8be-44b8-8f30-284c17866e6a@github.com>

On Thu, 3 Feb 2022 08:22:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Test fails because actual content type `application/jar` is not in allowed list of types: `application/java-archive`, `application/x-java-archive`.
> But Amazon Corretto installer set this content type to Windows registry.
> ![???????????](https://user-images.githubusercontent.com/741251/152308738-58d790ea-167a-45c7-9e08-8d619c4f316d.png)
> I propose to add this value to expected list.
> Test always fails for me. After fix, test passes.  Windows 11.

This pull request has now been integrated.

Changeset: f9137cb7
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f9137cb7b79f86e96247e7b4bc4abb03857afe75
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8280896: java/nio/file/Files/probeContentType/Basic.java fails on Windows 11

Reviewed-by: jpai, bpb

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

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

From alanb at openjdk.java.net  Thu Mar 24 06:40:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 24 Mar 2022 06:40:48 GMT
Subject: RFR: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <h8a0EsgEfgLjVtPOm2zyPaYHuahexFWgQbp1StIoI0U=.173ca8f4-0285-457e-aa89-1468c41ed3f6@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
 <KBC8s-mRZKWb0Ej9efVMfxYFTHQ28AzDnjKFOqg34Sw=.e7521a12-5c95-4741-a6d7-a5dfcafe41a0@github.com>
 <h8a0EsgEfgLjVtPOm2zyPaYHuahexFWgQbp1StIoI0U=.173ca8f4-0285-457e-aa89-1468c41ed3f6@github.com>
Message-ID: <57LD418JhiPTDThuA9vvNulIBCfwhTEoWnKQ6XrqhYc=.1231b0ba-72ec-40be-95a2-4e24253ed952@github.com>

On Wed, 23 Mar 2022 14:57:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In this case then JDK-4850330 could be closed as a duplicate.

Yes, having it show up as sealed in the javadoc makes it clear.

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

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

From jvernee at openjdk.java.net  Thu Mar 24 13:16:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 13:16:53 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
Message-ID: <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>

On Wed, 23 Mar 2022 14:06:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop redundant javadoc statements re. handling of nulls
>   (handling of nulls is specified once and for all in the package javadoc)

Some more nits.

One potential issue with adding --enable-preview when building benchmarks (last comment of the bunch). 

Other than that, I think this looks good.

make/test/BuildMicrobenchmark.gmk line 97:

> 95:     SRC := $(MICROBENCHMARK_SRC), \
> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \

It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 61:

> 59:  *     <li>{@linkplain MemorySegment#allocateNative(long, long, MemorySession) native memory segments}, backed by off-heap memory;</li>
> 60:  *     <li>{@linkplain FileChannel#map(FileChannel.MapMode, long, long, MemorySession) mapped memory segments}, obtained by mapping
> 61:  * a file into main memory ({@code mmap}); tha contents of a mapped memory segments can be {@linkplain #force() persisted} and

Suggestion:

 * a file into main memory ({@code mmap}); the contents of a mapped memory segments can be {@linkplain #force() persisted} and

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 298:

> 296: 
> 297:     /**
> 298:      * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address

Saw a similar change in other places, so I'll suggest this here as well.
Suggestion:

     * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 311:

> 309: 
> 310:     /**
> 311:      * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address

Suggestion:

     * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 143:

> 141: 
> 142:     /**
> 143:      * {@return the owner thread associated with this memory session (if any)}

Maybe the "if any" here could be more specific. e.g. saying that `null` is returned if the session doesn't have an owner thread.

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 165:

> 163: 
> 164:     /**
> 165:      * Closes this memory session. As a side effect, if this operation completes without exceptions, this session

I'd suggest change this to "As a result of this", since the effects listed are the main reason for closing a session. (it strikes me as strange. If the things listed are side-effects, then what is the main effect of closing a segment?)
Suggestion:

     * Closes this memory session. As a result of this, if this operation completes without exceptions, this session

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 51:

> 49:  * <p>
> 50:  * Clients can obtain a {@linkplain #loaderLookup() loader lookup},
> 51:  * which can be used to search symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)},

"search symbols" sounds a bit unnatural to me... I like the wording in the libraryLookup doc more
Suggestion:

 * which can be used to find symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)},

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 59:

> 57:  * <p>
> 58:  * Finally, clients can load a library and obtain a {@linkplain #libraryLookup(Path, MemorySession) library lookup} which can be used
> 59:  * to search symbols in that library. A library lookup is associated with a {@linkplain  MemorySession memory session},

Suggestion:

 * to find symbols in that library. A library lookup is associated with a {@linkplain  MemorySession memory session},

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7895:

> 7893:      *     VarHandle handle = MethodHandles.memorySegmentViewVarHandle(ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN)); //(MemorySegment, long) -> int
> 7894:      *     handle = MethodHandles.insertCoordinates(handle, 1, 4); //(MemorySegment) -> int
> 7895:      * }</pre></blockquote>

These could be snippets.

Also, I think it would be nice to add a link to MemoryLayout.varHandle here.

src/java.base/share/classes/java/nio/channels/FileChannel.java line 975:

> 973:     /**
> 974:      * Maps a region of this channel's file into a new mapped memory segment,
> 975:      * with a given offset, size and memory session.

Suggestion:

     * with the given offset, size and memory session.

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 51:

> 49: 
> 50:     /* A fallback lookup, used when creation of system lookup fails. */
> 51:     private static final Function<String, Optional<MemorySegment>> fallbackLookup = name -> Optional.empty();

Now that we have SymbolLookup again, these Function types could potentially be changed to SymbolLookup again. (and also avoid some churn here)

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:

> 133:     }
> 134: 
> 135:     public Optional<MemorySegment> lookup(String name) {

`@Override` here?

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

> 1069:         sessionImpl.checkValidStateSlow();
> 1070:         if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0.");
> 1071:         if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0.");

The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing?

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

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

From bpb at openjdk.java.net  Thu Mar 24 16:15:45 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Mar 2022 16:15:45 GMT
Subject: Integrated: 8283417: Update java.nio buffers to use sealed classes
In-Reply-To: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
References: <CdsymdjNqwtb5bLeKs2v-jGRxNbcaeCJQIj5xLCUrbM=.3656f025-5ede-4289-851e-92ea7e1a0d7e@github.com>
Message-ID: <gF5ZVra8ImtcjqVGfQLIRlJwZVTWYy2oNZXpHSSOjiA=.bf8090a0-f084-4663-b9b9-d0ce08dc57d0@github.com>

On Tue, 22 Mar 2022 17:02:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Seal subclassed buffer classes and make non-subclassed buffer classes final.

This pull request has now been integrated.

Changeset: b36cf35a
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b36cf35ad938f9bab7cbb9752c0b15c49bd50407
Stats:     45 lines in 7 files changed: 37 ins; 0 del; 8 mod

8283417: Update java.nio buffers to use sealed classes

Reviewed-by: rriggs, darcy, iris, alanb

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 17:57:16 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 17:57:16 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v6]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UlF0pUMIRsWi9nKnoi4uxDWW1LYqj5VIsFU5PG797ms=.80afd075-e9fc-42e1-aa35-6b792ab5d1f2@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/c9bc9a70..95f65eea

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

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 17:57:19 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 17:57:19 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
Message-ID: <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>

On Thu, 24 Mar 2022 13:10:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop redundant javadoc statements re. handling of nulls
>>   (handling of nulls is specified once and for all in the package javadoc)
>
> make/test/BuildMicrobenchmark.gmk line 97:
> 
>> 95:     SRC := $(MICROBENCHMARK_SRC), \
>> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \
> 
> It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version.

Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well.

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 18:19:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:19:09 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v7]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <Dk4tijedl7MZ4TwIOY4TojoGpkUB53aRHaQ3WYvTWTY=.2446002d-771d-4eda-8798-104f828b883e@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/95f65eea..3e8cfd74

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

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 18:19:12 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:19:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
Message-ID: <BF7C3WgLSzE3-OI4ffG0ThctsxSZmDGOuSyRxdO_8L8=.53a9f38d-08d8-4a69-9182-f7a240444b14@github.com>

On Thu, 24 Mar 2022 13:00:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop redundant javadoc statements re. handling of nulls
>>   (handling of nulls is specified once and for all in the package javadoc)
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071:
> 
>> 1069:         sessionImpl.checkValidStateSlow();
>> 1070:         if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0.");
>> 1071:         if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0.");
> 
> The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing?

`mapInternal` in FileChannelImpl takes care of that for both flavors of `map`

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

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

From jvernee at openjdk.java.net  Thu Mar 24 18:38:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 18:38:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
 <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
Message-ID: <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>

On Thu, 24 Mar 2022 17:48:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> make/test/BuildMicrobenchmark.gmk line 97:
>> 
>>> 95:     SRC := $(MICROBENCHMARK_SRC), \
>>> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
>>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \
>> 
>> It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version.
>
> Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well.

I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick:


diff --git a/make/RunTests.gmk b/make/RunTests.gmk
index 81540266ec0..9ed45fb02a8 100644
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -583,7 +583,7 @@ define SetupRunMicroTestBody
   $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS))

   # Current tests needs to open java.io
-  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED
+  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview

   # Save output as JSON or CSV file
   ifneq ($$(MICRO_RESULTS_FORMAT), )


People manually running the benchmarks.jar will have to pass `--enable-preview` still though.

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

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

From lancea at openjdk.java.net  Thu Mar 24 18:40:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 24 Mar 2022 18:40:47 GMT
Subject: Integrated: 8272477 : Additional cleanup of
 test/jdk/java/nio/file/spi/SetDefaultProvider.java
In-Reply-To: <LDs6Cs7lfpWDwTjVhS2egsdevMACb-OtZ9Gfrofnj6I=.d992d545-0ec9-49a9-a4b6-0110946ffe96@github.com>
References: <LDs6Cs7lfpWDwTjVhS2egsdevMACb-OtZ9Gfrofnj6I=.d992d545-0ec9-49a9-a4b6-0110946ffe96@github.com>
Message-ID: <r_sOnn-oBdhJjlp195KWjyCKk_-hFV-fOBmVpUHWJJ4=.21632086-e1ce-4733-9bca-0930c4df9ae1@github.com>

On Wed, 23 Mar 2022 17:43:49 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this minor cleanup to test/jdk/java/nio/file/spi/SetDefaultProvider.java
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: 90750dec
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90750decb47772420eaf127b19efa9b5cdacccfe
Stats:     13 lines in 1 file changed: 0 ins; 1 del; 12 mod

8272477: Additional cleanup of test/jdk/java/nio/file/spi/SetDefaultProvider.java

Reviewed-by: bpb

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 18:59:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:59:11 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v8]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <6yP7vgmmPmX36zl3Lp0Dxw48sxlimGcfvOI0YrM4Bt0=.86078fb2-182d-44a1-b861-a7a234073f40@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/3e8cfd74..6881b6dc

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

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:05:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:05:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v9]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <bK3ZUgWiUICbQoH6BAXaMVvozl-8K3QSP-r8i3s73R8=.62c1679c-bef6-4c61-9649-ee0b49619e11@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address more review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6881b6dc..d95c6d0f

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

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:12:01 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:12:01 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v10]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <IbzbMQh8itf1bZDG2NW9koTmFnZBZy4p793Ia9rqmYI=.5821acaa-a4ca-4f7a-8335-36f9be6e41a1@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add --enable-preview to micro benchmark java options

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/d95c6d0f..6e7189b4

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

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

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

From jvernee at openjdk.java.net  Thu Mar 24 19:27:22 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 19:27:22 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v11]
In-Reply-To: <sqYi7QOy93LHy2hsoiN3yxBl-d_xn5ERQ0dcUxp6Lss=.05c0c823-d8d1-415b-9e44-2ddf7cdf1806@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <sqYi7QOy93LHy2hsoiN3yxBl-d_xn5ERQ0dcUxp6Lss=.05c0c823-d8d1-415b-9e44-2ddf7cdf1806@github.com>
Message-ID: <EU8pU4FOUDRFJLT36VCNphal4tKZakWcpxu7QavBUtM=.86052746-8cf2-444d-b59d-717c185c40de@github.com>

On Thu, 24 Mar 2022 19:19:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to RunTests.gmk

Looks Good!

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

Marked as reviewed by jvernee (Reviewer).

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:27:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:27:21 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v11]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <sqYi7QOy93LHy2hsoiN3yxBl-d_xn5ERQ0dcUxp6Lss=.05c0c823-d8d1-415b-9e44-2ddf7cdf1806@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to RunTests.gmk

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6e7189b4..504b564a

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

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

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

From jvernee at openjdk.java.net  Thu Mar 24 19:27:23 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 19:27:23 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
 <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
 <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>
Message-ID: <AeMdR84caksIk-YkuMEQ3zmHwU2BazSNx8CHO34Tts0=.71fb91b5-ef10-4961-975c-a34897b80fa3@github.com>

On Thu, 24 Mar 2022 18:35:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well.
>
> I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick:
> 
> 
> diff --git a/make/RunTests.gmk b/make/RunTests.gmk
> index 81540266ec0..9ed45fb02a8 100644
> --- a/make/RunTests.gmk
> +++ b/make/RunTests.gmk
> @@ -583,7 +583,7 @@ define SetupRunMicroTestBody
>    $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS))
> 
>    # Current tests needs to open java.io
> -  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED
> +  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview
> 
>    # Save output as JSON or CSV file
>    ifneq ($$(MICRO_RESULTS_FORMAT), )
> 
> 
> People manually running the benchmarks.jar will have to pass `--enable-preview` still though.

After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted.

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:27:24 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:27:24 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <AeMdR84caksIk-YkuMEQ3zmHwU2BazSNx8CHO34Tts0=.71fb91b5-ef10-4961-975c-a34897b80fa3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
 <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
 <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>
 <AeMdR84caksIk-YkuMEQ3zmHwU2BazSNx8CHO34Tts0=.71fb91b5-ef10-4961-975c-a34897b80fa3@github.com>
Message-ID: <cRZrwXe67GkRYGSFqF2JOz4H2xfx8XNi_JwTcBj_ZVw=.b7b983b3-a936-44e4-be48-1886c852d0e6@github.com>

On Thu, 24 Mar 2022 19:17:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick:
>> 
>> 
>> diff --git a/make/RunTests.gmk b/make/RunTests.gmk
>> index 81540266ec0..9ed45fb02a8 100644
>> --- a/make/RunTests.gmk
>> +++ b/make/RunTests.gmk
>> @@ -583,7 +583,7 @@ define SetupRunMicroTestBody
>>    $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS))
>> 
>>    # Current tests needs to open java.io
>> -  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED
>> +  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview
>> 
>>    # Save output as JSON or CSV file
>>    ifneq ($$(MICRO_RESULTS_FORMAT), )
>> 
>> 
>> People manually running the benchmarks.jar will have to pass `--enable-preview` still though.
>
> After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted.

Turns out this is no longer necessary. As part of the support for preview API, javac now only pollutes the classfile if a source file is using preview features, as described in this PR:
https://github.com/openjdk/jdk/pull/703

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

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

From duke at openjdk.java.net  Sat Mar 26 16:38:41 2022
From: duke at openjdk.java.net (liach)
Date: Sat, 26 Mar 2022 16:38:41 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v3]
In-Reply-To: <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
Message-ID: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com>

On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert dubious changes in MethodType

Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array?

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

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

From duke at openjdk.java.net  Sat Mar 26 19:27:40 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 26 Mar 2022 19:27:40 GMT
Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory
 consumption [v3]
In-Reply-To: <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
Message-ID: <PnvdxgMFOIjyBNWns4NCzVlkauh4lsXyfTrkyuTtN0U=.ccee3b66-f59b-4cdb-98e8-51fe4a3dfabc@github.com>

On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert dubious changes in MethodType

There were changes with `Set.of()`, but I've reverted them as dubious. I'll rename the ticket and PR's title.

As of the second question I didn't look namely for `Collections.addAll(set, elements)`, if I find any feasible for replacement with `Set.of()` then I'll add it.

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

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

From simonis at openjdk.java.net  Mon Mar 28 08:11:15 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 28 Mar 2022 08:11:15 GMT
Subject: RFR: 8283756: [testbug] Only verify inflated bytes in
 ZipFSOutputStreamTest
Message-ID: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>

The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.

The content consists of a data stream of bytes with the value `42`.

The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).

The fix is trivial. Only compare as many bytes as have been inflated against the original content.

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

Commit messages:
 - 8283756: [testbug] Only verify inflated bytes in ZipFSOutputStreamTest

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

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

From jpai at openjdk.java.net  Mon Mar 28 08:21:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 28 Mar 2022 08:21:46 GMT
Subject: RFR: 8283756: [testbug] Only verify inflated bytes in
 ZipFSOutputStreamTest
In-Reply-To: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
References: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
Message-ID: <WZr3qyqjwPFSYLYS6xJ72zHeDUQmu4W8yYyB-Ix32-g=.0460473d-be15-4f80-abc0-c1858e6debc2@github.com>

On Mon, 28 Mar 2022 08:04:59 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.
> 
> The content consists of a data stream of bytes with the value `42`.
> 
> The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).
> 
> The fix is trivial. Only compare as many bytes as have been inflated against the original content.

Marked as reviewed by jpai (Committer).

Thank you for catching this, Volker. The change looks fine to me.

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

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

From alanb at openjdk.java.net  Mon Mar 28 08:49:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 28 Mar 2022 08:49:49 GMT
Subject: RFR: 8283756: [testbug] Only verify inflated bytes in
 ZipFSOutputStreamTest
In-Reply-To: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
References: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
Message-ID: <LGGg5MRj_FW9jFj0lNR6vV-CCHvfZbrYVtScYoczVPg=.3d96d4cb-7b09-46c3-a60d-5b4e136f01b8@github.com>

On Mon, 28 Mar 2022 08:04:59 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.
> 
> The content consists of a data stream of bytes with the value `42`.
> 
> The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).
> 
> The fix is trivial. Only compare as many bytes as have been inflated against the original content.

This looks okay.

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

Marked as reviewed by alanb (Reviewer).

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

From simonis at openjdk.java.net  Mon Mar 28 10:05:18 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 28 Mar 2022 10:05:18 GMT
Subject: RFR: 8283756: [testbug] Only verify inflated bytes in
 ZipFSOutputStreamTest [v2]
In-Reply-To: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
References: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
Message-ID: <c6xhD1h1oaVKsZKtKwul3pP1dcjAixbxmJBffI1FZZ4=.e9bbc540-2416-4179-ac1b-e68628b2735a@github.com>

> The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.
> 
> The content consists of a data stream of bytes with the value `42`.
> 
> The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).
> 
> The fix is trivial. Only compare as many bytes as have been inflated against the original content.

Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  (zipfs) ZipFSOutputStreamTest.testOutputStream should only check inflated bytes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7984/files
  - new: https://git.openjdk.java.net/jdk/pull/7984/files/6f121a22..810369c7

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

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

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

From simonis at openjdk.java.net  Mon Mar 28 10:13:15 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 28 Mar 2022 10:13:15 GMT
Subject: RFR: 8283756: (zipfs) ZipFSOutputStreamTest.testOutputStream
 should only check inflated bytes [v3]
In-Reply-To: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
References: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
Message-ID: <87adxVKKaAP0IZI7gQmS3DZxxIQgL1HPWRidyA_o2DQ=.a5015be0-4383-4e0f-a507-eee3ba97a855@github.com>

> The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.
> 
> The content consists of a data stream of bytes with the value `42`.
> 
> The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).
> 
> The fix is trivial. Only compare as many bytes as have been inflated against the original content.

Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8283756: (zipfs) ZipFSOutputStreamTest.testOutputStream should only check inflated bytes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7984/files
  - new: https://git.openjdk.java.net/jdk/pull/7984/files/810369c7..814a2f56

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

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

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

From lancea at openjdk.java.net  Mon Mar 28 10:14:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Mar 2022 10:14:53 GMT
Subject: RFR: 8283756: (zipfs) ZipFSOutputStreamTest.testOutputStream
 should only check inflated bytes [v3]
In-Reply-To: <87adxVKKaAP0IZI7gQmS3DZxxIQgL1HPWRidyA_o2DQ=.a5015be0-4383-4e0f-a507-eee3ba97a855@github.com>
References: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
 <87adxVKKaAP0IZI7gQmS3DZxxIQgL1HPWRidyA_o2DQ=.a5015be0-4383-4e0f-a507-eee3ba97a855@github.com>
Message-ID: <xvGHT09Sr7zio6oeiAjwXv9XFAufvZrgTPGWaCThajM=.6bffad83-f8ea-471a-9e2c-366fbbd449be@github.com>

On Mon, 28 Mar 2022 10:13:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.
>> 
>> The content consists of a data stream of bytes with the value `42`.
>> 
>> The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).
>> 
>> The fix is trivial. Only compare as many bytes as have been inflated against the original content.
>
> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8283756: (zipfs) ZipFSOutputStreamTest.testOutputStream should only check inflated bytes

Marked as reviewed by lancea (Reviewer).

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

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

From simonis at openjdk.java.net  Mon Mar 28 13:44:43 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 28 Mar 2022 13:44:43 GMT
Subject: Integrated: 8283756: (zipfs) ZipFSOutputStreamTest.testOutputStream
 should only check inflated bytes
In-Reply-To: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
References: <LXEKA8_j6zQRQnIh8rr5tEGfdkNbVla126cCduGfWfo=.a1ec67a4-f0b6-409b-96df-d1d283049fc2@github.com>
Message-ID: <oMi_xSuLoiyJdMesBIYoy0zwBbpClun9Zk1rO6B5jzw=.40631726-fbc1-48f7-b788-823495266e17@github.com>

On Mon, 28 Mar 2022 08:04:59 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> The test `ZipFSOutputStreamTest` deflates content into a zip file system and subsequently inflates the deflated files and checks their content against the original data.
> 
> The content consists of a data stream of bytes with the value `42`.
> 
> The check currently compares the temporary inflation buffer with the original source buffer, no matter how many bytes were inflated into the inflation buffer. This can lead to problems with alternative zlib implementations which sometimes write beyond the last inflated byte (see [JDK-8282648](https://bugs.openjdk.java.net/browse/JDK-8282648) for more details).
> 
> The fix is trivial. Only compare as many bytes as have been inflated against the original content.

This pull request has now been integrated.

Changeset: 0c472c8a
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c472c8a4ff01b3bc8fba5df82c24c240586e5c5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283756: (zipfs) ZipFSOutputStreamTest.testOutputStream should only check inflated bytes

Reviewed-by: jpai, alanb, lancea

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

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

From duke at openjdk.java.net  Tue Mar 29 04:03:47 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 29 Mar 2022 04:03:47 GMT
Subject: Withdrawn: 8274112: (fc) Tune FileChannel.transferTo()
In-Reply-To: <c6AIUxLqHUQuZq_KOTFM7wuRLJuSM5fvP-WAGHS3pvY=.a5d3f024-b306-4158-b674-9216726ac1cd@github.com>
References: <c6AIUxLqHUQuZq_KOTFM7wuRLJuSM5fvP-WAGHS3pvY=.a5d3f024-b306-4158-b674-9216726ac1cd@github.com>
Message-ID: <6dIG-AQD1ifA-FjxTku2hWdZpyefANGJfJenABKMugs=.340713b5-507c-457f-91fe-1a09932fc5af@github.com>

On Wed, 22 Sep 2021 01:25:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this patch which would improve the performance of
> `FileChannel.transferTo()` on macOS and Windows.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Tue Mar 29 09:51:42 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 29 Mar 2022 09:51:42 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com>
Message-ID: <txxWRGCj95Z4BRqwcSn6bbuc1UxbnJ_YzmlOaToVj8Y=.ff2f76c9-a65d-446d-bd7c-4e4836e90d67@github.com>

On Sat, 26 Mar 2022 16:35:14 GMT, liach <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes in MethodType
>
> Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array?

@liach I've found a couple of places:
- `AsynchronousFileChannel.open()`
- `FileChannel.open()`
- `DecimalStyle.getAvailableLocales()`
They all either rely on user input, i.e. might throw NPE or IAE for nulls or duplicates respectively, or return the set, which is currently modifiable `HashSet`. I think the possible win isn't worth the effort.

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

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

From mcimadamore at openjdk.java.net  Tue Mar 29 18:13:05 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 18:13:05 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v12]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <VrBKvqY2VPw610lAb_DQ67oJoPUKg8gY1NfbQtDompc=.302e1c5e-0577-4e19-a963-3e137c2f2879@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore 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 27 additional commits since the last revision:

 - Use thread local storage to optimize attach of async threads
 - Drop support for Constable from MemoryLayout/FunctionDescriptor
 - Merge branch 'master' into foreign-preview
 - Revert changes to RunTests.gmk
 - Add --enable-preview to micro benchmark java options
 - Address more review comments
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Address review comments
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/02333d66...55aee872

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/504b564a..55aee872

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

  Stats: 99257 lines in 1550 files changed: 79659 ins; 15544 del; 4054 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From mcimadamore at openjdk.java.net  Tue Mar 29 18:23:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 18:23:41 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v13]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <w1LIgrpX4jp0zQM5bnopMS4X7F2Tedv1heD_crujzLg=.eaef7a80-78c1-4d82-9d5b-9151793c587a@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Switch to daemon threads for async upcalls

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/55aee872..43dc6be3

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

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

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

From mcimadamore at openjdk.java.net  Wed Mar 30 18:06:28 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 18:06:28 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v14]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UUVSVqArxsxmgZm4nRpTMSOOP7TBU-HAlliRgnZj3nA=.7c2577cd-3275-4711-8250-5f3f9177cd4f@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix bad usage of `@link` with primitive array types

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/43dc6be3..0bcc8664

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

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

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

From mcimadamore at openjdk.java.net  Wed Mar 30 20:59:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 20:59:34 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v15]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <ChILQVD6A1dP5zIu-XbL55gyACnJznvKj2As-xmN9zo=.77166bcb-2e43-4f23-b3e4-572bd0cb03c7@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak FunctionDescriptor::argumentLayouts to return an immutable list

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/0bcc8664..af41a76c

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

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

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

From mcimadamore at openjdk.java.net  Wed Mar 30 21:51:16 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 21:51:16 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v16]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <D_sTznfZ5MwQIq0R-E6xdlYDoMdB1zS4I9Fw4CPI4fE=.19016960-d411-4506-b323-b2d6b359c916@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into foreign-preview
 - Tweak FunctionDescriptor::argumentLayouts to return an immutable list
 - Fix bad usage of `@link` with primitive array types
 - Switch to daemon threads for async upcalls
 - Use thread local storage to optimize attach of async threads
 - Drop support for Constable from MemoryLayout/FunctionDescriptor
 - Merge branch 'master' into foreign-preview
 - Revert changes to RunTests.gmk
 - Add --enable-preview to micro benchmark java options
 - Address more review comments
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=15
  Stats: 64862 lines in 366 files changed: 43028 ins; 19321 del; 2513 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From duke at openjdk.java.net  Wed Mar 30 22:25:44 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 30 Mar 2022 22:25:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v15]
In-Reply-To: <ChILQVD6A1dP5zIu-XbL55gyACnJznvKj2As-xmN9zo=.77166bcb-2e43-4f23-b3e4-572bd0cb03c7@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <ChILQVD6A1dP5zIu-XbL55gyACnJznvKj2As-xmN9zo=.77166bcb-2e43-4f23-b3e4-572bd0cb03c7@github.com>
Message-ID: <AGhJWXkbgskWwaMsytGJeljynUof-XLGCScTmUpJpdc=.e4254f87-bfec-42a9-8813-da67515d2e6d@github.com>

On Wed, 30 Mar 2022 20:59:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak FunctionDescriptor::argumentLayouts to return an immutable list

src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 73:

> 71:      */
> 72:     public List<MemoryLayout> argumentLayouts() {
> 73:         return Collections.unmodifiableList(argLayouts);

This?change doesn?t?seem to?be?necessary, as?`FunctionDescriptor` is?already?created?with?`List.of(?)` (or?`Stream.toList()` in?the?case of?`FunctionDescriptor.VariadicFunction`), which?produce immutable?lists (although?`Stream.toList()` permits?`null`s, which?`Stream.collect(Collectors.toImmutableList())` and?`List.of(?)`?doesn?t).

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

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

From psandoz at openjdk.java.net  Wed Mar 30 22:44:42 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 30 Mar 2022 22:44:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v16]
In-Reply-To: <D_sTznfZ5MwQIq0R-E6xdlYDoMdB1zS4I9Fw4CPI4fE=.19016960-d411-4506-b323-b2d6b359c916@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <D_sTznfZ5MwQIq0R-E6xdlYDoMdB1zS4I9Fw4CPI4fE=.19016960-d411-4506-b323-b2d6b359c916@github.com>
Message-ID: <b6v4JeNodxX__cHxI3F3rGCRu8bB2o6_-9GEco-H-Sc=.4ba750f5-1ab2-4d6d-b16b-c108cc04222e@github.com>

On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Tweak FunctionDescriptor::argumentLayouts to return an immutable list
>  - Fix bad usage of `@link` with primitive array types
>  - Switch to daemon threads for async upcalls
>  - Use thread local storage to optimize attach of async threads
>  - Drop support for Constable from MemoryLayout/FunctionDescriptor
>  - Merge branch 'master' into foreign-preview
>  - Revert changes to RunTests.gmk
>  - Add --enable-preview to micro benchmark java options
>  - Address more review comments
>  - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5

Java code looks good (i did not go through the tests). As is common no comments, since code was reviewed in smaller steps in the panama-foreign respository.

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

Marked as reviewed by psandoz (Reviewer).

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

From bpb at openjdk.java.net  Wed Mar 30 23:15:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Mar 2022 23:15:36 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v9]
In-Reply-To: <q1C6Dc7uLUCuGI-7Fh9T2B1gQU0Xnu-xIgpT7lvdmqQ=.4b28e841-22af-4bd8-a1e0-e94c8509962a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <iuf12RvTYzRk8PSskmiu8dW72NG2AL2-2fQGqt2nauE=.b300b495-8f79-4d0c-993d-39e07f34d872@github.com>
 <q1C6Dc7uLUCuGI-7Fh9T2B1gQU0Xnu-xIgpT7lvdmqQ=.4b28e841-22af-4bd8-a1e0-e94c8509962a@github.com>
Message-ID: <BTUt8seuKB9qmQgLsnG1UM9Ay5K4VXvCkw6HdXZvduw=.9564d4e8-17d4-4034-9468-292b30d89405@github.com>

On Fri, 29 Jan 2021 22:10:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Path.java line 258:
>> 
>>> 256:      * is returned.  This will occur if the file name has length less than two,
>>> 257:      * only the first character is a dot, or the last character is a dot.
>>> 258:      *
>> 
>> Add the case where there is no '.' to be explicit.
>
> Good point; will do.

Fixed by commit 7c3d0ff79ee11e6f1e567a21c6f23d3b3dc1c615.

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

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

From bpb at openjdk.java.net  Wed Mar 30 23:28:44 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Mar 2022 23:28:44 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v2]
In-Reply-To: <ifnyby1Ep_3sirnIVAOsOoSePYKUelPbOUJVaJlZtvo=.5587590d-482c-474a-9304-505c1bccd931@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <lXnihqoSeE9UoeatdQ3B2XgZWyrzSkv3DjDSSdYiZ3I=.79baefd9-45cf-40bb-bd31-7768394d5f48@github.com>
 <hDqwPegKOU3l6SZsTwJUlm_I6Ump0VTH9wwzQc7oDfA=.17eadc4a-bc00-4bb3-9b8d-9117b16c32f7@github.com>
 <ifnyby1Ep_3sirnIVAOsOoSePYKUelPbOUJVaJlZtvo=.5587590d-482c-474a-9304-505c1bccd931@github.com>
Message-ID: <0XrtvbE2683r1Ql3tJmOmDXLIFaqKRMirQD9TcJj2v0=.92a3741a-3115-48f8-b38f-84a403b50a91@github.com>

On Mon, 1 Feb 2021 17:53:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Path.java line 259:
>> 
>>> 257:      * characters, does not contain a dot, only the first character is a dot,
>>> 258:      * or the last character is a dot.
>>> 259:      *
>> 
>> Thanks for bringing this one back. The survey and the current proposal seems reasonable.
>> 
>> The spec will need cover the case that the Path doesn't have a file name (getFileName can return null so I assume the prototype implementation will NPE in that case). Are you planning to return null or the empty String for this case?
>> 
>> "file name string" needs to be replaced with "the String representation of the file name". This is significant aspect of the proposal in that it aligns the method with toString rather than other operations that preserve the platform representation of the path.
>
> The `getFileName() == null` case was an oversight. I think the empty string should be returned in this case.

Addressed by commit 8d462f8615bc9038a4e27ec5302902f71d558e02.

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

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

From bpb at openjdk.java.net  Wed Mar 30 23:28:53 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Mar 2022 23:28:53 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v9]
In-Reply-To: <iuf12RvTYzRk8PSskmiu8dW72NG2AL2-2fQGqt2nauE=.b300b495-8f79-4d0c-993d-39e07f34d872@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <iuf12RvTYzRk8PSskmiu8dW72NG2AL2-2fQGqt2nauE=.b300b495-8f79-4d0c-993d-39e07f34d872@github.com>
Message-ID: <V5AAeUR0xsCUkV3jPdPniXazbZu_wEhDJ0sWQtgKs3A=.0e9b3f8d-ed83-48cb-baaa-24ee08f81a49@github.com>

On Fri, 29 Jan 2021 21:53:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter 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:
>> 
>>  - 8057113: Optimistically update @since tag to 18
>>  - Merge
>>  - 8057113: Change first sentence; change param name
>>  - 8057113: Change Path.getExtension() to accept a default return value in case the extension is indeterminate
>>  - 8057113: Tweak spec again, and @implSpec code
>>  - 8057113: Add @since tag
>>  - 8057113: Tweak first sentence of spec
>>  - 8057113: Handle getFileName() == null; revise spec
>>  - 8057113: Changes pursuant to PR conversation
>>  - 8057113: (fs) Path should have a method to obtain the filename extension
>
> src/java.base/share/classes/java/nio/file/Path.java line 267:
> 
>> 265:      *     filename.substring(filename.lastIndexOf('.') + 1);
>> 266:      * }</pre>
>> 267:      *
> 
> The Implspec fragment should be more complete. The preconditions in the prose are likely to be ignored by the reader.

Addressed by commit 7c3d0ff79ee11e6f1e567a21c6f23d3b3dc1c615.

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

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

From bpb at openjdk.java.net  Wed Mar 30 23:28:55 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Mar 2022 23:28:55 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v9]
In-Reply-To: <3S92nkcCBDPgT2zytmFpiexJkN89K6vuXbe-V1Tm_gw=.68c00c66-ba7e-475c-ba13-a2de52e6b3e2@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <DT0SprapH6Uam8_-fuYCTxzAk4rAqsGdpm6YzZCWzmE=.f4447d03-5d97-4f02-8a64-362e0a21e54f@github.com>
 <3S92nkcCBDPgT2zytmFpiexJkN89K6vuXbe-V1Tm_gw=.68c00c66-ba7e-475c-ba13-a2de52e6b3e2@github.com>
Message-ID: <a170K5X8Xf7jfzbw3TGAm__h5IWZ1bZ0bTtDcRqiz5U=.7ddff288-a92a-4132-9522-9ad5f3ad3c77@github.com>

On Fri, 29 Jan 2021 22:22:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Path.java line 278:
>> 
>>> 276:         // Indeterminate if name is too short or equal to "..".
>>> 277:         if (length > 1 && !name.equals("..")) {
>>> 278:             int lastDotIndex = name.lastIndexOf('.');
>> 
>> Since there are no strings of length 0..2, is it sufficient to check for length > 2.
>> (Instead of the string compare equals("..").
>
> Nice point! Considering that the strings of length 2 are `.x`, `xy`, and `x.` where `x` and `y` are characters which are not `'.'`, then I concur.

Addressed by commit 7c3d0ff79ee11e6f1e567a21c6f23d3b3dc1c615.

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

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