From lihuaming3 at huawei.com  Mon Feb  1 01:22:29 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Mon, 1 Feb 2021 01:22:29 +0000
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTogKGZjKSBGaWxlQ2hhbm5lbC50cmFu?=
 =?utf-8?B?c2ZlckZyb20vdHJhbnNmZXJGcm9tQXJiaXRyYXJ5Q2hhbm5lbCB0byByZXR1?=
 =?utf-8?Q?rn_-1_at_some_error_condition?=
In-Reply-To: <408c0fa4-cfcc-88dc-8afa-5ba07c869796@oracle.com>
References: <FF52E71F75D5A341BDD9AB1622091FA5012103D3@DGGEML523-MBX.china.huawei.com>
 <f0d14384-b663-7398-439d-fd2657470617@oracle.com>
 <FF52E71F75D5A341BDD9AB1622091FA501211937@DGGEML523-MBX.china.huawei.com>
 <d032afdb-6be0-37a4-a343-d7be3e4291ca@oracle.com>
 <FF52E71F75D5A341BDD9AB1622091FA501211B9E@DGGEML523-MBX.china.huawei.com>
 <408c0fa4-cfcc-88dc-8afa-5ba07c869796@oracle.com>
Message-ID: <FF52E71F75D5A341BDD9AB1622091FA501212E1C@DGGEML523-MBX.china.huawei.com>

Got it, thanks Alan.
I will put something into apiNote of transferFrom/transferTo, it?s tracked by https://bugs.openjdk.java.net/browse/JDK-8260694.

Thanks,
Hamlin

???: Alan Bateman [mailto:Alan.Bateman at oracle.com]
????: 2021?1?30? 16:52
???: lihuaming (A) <lihuaming3 at huawei.com>; nio-dev at openjdk.java.net
??: Re: ??: ??: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to return -1 at some error condition

On 30/01/2021 07:52, lihuaming (A) wrote:


### if the arbitrary channel was just closed by peer side, transferFrom will return 0 this time or next time, and there is no way for it knows that the underlying socket was closed, unless it calls channel.read. But for performance consideration, I think some framework/program would like to call FileChannel,transferFrom(channel, ?) only, rather than followed by a read+write just in case of channel is closed by peer side; read+write can be optimized by only do it if transferFrom(channel, ?) returns 0, but it still has some extra cost, and code is not simple and straight.
### I don?t think this is jdk bug and I do have concern about the compatibility too and explained to framework/program developers, but I can also understand their points, so want to see if there are some way to make it more friendly to framework/program developers in this situation. Hope I have made it clear ?. If there is no other better solutions, I will let them know that it?s better to modify their code.

Thanks Alan for discussion.

Right, I think you get it. In this case the framework will need to fix their code.

While not the case here, I do have sympathy for those trying to using this API with a source channel that is configured non-blocking. As the method returns the number of bytes transferred (meaning read and then the written to the file) then it can't distinguish the EOF from the "no bytes available" case. This is probably something we should put into an @apiNote.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210201/5bd6dcf2/attachment.htm>

From mli at openjdk.java.net  Mon Feb  1 11:24:55 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 1 Feb 2021 11:24:55 GMT
Subject: RFR: JDK-8260694: (fc) put clear message in
 FileChannel.transferFrom/transferTo that it will not return -1
Message-ID: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>

We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.

please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

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

Commit messages:
 - JDK-8260694: (fc) put clear message in FileChannel.transferFrom/transferTo that it will not return -1

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

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

From bpb at openjdk.java.net  Mon Feb  1 17:58:59 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 1 Feb 2021 17:58:59 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>

> 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
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

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

  8057113: Handle getFileName() == null; revise spec

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2319/files
  - new: https://git.openjdk.java.net/jdk/pull/2319/files/7c3d0ff7..8d462f86

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

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

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

From bpb at openjdk.java.net  Mon Feb  1 17:59:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 1 Feb 2021 17:59:00 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v2]
In-Reply-To: <hDqwPegKOU3l6SZsTwJUlm_I6Ump0VTH9wwzQc7oDfA=.17eadc4a-bc00-4bb3-9b8d-9117b16c32f7@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>
Message-ID: <ifnyby1Ep_3sirnIVAOsOoSePYKUelPbOUJVaJlZtvo=.5587590d-482c-474a-9304-505c1bccd931@github.com>

On Sun, 31 Jan 2021 12:39:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8057113: Changes pursuant to PR conversation
>
> 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.

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

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

From rriggs at openjdk.java.net  Mon Feb  1 18:57:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 1 Feb 2021 18:57:43 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
Message-ID: <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>

On Mon, 1 Feb 2021 17:58:59 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
>> 
>> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Handle getFileName() == null; revise spec

Marked as reviewed by rriggs (Reviewer).

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

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

From bpb at openjdk.java.net  Mon Feb  1 22:07:54 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 1 Feb 2021 22:07:54 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v4]
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <2nx-zNCDFyXdJYq4rB3GtpM5_Kyes0ST2SAqBG4Ev_I=.2dc22fba-5170-4e24-ae17-2864d50f8238@github.com>

> 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
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

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

  8057113: Tweak first sentence of spec

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2319/files
  - new: https://git.openjdk.java.net/jdk/pull/2319/files/8d462f86..f973b06a

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

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

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

From bpb at openjdk.java.net  Mon Feb  1 22:17:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 1 Feb 2021 22:17:58 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v5]
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <2Gf7ruDZvXD39IRzLvdfY_ad70ajUNpw3riduSsesE0=.04884f97-a3a6-48d9-9111-8522b2f31b9f@github.com>

> 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
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

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

  8057113: Add @since tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2319/files
  - new: https://git.openjdk.java.net/jdk/pull/2319/files/f973b06a..ba3c5abf

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

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

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

From bpb at openjdk.java.net  Mon Feb  1 23:16:59 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 1 Feb 2021 23:16:59 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v6]
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <VevAFDqxbnp4Y5uS9JQYrldeKuGMhyd4dalmGdg-WCQ=.ddd57e1f-9a0b-47f5-bb6e-318c45758cbc@github.com>

> 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
> 
> If the specification can be agreed upon, then a test will be added to this PR and a corresponding CSR will be filed.

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

  8057113: Tweak spec again, and @implSpec code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2319/files
  - new: https://git.openjdk.java.net/jdk/pull/2319/files/ba3c5abf..22c3ccec

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

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

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

From mli at openjdk.java.net  Tue Feb  2 01:08:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 2 Feb 2021 01:08:41 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case
In-Reply-To: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
Message-ID: <lK6op_K6p4UTYWK8tVi1W04fc0vQQnIEcEPcZhKtHvM=.18a486ac-e1d0-480d-8f52-4ee9deb5541a@github.com>

On Mon, 1 Feb 2021 02:26:23 GMT, Hamlin Li <mli at openjdk.org> wrote:

> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
> 
> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

interesting, why it keeps failing? I just modified the javadoc in the patch. is this an environment issue?

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

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

From mli at openjdk.java.net  Tue Feb  2 04:30:52 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 2 Feb 2021 04:30:52 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
Message-ID: <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>

> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
> 
> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

Hamlin Li 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:

  JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2329/files
  - new: https://git.openjdk.java.net/jdk/pull/2329/files/c9ed084b..91233c7f

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

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

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

From hedongbo at huawei.com  Tue Feb  2 06:06:44 2021
From: hedongbo at huawei.com (hedongbo)
Date: Tue, 2 Feb 2021 06:06:44 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
Message-ID: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>

Hi,

Please review this changes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8260875
webrev: http://cr.openjdk.java.net/~dongbohe/8260875/webrev.00/


Testing:  jdk_tier1

Thanks,
dongbohe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/76d22b6c/attachment.htm>

From Alan.Bateman at oracle.com  Tue Feb  2 08:20:51 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Feb 2021 08:20:51 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
Message-ID: <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>

On 02/02/2021 06:06, hedongbo wrote:
>
> Hi,
>
> Please review this changes.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8260875 
> <https://bugs.openjdk.java.net/browse/JDK-8260875>
>
> webrev: http://cr.openjdk.java.net/~dongbohe/8260875/webrev.00/ 
> <http://cr.openjdk.java.net/~dongbohe/8260875/webrev.00/>
>
> Testing: ?jdk_tier1
>
>
Hi,

I spotted JDK-8260875 today and closed it as a dup of JDK-6878250 before 
seeing your mail. The socket adaptor was significantly re-written in JDK 
13 and the newer implementation checks the channel state before the 
blocking mode. This means that ClosedChannelException is thrown if you 
attempt to read and the underlying channel was configured non-blocking 
before it was closed. So are you looking to fix this in 11u or 8u?

-Alan.

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

From alanb at openjdk.java.net  Tue Feb  2 08:41:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 2 Feb 2021 08:41:43 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
Message-ID: <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>

On Tue, 2 Feb 2021 04:30:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
>> 
>> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html
>
> Hamlin Li 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.

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

> 592:      * This method only returns the number of bytes that were actually
> 593:      * transferred, it will not return -1.
> 594:      *

The transferTo method is file -> target channel and I think it would be confusing to mention -1 here.
We could add an apiNote to point out that the method returns zero if the given position is greater than the file's current size, and also zero if the target channel is non-blocking and has no bytes free in its output buffer, but I think the javadoc is already clear.

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

> 664:      * transferred, it will not return -1, e.g. in case of EOF of the
> 665:      * {@code src} parameter.
> 666:      *

Looking at this again, I think it may be better if we just add a sentence to the end of the second paragraph of the method description. The second paragraph already covers the case that fewer bytes are transferred. I think it can be something simple like "No bytes are transferred if the source channel has reached end-of-stream". I suggest "end-of-stream" rather than "EOF" because that is the phrase used in the RBC javadoc.

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

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

From sebastian.stenzel at gmail.com  Tue Feb  2 09:21:58 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Tue, 2 Feb 2021 10:21:58 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
Message-ID: <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>


> On 25. Jan 2021, at 15:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 25/01/2021 08:30, Sebastian Stenzel wrote:
>> 
>> I guess the pattern here is to assign the `my_methodhandle` to whatever applies during init(), as it is done e.g. for `my_futimens_func`? May I ask why this is done via dlsym()? Since the code is inside an #ifdef directive, so the compiler can't reach it if not applicable, can't I just assign my_futimens_func = futimens?
>> 
>> Am I right that we're dealing with four platforms (Linux, Aix, BSD and macOS, the latter being a "special" BSD), that can be distinguished via #ifdef using one of these:
>> 
>> ```
>> __linux__
>> _AIX
>> _ALLBSD_SOURCE
>> MACOSX
>> ```
>> 
>> What about `#ifdef __APPLE__`? I can see this used in various other places.
>> 
>> If `_ALLBSD_SOURCE` is supposed to include all BSD flavours, can I simplify this:
>> 
>> ```
>> #if defined(__linux__) || defined(_AIX)
>> #include <string.h>
>> #endif
>> 
>> #ifdef _ALLBSD_SOURCE
>> #include <string.h>
>> ...
>> #endif
>> ```
>> 
>> to this:
>> 
>> ```
>> #include <string.h>
>> ```
>> 
>> ?
> 
> The xxx_func setup in the LinuxNativeDispatcher_init date when from when the xattr functions weren't in the include files used at build-time. A potential first step is to include     <attr/xattr.h> and get that change bedded in.
> 
> The _ALLBSD_SOURCE vs. MACOSX vs. ... is unfortunate and stems from how the macOS port came into JDK 7u4.  No objection to use _ALLBSD_SOURCE.
> 
> -Alan

So far there is no issue on the bug tracker for this task, is it? If I understand the contribution guideline correctly, PRs without issues will get rejected. Since I have no write access to the bug tracker, shall I submit it via bugreport.java.com?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/0dacfb0f/attachment.htm>

From hedongbo at huawei.com  Tue Feb  2 09:33:11 2021
From: hedongbo at huawei.com (hedongbo)
Date: Tue, 2 Feb 2021 09:33:11 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
Message-ID: <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>

Yes, I want to fix this on 8. Webrev is also for 8.
Backport JDK-8246707 to 11 can solve this problem in 11, and I am doing this backport.


Thanks,
Dongbohe

From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Tuesday, February 2, 2021 4:21 PM
To: hedongbo <hedongbo at huawei.com>; nio-dev at openjdk.java.net
Subject: Re: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws IllegalBlockingModeException on closed channel

On 02/02/2021 06:06, hedongbo wrote:

Hi,

Please review this changes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8260875
webrev: http://cr.openjdk.java.net/~dongbohe/8260875/webrev.00/


Testing:  jdk_tier1

Hi,

I spotted JDK-8260875 today and closed it as a dup of JDK-6878250 before seeing your mail. The socket adaptor was significantly re-written in JDK 13 and the newer implementation checks the channel state before the blocking mode. This means that ClosedChannelException is thrown if you attempt to read and the underlying channel was configured non-blocking before it was closed. So are you looking to fix this in 11u or 8u?

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/27528d31/attachment-0001.htm>

From sebastian.stenzel at gmail.com  Tue Feb  2 10:02:34 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Tue, 2 Feb 2021 11:02:34 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
Message-ID: <17A3517F-E136-4D6E-8B68-478576A64164@gmail.com>


> On 2. Feb 2021, at 10:21, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> 
>> On 25. Jan 2021, at 15:00, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>> 
>> On 25/01/2021 08:30, Sebastian Stenzel wrote:
>>> 
>>> I guess the pattern here is to assign the `my_methodhandle` to whatever applies during init(), as it is done e.g. for `my_futimens_func`? May I ask why this is done via dlsym()? Since the code is inside an #ifdef directive, so the compiler can't reach it if not applicable, can't I just assign my_futimens_func = futimens?
>>> 
>>> Am I right that we're dealing with four platforms (Linux, Aix, BSD and macOS, the latter being a "special" BSD), that can be distinguished via #ifdef using one of these:
>>> 
>>> ```
>>> __linux__
>>> _AIX
>>> _ALLBSD_SOURCE
>>> MACOSX
>>> ```
>>> 
>>> What about `#ifdef __APPLE__`? I can see this used in various other places.
>>> 
>>> If `_ALLBSD_SOURCE` is supposed to include all BSD flavours, can I simplify this:
>>> 
>>> ```
>>> #if defined(__linux__) || defined(_AIX)
>>> #include <string.h>
>>> #endif
>>> 
>>> #ifdef _ALLBSD_SOURCE
>>> #include <string.h>
>>> ...
>>> #endif
>>> ```
>>> 
>>> to this:
>>> 
>>> ```
>>> #include <string.h>
>>> ```
>>> 
>>> ?
>> 
>> The xxx_func setup in the LinuxNativeDispatcher_init date when from when the xattr functions weren't in the include files used at build-time. A potential first step is to include <attr/xattr.h> and get that change bedded in.
>> 
>> The _ALLBSD_SOURCE vs. MACOSX vs. ... is unfortunate and stems from how the macOS port came into JDK 7u4.  No objection to use _ALLBSD_SOURCE.
>> 
>> -Alan
> 
> So far there is no issue on the bug tracker for this task, is it? If I understand the contribution guideline correctly, PRs without issues will get rejected. Since I have no write access to the bug tracker, shall I submit it via bugreport.java.com <http://bugreport.java.com/>?

Bonus question: May I change `capabilities` to long? https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L569-L574 <https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L569-L574>
I'd like to add `SUPPORTS_XATTR`, but I guess `1 << 32` won't fit into an int.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/7d8269a5/attachment.htm>

From Alan.Bateman at oracle.com  Tue Feb  2 11:11:42 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Feb 2021 11:11:42 +0000
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
Message-ID: <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>

On 02/02/2021 09:21, Sebastian Stenzel wrote:
> So far there is no issue on the bug tracker for this task, is it? If I 
> understand the contribution guideline correctly, PRs without issues 
> will get rejected. Since I have no write access to the bug tracker, 
> shall I submit it via bugreport.java.com 
> <https://urldefense.com/v3/__http://bugreport.java.com__;!!GqivPVa7Brio!Iuw3U7d7JJWXoFhEp-u4w4apFbV-ieLN6CLvfrcG9LvlQ3mAo5f5rfE9PlTUARFk3w$>?

I should have replied to you on this. I did create JDK-8260691 [1] a few 
days ago to eliminate the use of dlsym from the Linux implementation. It 
dates back to when xattr.h could not be relied on to be in the build 
environment. I see Brian Burkhalter has picked it up but I don't know if 
he has done anything on it. I assume you want to start with that one. 
I'll create another issue for the consolidation and reply here with the 
link.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8260691
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/3313820e/attachment.htm>

From Alan.Bateman at oracle.com  Tue Feb  2 11:15:59 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Feb 2021 11:15:59 +0000
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <17A3517F-E136-4D6E-8B68-478576A64164@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <17A3517F-E136-4D6E-8B68-478576A64164@gmail.com>
Message-ID: <c012b82c-ff2f-00b8-90d3-b5112d3835a5@oracle.com>

On 02/02/2021 10:02, Sebastian Stenzel wrote:
> :
>
> Bonus question: May I change `capabilities` to long? 
> https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L569-L574 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/jdk-17*7/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java*L569-L574__;KyM!!GqivPVa7Brio!PaPuewCCxFb9a7f0XBQZdRHRwsjD81df1TlabuvZ3yIwhxYiB9XK8a-QZAYUGB_l2g$>
> I'd like to add `SUPPORTS_XATTR`, but I guess `1 << 32` won't fit into 
> an int.
It might be better to just fix the initialization of the existing 
SUPPORTS_ constants. There are only 5 of them so there are lots of bits 
available.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/75b635b6/attachment-0001.htm>

From sebastian.stenzel at gmail.com  Tue Feb  2 11:25:49 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Tue, 2 Feb 2021 12:25:49 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <c012b82c-ff2f-00b8-90d3-b5112d3835a5@oracle.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <17A3517F-E136-4D6E-8B68-478576A64164@gmail.com>
 <c012b82c-ff2f-00b8-90d3-b5112d3835a5@oracle.com>
Message-ID: <5728AA5F-57A5-4539-A99A-1AAA7354AB88@gmail.com>


> On 2. Feb 2021, at 12:15, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 02/02/2021 10:02, Sebastian Stenzel wrote:
>> :
>> 
>> Bonus question: May I change `capabilities` to long? https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L569-L574 <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/jdk-17*7/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java*L569-L574__;KyM!!GqivPVa7Brio!PaPuewCCxFb9a7f0XBQZdRHRwsjD81df1TlabuvZ3yIwhxYiB9XK8a-QZAYUGB_l2g$>
>> I'd like to add `SUPPORTS_XATTR`, but I guess `1 << 32` won't fit into an int.
> It might be better to just fix the initialization of the existing SUPPORTS_ constants. There are only 5 of them so there are lots of bits available.
> 
> -Alan.

Right. Should I keep SUPPORTS_BIRTHTIME as 2^16? The comments suggest there are two different domains of supported features.

Proposal:

```
private static final int SUPPORTS_OPENAT        = 1 << 1;  // syscalls
private static final int SUPPORTS_FUTIMES       = 1 << 2;
private static final int SUPPORTS_FUTIMENS      = 1 << 3;
private static final int SUPPORTS_LUTIMES       = 1 << 4;
private static final int SUPPORTS_XATTR         = 1 << 5;
private static final int SUPPORTS_BIRTHTIME     = 1 << 16; // other features
```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/633be202/attachment.htm>

From sebastian.stenzel at gmail.com  Tue Feb  2 11:29:14 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Tue, 2 Feb 2021 12:29:14 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>
Message-ID: <F843D2CA-00D3-43FF-BD8E-32A212895A19@gmail.com>


> On 2. Feb 2021, at 12:11, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 02/02/2021 09:21, Sebastian Stenzel wrote:
>> So far there is no issue on the bug tracker for this task, is it? If I understand the contribution guideline correctly, PRs without issues will get rejected. Since I have no write access to the bug tracker, shall I submit it via bugreport.java.com <https://urldefense.com/v3/__http://bugreport.java.com__;!!GqivPVa7Brio!Iuw3U7d7JJWXoFhEp-u4w4apFbV-ieLN6CLvfrcG9LvlQ3mAo5f5rfE9PlTUARFk3w$>?
> 
> I should have replied to you on this. I did create JDK-8260691 [1] a few days ago to eliminate the use of dlsym from the Linux implementation. It dates back to when xattr.h could not be relied on to be in the build environment. I see Brian Burkhalter has picked it up but I don't know if he has done anything on it. I assume you want to start with that one. I'll create another issue for the consolidation and reply here with the link.
> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8260691 <https://bugs.openjdk.java.net/browse/JDK-8260691>

I would have removed the dlsym code in one go, together with the dedup and modernization. Assuming Brian has not already any uncommitted changes, should I still proceed or rather split this into two separate pull requests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/0aada6c9/attachment.htm>

From Alan.Bateman at oracle.com  Tue Feb  2 12:16:48 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Feb 2021 12:16:48 +0000
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <5728AA5F-57A5-4539-A99A-1AAA7354AB88@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <17A3517F-E136-4D6E-8B68-478576A64164@gmail.com>
 <c012b82c-ff2f-00b8-90d3-b5112d3835a5@oracle.com>
 <5728AA5F-57A5-4539-A99A-1AAA7354AB88@gmail.com>
Message-ID: <454bb6a5-218f-3880-c3e1-a44ff61b6691@oracle.com>



On 02/02/2021 11:25, Sebastian Stenzel wrote:
>
>
> Right. Should I keep?SUPPORTS_BIRTHTIME?as 2^16? The comments suggest 
> there are two different domains of supported features.
>
> Proposal:
>
> ```
> private static final int?SUPPORTS_OPENAT ?=?1?<<?1; ?// syscalls
> private static final int?SUPPORTS_FUTIMES ? ? ? =?1?<<?2;
> private static final int?SUPPORTS_FUTIMENS ? ? ?=?1?<<?3;
> private static final int?SUPPORTS_LUTIMES ? ? ? =?1?<<?4;
> private static final int?SUPPORTS_XATTR ? ? ? ? =?1?<<?5;
> private static final int?SUPPORTS_BIRTHTIME =?1?<<?16;?// other features
> ```
Capabilities was originally just for system calls but it was extended to 
st_birthtim as the only "other feature".? You proposal is good.

-Alan

From Alan.Bateman at oracle.com  Tue Feb  2 17:22:36 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Feb 2021 17:22:36 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
Message-ID: <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com>

On 02/02/2021 09:33, hedongbo wrote:
>
> Yes, I want to fix this on 8. Webrev is also for 8.
>
> Backport JDK-8246707 to 11 can solve this problem in 11, and I am 
> doing this backport.
>

Okay. Feel free to re-open JDK-8260875if it easier for you.I'm not 
involved in JDK updates so you'll need to follow the process for the 
updates releases (the patch to SocketAdaptor in your patch is fine).

JDK-8246707 is a different issue. This is the throwing of 
AsynchronousCloseException instead of ClosedClosedException which can be 
confusing. That could be fixed in 11u, should not be an issue in 8u.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/cad582e8/attachment.htm>

From brian.burkhalter at oracle.com  Tue Feb  2 17:28:42 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 2 Feb 2021 09:28:42 -0800
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>
Message-ID: <ACB92A32-8B9E-44C6-AD87-1F9A81D11CF1@oracle.com>


> On Feb 2, 2021, at 3:11 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 02/02/2021 09:21, Sebastian Stenzel wrote:
>> So far there is no issue on the bug tracker for this task, is it? If I understand the contribution guideline correctly, PRs without issues will get rejected. Since I have no write access to the bug tracker, shall I submit it via bugreport.java.com <https://urldefense.com/v3/__http://bugreport.java.com__;!!GqivPVa7Brio!Iuw3U7d7JJWXoFhEp-u4w4apFbV-ieLN6CLvfrcG9LvlQ3mAo5f5rfE9PlTUARFk3w$>?
> 
> I should have replied to you on this. I did create JDK-8260691 [1] a few days ago to eliminate the use of dlsym from the Linux implementation. It dates back to when xattr.h could not be relied on to be in the build environment. I see Brian Burkhalter has picked it up but I don't know if he has done anything on it. I assume you want to start with that one. I'll create another issue for the consolidation and reply here with the link.

I have as yet not done any work on [1] other than to assign the issue to myself (triage). I have no uncommitted changes so feel free to proceed.

[1] https://bugs.openjdk.java.net/browse/JDK-8260691 <https://bugs.openjdk.java.net/browse/JDK-8260691>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210202/7d249183/attachment-0001.htm>

From Alan.Bateman at oracle.com  Tue Feb  2 17:32:27 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 2 Feb 2021 17:32:27 +0000
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <F843D2CA-00D3-43FF-BD8E-32A212895A19@gmail.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>
 <F843D2CA-00D3-43FF-BD8E-32A212895A19@gmail.com>
Message-ID: <958fd230-7766-72a4-a7f3-d70540dcf85c@oracle.com>

On 02/02/2021 11:29, Sebastian Stenzel wrote:
> :
>
> I would have removed the dlsym code in one go, together with the dedup 
> and modernization. Assuming Brian has not already any uncommitted 
> changes, should I still proceed or rather split this into two separate 
> pull requests?
Up to you although it might make the review easier if we clean-up the 
Linux implementation first. I created JDK-8260966 [1] for the 
consolidation work. Once you have one or two more commits then we should 
look as giving you Author role so that you have JBS access.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8260966

From sebastian.stenzel at gmail.com  Tue Feb  2 19:12:27 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Tue, 2 Feb 2021 20:12:27 +0100
Subject: Deduplicating code in BsdUserDefinedFileAttributeView and
 LinuxUserDefinedFileAttributeView
In-Reply-To: <958fd230-7766-72a4-a7f3-d70540dcf85c@oracle.com>
References: <F6FA1F82-966E-4483-9536-0C7B698661FF@gmail.com>
 <3a4ea192-885f-f2d3-dc20-779418e43ea2@oracle.com>
 <E36DE692-3705-414A-BDD3-31C25FD50ADA@gmail.com>
 <203f751d-355d-53a0-599c-c10dde77bbdc@oracle.com>
 <587F244A-352E-433C-BC61-2A16444494B9@gmail.com>
 <c7aaacb9-76d2-73fe-b904-0382329fdf76@oracle.com>
 <F843D2CA-00D3-43FF-BD8E-32A212895A19@gmail.com>
 <958fd230-7766-72a4-a7f3-d70540dcf85c@oracle.com>
Message-ID: <AA0E89AD-F984-48D8-BB99-E0918EFE13AC@gmail.com>


> On 2. Feb 2021, at 18:32, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 02/02/2021 11:29, Sebastian Stenzel wrote:
>> :
>> 
>> I would have removed the dlsym code in one go, together with the dedup and modernization. Assuming Brian has not already any uncommitted changes, should I still proceed or rather split this into two separate pull requests?
> Up to you although it might make the review easier if we clean-up the Linux implementation first. I created JDK-8260966 [1] for the consolidation work. Once you have one or two more commits then we should look as giving you Author role so that you have JBS access.
> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8260966

Thank you, I will reference JDK-8260966. Since Brian said he didn't change anything so far, it'll be easier for me to combine both issues. In comparison, the dlsym diff is rather small, anyway. I think I should be able to draft a PR within the next day.

From github.com+1204330+overheadhunter at openjdk.java.net  Tue Feb  2 21:27:59 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Tue, 2 Feb 2021 21:27:59 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of
 UserDefinedFileAttributeView
Message-ID: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>

I want to discuss the changes of this PR in three sections:

# Deduplications
The main focus was to deduplicate code:
- `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I made added an abstract method `UnixUserDefinedAttributeView. maxNameLength()` and kept the other two.
- `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix. BSD-specific adjustments are now done in C.
- `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
- For the latter I hade to combine `UnixConstants.ENODATA` and `UnixConstants.ENOATTR` to a platform-agnostic `UnixConstants.XATTR_NOT_FOUND` ??  Warning: While `ENODATA` is no longer used JDK-internally, it might have been used via reflection in downstream projects, thus causing regressions. Maintainers should decide, if we might want to keep `ENODATA` additionally to the new `XATTR_NOT_FOUND`.
- Deduplicated code inside of *NativeDispatcher's methods `copyExtendedAttributes(int ofd, int nfd)` and `list()`

# Cleanup / Improvements
- On AIX (or other Unix Platforms not explicitly supporting xattr), calling related native methods will result in `ENOTSUP`
- `NativeBuffer implements AutoCloseable` and used try-with-resource statements where applicable
- changed loop to recursive function for creation of larger buffer, if `flistxattr` fails due to `ERANGE` error (max recursion depth is 5, I don't expect performance benefits from loop unrolling, therefore chose reduced cyclomatic complexity over performance)
- Added `UnixNativeDispatcher.SUPPORTS_XATTR` capability and added a shortcut to `UnixFileStore. isExtendedAttributesEnabled(...)` to skip I/O that is known to fail
- Removed legacy `dlsym` for xattr-related Linux system calls (fixes JDK-8260691)

# Fixes
- `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` now correctly copies xattr on macOS/BSD ([invocation was missing before](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72))
- no longer [access `dst.arrayOffset()` without checking](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L201) if `dst.hasArray()` during `read()`. Code is now symmetric with `write()`
- fixed [potential resource leak of `nb` during `write()`](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L258), if `file.openForAttributeAccess(...)` fails


Please note, that while the tests succeed on macOS, so far I didn't manage to run `jtreg:test/jdk/java/nio/file/attribute/` on a Linux CI system due to lack of knowledge or will power ??

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

Commit messages:
 - Deduplicated code in LinuxFileStore and BsdFileStore
 - further deduplication and complexity reduction
 - deduplicate LinuxUserDefinedAttributeView and BsdUserDefinedAttributeView

Changes: https://git.openjdk.java.net/jdk/pull/2363/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2363&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260966
  Stats: 1510 lines in 17 files changed: 520 ins; 971 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2363/head:pull/2363

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

From honguye at microsoft.com  Tue Feb  2 21:56:27 2021
From: honguye at microsoft.com (Nhat Nguyen)
Date: Tue, 2 Feb 2021 21:56:27 +0000
Subject: [EXTERNAL] Re: Bug in Files.isSameFile(Path,Path)
In-Reply-To: <MW2PR2101MB181769932B678AD5676810B7A6E60@MW2PR2101MB1817.namprd21.prod.outlook.com>
References: <31383fa0-ba8f-1e29-8d3a-950f34c724b0@freedom.nl>
 <AM6PR03MB4389E24F6BB9C9933889D997FF1A0@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <505f6548-382b-f85c-bc89-b70bfae9e294@freedom.nl>
 <DM6PR21MB1468569CDF508EF079122F08F51A0@DM6PR21MB1468.namprd21.prod.outlook.com>
 <828f16b7-c438-9827-70fa-49ac15fcb20f@oracle.com>
 <DM6PR21MB1641EAEC982B4450AF1F878BA6140@DM6PR21MB1641.namprd21.prod.outlook.com>
 <ba999d5a-564c-cb61-14bb-519190e3fab0@oracle.com>
 <DM6PR21MB1468A315AFEF45B14A2AB53EF5140@DM6PR21MB1468.namprd21.prod.outlook.com>
 <BN7PR21MB163613BBB01CC8863AA1547AA6100@BN7PR21MB1636.namprd21.prod.outlook.com>
 <0fb92dd2-7319-25ed-2d74-74445dc5aa8a@oracle.com>
 <DM6PR21MB1641267734BB6A8375113DD1A6EF0@DM6PR21MB1641.namprd21.prod.outlook.com>
 <b581a793-6cb9-f8db-5592-d70637dab746@oracle.com>
 <MW2PR2101MB181769932B678AD5676810B7A6E60@MW2PR2101MB1817.namprd21.prod.outlook.com>
Message-ID: <DM5PR21MB17842C1750584B4DE5DE2FC0A6B59@DM5PR21MB1784.namprd21.prod.outlook.com>

Hi Alan,

It has been a while since we last had this conversation. I just want to ask if
you are still interested in investigating more into this issue?

Thank you,
Nhat

-----Original Message-----
From: Nhat Nguyen 
Sent: Thursday, November 12, 2020 4:26 PM
To: Alan Bateman <Alan.Bateman at oracle.com>; Nikola Grcevski <Nikola.Grcevski at microsoft.com>; WarnerJan Veldhuis <veldhuis at freedom.nl>; nio-dev at openjdk.java.net
Cc: Brian Stafford <Brian.Stafford at microsoft.com>
Subject: RE: [EXTERNAL] Re: Bug in Files.isSameFile(Path,Path)

Hi Alan,

> If you confirm that GetFinalPathNameByHandle is essentially POSIX 
> realpath then I would be happy to see WindowsLinkSupport.getRealPath 
> changed to use that for the followLinks=true case. It might be that we 
> need a fallback for cases where GetFinalPathNameByHandle fails

I found an interesting discussion from the cpython folks [1]. They recently started using GetFinalPathNameByHandle by default for their realpath implementation [2]. If the call fails, they fall back to a combination of GetFinalPathNameByHandle and manually resolving links [3].

In this discussion, there was a particularly useful comment from Eryk Sun [4] where he mentioned that GetFinalPathNameByHandle is not entirely similar to POSIX realpath when the path contains a mount point:

> Eryk Sun:
> What we need is an implementation of realpath("C:/spam/scripts") that returns "C:\\spam\\scripts"
> when "scripts" is a mount point and returns "C:\\spam\\etc\\scripts" when "scripts" is a symlink.
> This means we need an implementation of realpath() that looks a lot like posixpath.realpath.
> Generally a mount point should be walked over like a directory, just as mount points are handled in Unix.

However, looking at the current implementation of OpenJDK's toRealPath, as soon as we detect that there's a subpath that contains the flag FILE_ATTRIBUTE_REPARSE_POINT, we immediately call getFinalPath on the original path. So if a path contains a symlink or a mount point, the result of toRealPath is always the result of getFinalPath (unless the call fails due to broken links, at which point we try to resolve them and recursively call toRealPath again).

So my understanding is that we may still be ok to use getFinalPath for toRealPath, at least in the case where the path contains links/mount points, since the behaviour is the same as what we currently have. However, assuming we always use getFinalPath when followLinks=true, users who mount webdav on drive Z: will now get back the full link \\sharepointHostName.com at SSL\DavWWWRoot\a.txt" which used to be "Z:\a.txt". It is still unclear to me what should be the right behaviour in this particular case.


> I'd also would be okay with change isSameFile to use toRealPath on both files so that it does not rely on the volume or file index.

Solely for the purpose of file comparison, what is your opinion on using getFinalPath for isSameFile instead of toRealPath, which would also require some changes to its implementation? The paths are only used for comparison and aren't returned to the users, so we won't have to worry about breaking compatibility for existing code. 

Thanks,
Nhat

[1]: https://bugs.python.org/issue9949
[2]: https://github.com/python/cpython/blob/cc75ab791dd5ae2cb9f6e0c3c5f734a6ae1eb2a9/Lib/ntpath.py#L647
[3]: https://github.com/python/cpython/blob/cc75ab791dd5ae2cb9f6e0c3c5f734a6ae1eb2a9/Lib/ntpath.py#L579
[4]: https://bugs.python.org/msg350138, this is the directly link to one of the comments in [1]

-----Original Message-----
From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Thursday, November 5, 2020 6:12 AM
To: Nhat Nguyen <honguye at microsoft.com>; Nikola Grcevski <Nikola.Grcevski at microsoft.com>; WarnerJan Veldhuis <veldhuis at freedom.nl>; nio-dev at openjdk.java.net
Subject: Re: [EXTERNAL] Re: Bug in Files.isSameFile(Path,Path)

On 04/11/2020 00:16, Nhat Nguyen wrote:
> Hi Alan,
>
> Thank you for the suggestion! I tried using toRealPath and noticed this interesting scenario.
>
> Let's assume that we have a drive "Z:" mapped to a sharepoint drive containing file "a.txt" and another soft link "C:/link"
> whose target is "Z:/a.txt". Further assume we want to see if "Z:/a.txt" and "C:/link" are the same.
>
> If we perform toRealPath on both inputs, "Z:/a.txt" will stay as 
> "Z:/a.txt". However, "C:/link" will follow a different code path in WindowsLinkSupport.getRealPath where it notices that the input is a reparse point and eventually calls getFinalPath.
> The result for "C:/link" is then
> "\\sharepointHostName.com at SSL\DavWWWRoot\a.txt". So, we conclude that the files are different even though?they are the same.
>
> If we use GetFinalPath for both, we will be able to notice that they 
> are the same. I'd love to know what you think about this scenario and if it's worth supporting it.
>
I agree we need to re-examine WindowsLinkSupport.getRealPath, at least for the followLinks=true case. If I remember correctly, we couldn't rely on GetFinalPathNameByHandle because it wasn't available on Windows XP and that is historical now. Also there was an issue with needing to open the file with backup semantics, I need to page in some of the details but I think that was needed for directories. There was another issue with sym links on NTFS that linked to files on non-NTFS volumes. If you confirm that GetFinalPathNameByHandle is essentially POSIX realpath then I would be happy to see WindowsLinkSupport.getRealPath changed to use that for the followLinks=true case. It might be that we need a fallback for cases where GetFinalPathNameByHandle fails. I'd also would be okay with change isSameFile to use toRealPath on both files so that it does not rely on the volume or file index.

-Alan

From bpb at openjdk.java.net  Tue Feb  2 23:45:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 2 Feb 2021 23:45:43 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
 <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>
Message-ID: <rBp2Pky0zSQy1A97BNYkebti1t76mi--1FhgSZQPOng=.85e5a00d-dc78-4450-8839-6221c1260185@github.com>

On Mon, 1 Feb 2021 18:54:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8057113: Handle getFileName() == null; revise spec
>
> Marked as reviewed by rriggs (Reviewer).

**Alternate Specifications**

Alternate specifications are possible. Ignoring more precise naming, e.g., `getExtensionOrElseEmptyString()` for the original version above, some possible options are:

1. `String getExtension(`) returns the extension or the empty string if no extension found
2. `String getExtension()` returns the extension or `null` if no extension found
3. `String getExtension(String default)` returns the extension or `default` if no extension found (may be `null`)
4. `Optional<String> getExtension()` returns the extension, if any, contained in an `Optional`

Option 1 is that originally proposed. Option 2 is identical but returns null instead of the empty string if there is no extension. This is consistent with other methods in `Path` such as `getRoot()`, `getParent()`, and `getFileName()`. Option 3 allows the possibility to supply the value to be returned if no extension is found. Option 4 wraps the extension string or `null` in an `Optional`.

If one wanted to be able to retain the internal structure of the extension as a `Path`, then one could instead define two methods:

`Path Path.getExtension()`
`String Path.getExtensionString()`

as part of the point is the user not being obliged to call `toString()`. Here `getExtension()` would be implemented in the platform-specific `Path` classes, and `getExtensionString()` would be a default method in the `Path` interface.

In all cases, when the `Path` represents a root component, then the extension is indeterminate (empty or `null`, depending).

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

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

From mli at openjdk.java.net  Wed Feb  3 01:11:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 01:11:44 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
 <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
Message-ID: <sfrWao35Ge1nkdOUEVmoKLVP97Ip9TEFH9SzA_WS8eg=.64031938-3306-458e-a974-86978c80bf78@github.com>

On Tue, 2 Feb 2021 08:35:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hamlin Li 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.
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 594:
> 
>> 592:      * This method only returns the number of bytes that were actually
>> 593:      * transferred, it will not return -1.
>> 594:      *
> 
> The transferTo method is file -> target channel and I think it would be confusing to mention -1 here.
> We could add an apiNote to point out that the method returns zero if the given position is greater than the file's current size, and also zero if the target channel is non-blocking and has no bytes free in its output buffer, but I think the javadoc is already clear.

OK, I will remove this @apiNote addition

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

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

From mli at openjdk.java.net  Wed Feb  3 01:18:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 01:18:47 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
 <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
Message-ID: <rcdx7b3YnVw8fJgpllrS61AiHkD1QA2Ua6FYbn9DqeU=.cfac7471-1b93-4e6f-8bd6-c0db0e9ab492@github.com>

On Tue, 2 Feb 2021 08:39:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hamlin Li 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:
>> 
>>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 666:
> 
>> 664:      * transferred, it will not return -1, e.g. in case of EOF of the
>> 665:      * {@code src} parameter.
>> 666:      *
> 
> Looking at this again, I think it may be better if we just add a sentence to the end of the second paragraph of the method description. The second paragraph already covers the case that fewer bytes are transferred. I think it can be something simple like "No bytes are transferred if the source channel has reached end-of-stream". I suggest "end-of-stream" rather than "EOF" because that is the phrase used in the RBC javadoc.

Hi Alan, Thanks for reviewing.
I will add the sentence you suggested at the end of second paragraph, will use "end-of-stream".
Still think it's better to add an apiNote, although it's a little redundant, but it helps emphasize it, I saw several cases of misunderstanding of transferFrom. How do you think about it?

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

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

From mli at openjdk.java.net  Wed Feb  3 01:22:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 01:22:59 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v3]
In-Reply-To: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
Message-ID: <TprkFDx-lwD-l1rjlwHmhgmU22L8UI7N6aTH3lCFJGM=.2240e568-13b1-4bd0-b759-0861b619d69e@github.com>

> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
> 
> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

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

  JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2329/files
  - new: https://git.openjdk.java.net/jdk/pull/2329/files/91233c7f..b198ce68

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

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

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

From bpb at openjdk.java.net  Wed Feb  3 02:09:44 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 3 Feb 2021 02:09:44 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v3]
In-Reply-To: <TprkFDx-lwD-l1rjlwHmhgmU22L8UI7N6aTH3lCFJGM=.2240e568-13b1-4bd0-b759-0861b619d69e@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <TprkFDx-lwD-l1rjlwHmhgmU22L8UI7N6aTH3lCFJGM=.2240e568-13b1-4bd0-b759-0861b619d69e@github.com>
Message-ID: <S-u2wuUZ_97snIUwcpqi751sL0igwsEd9BYm6ZBK374=.ba4a8e5a-8f88-4458-b014-be29262d3221@github.com>

On Wed, 3 Feb 2021 01:22:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
>> 
>> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

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

> 644:      * and has fewer than {@code count} bytes immediately available in its
> 645:      * input buffer. No bytes are transferred if the source channel has reached
> 646:      * end-of-stream.

How about `* end-of-stream in which case zero will be returned.`?

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

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

From bpb at openjdk.java.net  Wed Feb  3 02:09:47 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 3 Feb 2021 02:09:47 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <rcdx7b3YnVw8fJgpllrS61AiHkD1QA2Ua6FYbn9DqeU=.cfac7471-1b93-4e6f-8bd6-c0db0e9ab492@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
 <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
 <rcdx7b3YnVw8fJgpllrS61AiHkD1QA2Ua6FYbn9DqeU=.cfac7471-1b93-4e6f-8bd6-c0db0e9ab492@github.com>
Message-ID: <mOxzAh-m2tjFszlNitXzSQl4o_EeRtuJp2Auzc63eSY=.decdf87f-34b4-4a49-89c2-b42a5f7d86cc@github.com>

On Wed, 3 Feb 2021 01:15:40 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/FileChannel.java line 666:
>> 
>>> 664:      * transferred, it will not return -1, e.g. in case of EOF of the
>>> 665:      * {@code src} parameter.
>>> 666:      *
>> 
>> Looking at this again, I think it may be better if we just add a sentence to the end of the second paragraph of the method description. The second paragraph already covers the case that fewer bytes are transferred. I think it can be something simple like "No bytes are transferred if the source channel has reached end-of-stream". I suggest "end-of-stream" rather than "EOF" because that is the phrase used in the RBC javadoc.
>
> Hi Alan, Thanks for reviewing.
> I will add the sentence you suggested at the end of second paragraph, will use "end-of-stream".
> Still think it's better to add an apiNote, although it's a little redundant, but it helps emphasize it, I saw several cases of misunderstanding of transferFrom. How do you think about it?

Given the other verbiage I don't think that an `apiNote` is actually necessary.

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

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

From mli at openjdk.java.net  Wed Feb  3 05:29:43 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 05:29:43 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v3]
In-Reply-To: <S-u2wuUZ_97snIUwcpqi751sL0igwsEd9BYm6ZBK374=.ba4a8e5a-8f88-4458-b014-be29262d3221@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <TprkFDx-lwD-l1rjlwHmhgmU22L8UI7N6aTH3lCFJGM=.2240e568-13b1-4bd0-b759-0861b619d69e@github.com>
 <S-u2wuUZ_97snIUwcpqi751sL0igwsEd9BYm6ZBK374=.ba4a8e5a-8f88-4458-b014-be29262d3221@github.com>
Message-ID: <OSCLl5gLC_pQg5VTPcvXJTITjTNZ9RZ-7m28hi1s5O0=.95f36dea-d86a-4ea9-a509-ec74efbdd8a7@github.com>

On Wed, 3 Feb 2021 02:05:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 646:
> 
>> 644:      * and has fewer than {@code count} bytes immediately available in its
>> 645:      * input buffer. No bytes are transferred if the source channel has reached
>> 646:      * end-of-stream.
> 
> How about `* end-of-stream in which case zero will be returned.`?

Sure, will modify as you suggested.

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

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

From mli at openjdk.java.net  Wed Feb  3 05:29:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 05:29:44 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <mOxzAh-m2tjFszlNitXzSQl4o_EeRtuJp2Auzc63eSY=.decdf87f-34b4-4a49-89c2-b42a5f7d86cc@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
 <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
 <rcdx7b3YnVw8fJgpllrS61AiHkD1QA2Ua6FYbn9DqeU=.cfac7471-1b93-4e6f-8bd6-c0db0e9ab492@github.com>
 <mOxzAh-m2tjFszlNitXzSQl4o_EeRtuJp2Auzc63eSY=.decdf87f-34b4-4a49-89c2-b42a5f7d86cc@github.com>
Message-ID: <Nvrblxwz8XFPurByCRXalOrXs1pP6UHkyJos5wL8kPA=.de03d350-3efc-42a4-8126-5dc8cdf5f73e@github.com>

On Wed, 3 Feb 2021 02:07:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hi Alan, Thanks for reviewing.
>> I will add the sentence you suggested at the end of second paragraph, will use "end-of-stream".
>> Still think it's better to add an apiNote, although it's a little redundant, but it helps emphasize it, I saw several cases of misunderstanding of transferFrom. How do you think about it?
>
> Given the other verbiage I don't think that an `apiNote` is actually necessary.

Hi Brian, 
At the beginning, I don't think this patch is necessary, because I think if I read really carefully, then I can avoid the misuse.
But the truth is there are several misuse cases, not just in my company, several are in opensource projects. So, I think it's worth to emphasize it even if it's a little redudant.
How do you think about it?

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

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

From mli at openjdk.java.net  Wed Feb  3 05:32:50 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 05:32:50 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case
In-Reply-To: <lK6op_K6p4UTYWK8tVi1W04fc0vQQnIEcEPcZhKtHvM=.18a486ac-e1d0-480d-8f52-4ee9deb5541a@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <lK6op_K6p4UTYWK8tVi1W04fc0vQQnIEcEPcZhKtHvM=.18a486ac-e1d0-480d-8f52-4ee9deb5541a@github.com>
Message-ID: <Soo652LfwozalX36p2w2Ggba_I1GYgMeNkG2yfDOfbU=.e77ae223-0c87-4b6b-9f94-2be61ef5e67c@github.com>

On Tue, 2 Feb 2021 01:05:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
>> 
>> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html
>
> interesting, why it keeps failing? I just modified the javadoc in the patch. is this an environment issue?

@AlanBateman @bplb Hi Alan, Brian, do you know how can I avoid the failures in pre-submit tests? I don't think my patch will introduce the failures, any clue or suggestion?
Thanks

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

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

From alanb at openjdk.java.net  Wed Feb  3 08:10:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 3 Feb 2021 08:10:43 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <Nvrblxwz8XFPurByCRXalOrXs1pP6UHkyJos5wL8kPA=.de03d350-3efc-42a4-8126-5dc8cdf5f73e@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
 <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
 <rcdx7b3YnVw8fJgpllrS61AiHkD1QA2Ua6FYbn9DqeU=.cfac7471-1b93-4e6f-8bd6-c0db0e9ab492@github.com>
 <mOxzAh-m2tjFszlNitXzSQl4o_EeRtuJp2Auzc63eSY=.decdf87f-34b4-4a49-89c2-b42a5f7d86cc@github.com>
 <Nvrblxwz8XFPurByCRXalOrXs1pP6UHkyJos5wL8kPA=.de03d350-3efc-42a4-8126-5dc8cdf5f73e@github.com>
Message-ID: <T8DQqNY5P9F5jmKVS92EwQxltY5hlmrBrKKXX-hLrzQ=.597280d6-e9d6-4a99-9854-2bf021f17e0c@github.com>

On Wed, 3 Feb 2021 05:27:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Given the other verbiage I don't think that an `apiNote` is actually necessary.
>
> Hi Brian, 
> At the beginning, I don't think this patch is necessary, because I think if I read really carefully, then I can avoid the misuse.
> But the truth is there are several misuse cases, not just in my company, several are in opensource projects. So, I think it's worth to emphasize it even if it's a little redudant.
> How do you think about it?

The transferXXX methods return the number of bytes that were transferred to or from the file so there should be no expectation that -1 is returned. My preference would be to just clarify the transferFrom javadoc to make it clear that zero is returned when the source has reached end-of-stream.

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

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

From hedongbo at huawei.com  Wed Feb  3 10:43:56 2021
From: hedongbo at huawei.com (hedongbo)
Date: Wed, 3 Feb 2021 10:43:56 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
 <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com>
Message-ID: <8FC616E5EC1A774287430B1CC2696FE30471140D@dggeml513-mbx.china.huawei.com>

Thank you for your review, Alan.



I changed the bug to JDK-6878250, and added jdk8-fix label on JDK-6878250

webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/

bug: https://bugs.openjdk.java.net/browse/JDK-6878250



At the same time, I have sent an email to jdk-updates-dev to backport JDK-8246707 to jdk11u



Thanks,
dongbohe

From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Wednesday, February 3, 2021 1:23 AM
To: hedongbo <hedongbo at huawei.com>; nio-dev at openjdk.java.net
Subject: Re: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws IllegalBlockingModeException on closed channel

On 02/02/2021 09:33, hedongbo wrote:

Yes, I want to fix this on 8. Webrev is also for 8.
Backport JDK-8246707 to 11 can solve this problem in 11, and I am doing this backport.

Okay. Feel free to re-open JDK-8260875 if it easier for you. I'm not involved in JDK updates so you'll need to follow the process for the updates releases (the patch to SocketAdaptor in your patch is fine).

JDK-8246707 is a different issue. This is the throwing of AsynchronousCloseException instead of ClosedClosedException which can be confusing. That could be fixed in 11u, should not be an issue in 8u.

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

From mli at openjdk.java.net  Wed Feb  3 11:54:00 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 11:54:00 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v4]
In-Reply-To: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
Message-ID: <YXaa2BXgT7rGwRH7FDrbBFvjQGNxIXg-9eycC4zzBnU=.829dede5-6878-49dc-9a54-cc37b6ad42bc@github.com>

> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
> 
> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

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

  JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2329/files
  - new: https://git.openjdk.java.net/jdk/pull/2329/files/b198ce68..b9ab224f

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

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

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

From mli at openjdk.java.net  Wed Feb  3 11:54:00 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Feb 2021 11:54:00 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v2]
In-Reply-To: <T8DQqNY5P9F5jmKVS92EwQxltY5hlmrBrKKXX-hLrzQ=.597280d6-e9d6-4a99-9854-2bf021f17e0c@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <1Qftla_F5mwhev4HNtGt9OtYmvsOphzjyb-GTmJk23k=.b48e52ae-8d65-4fb7-80dc-f66db8634378@github.com>
 <OB9Ccq3zC3dKLy0y_g4gTPgOpZLxFtW2X71afjrx3pE=.a161670a-b0eb-4ad0-b532-3009e5858ff5@github.com>
 <rcdx7b3YnVw8fJgpllrS61AiHkD1QA2Ua6FYbn9DqeU=.cfac7471-1b93-4e6f-8bd6-c0db0e9ab492@github.com>
 <mOxzAh-m2tjFszlNitXzSQl4o_EeRtuJp2Auzc63eSY=.decdf87f-34b4-4a49-89c2-b42a5f7d86cc@github.com>
 <Nvrblxwz8XFPurByCRXalOrXs1pP6UHkyJos5wL8kPA=.de03d350-3efc-42a4-8126-5dc8cdf5f73e@github.com>
 <T8DQqNY5P9F5jmKVS92EwQxltY5hlmrBrKKXX-hLrzQ=.597280d6-e9d6-4a99-9854-2bf021f17e0c@github.com>
Message-ID: <Osa1155SRCqHNyPutDvs2OdIxOlLLt61BEtnsTf3rsE=.67db2cf5-70fd-484e-a217-48550ca179c9@github.com>

On Wed, 3 Feb 2021 08:07:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Brian, 
>> At the beginning, I don't think this patch is necessary, because I think if I read really carefully, then I can avoid the misuse.
>> But the truth is there are several misuse cases, not just in my company, several are in opensource projects. So, I think it's worth to emphasize it even if it's a little redudant.
>> How do you think about it?
>
> The transferXXX methods return the number of bytes that were transferred to or from the file so there should be no expectation that -1 is returned. My preference would be to just clarify the transferFrom javadoc to make it clear that zero is returned when the source has reached end-of-stream.

OK, I have removed the apiNote and only refine the javadoc as Brian suggested.
Would you mind to take another look? Thanks

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Feb  3 12:08:42 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 3 Feb 2021 12:08:42 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
References: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
Message-ID: <FTke6oVlaDcxPk-daShaF2dmGHG6VphYyl6zhwrAz4U=.9f56e79b-620c-4652-9e29-e1152a881fd7@github.com>

On Tue, 2 Feb 2021 21:23:04 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

> I want to discuss the changes of this PR in three sections:
> 
> # Deduplications
> The main focus was to deduplicate code:
> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I made added an abstract method `UnixUserDefinedAttributeView. maxNameLength()` and kept the other two.
> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix. BSD-specific adjustments are now done in C.
> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
> - For the latter I hade to combine `UnixConstants.ENODATA` and `UnixConstants.ENOATTR` to a platform-agnostic `UnixConstants.XATTR_NOT_FOUND` ??  Warning: While `ENODATA` is no longer used JDK-internally, it might have been used via reflection in downstream projects, thus causing regressions. Maintainers should decide, if we might want to keep `ENODATA` additionally to the new `XATTR_NOT_FOUND`.
> - Deduplicated code inside of *NativeDispatcher's methods `copyExtendedAttributes(int ofd, int nfd)` and `list()`
> 
> # Cleanup / Improvements
> - On AIX (or other Unix Platforms not explicitly supporting xattr), calling related native methods will result in `ENOTSUP`
> - `NativeBuffer implements AutoCloseable` and used try-with-resource statements where applicable
> - changed loop to recursive function for creation of larger buffer, if `flistxattr` fails due to `ERANGE` error (max recursion depth is 5, I don't expect performance benefits from loop unrolling, therefore chose reduced cyclomatic complexity over performance)
> - Added `UnixNativeDispatcher.SUPPORTS_XATTR` capability and added a shortcut to `UnixFileStore. isExtendedAttributesEnabled(...)` to skip I/O that is known to fail
> - Removed legacy `dlsym` for xattr-related Linux system calls (fixes JDK-8260691)
> 
> # Fixes
> - `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` now correctly copies xattr on macOS/BSD ([invocation was missing before](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72))
> - no longer [access `dst.arrayOffset()` without checking](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L201) if `dst.hasArray()` during `read()`. Code is now symmetric with `write()`
> - fixed [potential resource leak of `nb` during `write()`](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L258), if `file.openForAttributeAccess(...)` fails
> 
> 
> Please note, that while the tests succeed on macOS, so far I didn't manage to run `jtreg:test/jdk/java/nio/file/attribute/` on a Linux CI system due to lack of knowledge or will power ??

Ok I managed to get jtreg running in a Linux container now. Looks good:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/nio/file/attribute               10    10     0     0   
==============================
TEST SUCCESS

Finished building target 'run-test' in configuration 'linux-x86_64-server-release'

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

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

From Alan.Bateman at oracle.com  Wed Feb  3 14:03:19 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Feb 2021 14:03:19 +0000
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
References: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
Message-ID: <6f063488-5fb6-df44-a874-f48293c6e1f0@oracle.com>

On 02/02/2021 21:27, Sebastian Stenzel wrote:
> I want to discuss the changes of this PR in three sections:
Okay, one general remark here the overall patch is harder to review now 
because there are several things going on. I had hoped that the 
"modernization" of the *UserDefinedFileAttributeView would be separated 
out as there are several discussion points there. Also moving/combining 
files and significantly changing them at the same time means the diffs 
are harder to read. There is also some re-formatting that introduces 
some noise too. I'm not opposed to doing all the steps in one, it will 
just take long to review (and careful review is required due to the 
potential for buffer overflow in some of this code).


>
> # Deduplications
> The main focus was to deduplicate code:
> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I made added an abstract method `UnixUserDefinedAttributeView. maxNameLength()` and kept the other two.
> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix. BSD-specific adjustments are now done in C.
> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
> - For the latter I hade to combine `UnixConstants.ENODATA` and `UnixConstants.ENOATTR` to a platform-agnostic `UnixConstants.XATTR_NOT_FOUND` ??  Warning: While `ENODATA` is no longer used JDK-internally, it might have been used via reflection in downstream projects, thus causing regressions. Maintainers should decide, if we might want to keep `ENODATA` additionally to the new `XATTR_NOT_FOUND`
I would prefer if we left ENODATA so that it can be used in Linux 
specific code.


> - Deduplicated code inside of *NativeDispatcher's methods `copyExtendedAttributes(int ofd, int nfd)` and `list()`
>
> # Cleanup / Improvements
> - On AIX (or other Unix Platforms not explicitly supporting xattr), calling related native methods will result in `ENOTSUP`
> - `NativeBuffer implements AutoCloseable` and used try-with-resource statements where applicable
> - changed loop to recursive function for creation of larger buffer, if `flistxattr` fails due to `ERANGE` error (max recursion depth is 5, I don't expect performance benefits from loop unrolling, therefore chose reduced cyclomatic complexity over performance)
> - Added `UnixNativeDispatcher.SUPPORTS_XATTR` capability and added a shortcut to `UnixFileStore. isExtendedAttributesEnabled(...)` to skip I/O that is known to fail
> - Removed legacy `dlsym` for xattr-related Linux system calls (fixes JDK-8260691)
>
> # Fixes
> - `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` now correctly copies xattr on macOS/BSD ([invocation was missing before](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72))
> - no longer [access `dst.arrayOffset()` without checking](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L201) if `dst.hasArray()` during `read()`. Code is now symmetric with `write()`
> - fixed [potential resource leak of `nb` during `write()`](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L258), if `file.openForAttributeAccess(...)` fails
At a high-level then I think most of these suggestion changes are okay 
but I expect it will take several iterations to get agreement on all 
changes.

-Alan.

From alanb at openjdk.java.net  Wed Feb  3 14:10:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 3 Feb 2021 14:10:42 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v4]
In-Reply-To: <YXaa2BXgT7rGwRH7FDrbBFvjQGNxIXg-9eycC4zzBnU=.829dede5-6878-49dc-9a54-cc37b6ad42bc@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <YXaa2BXgT7rGwRH7FDrbBFvjQGNxIXg-9eycC4zzBnU=.829dede5-6878-49dc-9a54-cc37b6ad42bc@github.com>
Message-ID: <UFWKK7Ycsf1QDfP6vPUw3Q6mgcKtw3MNod21CcRGA9s=.66f82b84-8bdf-4b8f-9d9d-4abf140e0764@github.com>

On Wed, 3 Feb 2021 11:54:00 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
>> 
>> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

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

> 644:      * and has fewer than {@code count} bytes immediately available in its
> 645:      * input buffer. No bytes are transferred if the source channel has reached
> 646:      * the end-of-stream in which case zero will be returned.

Thanks for dropping the apiNote that mentions -1 and return value.

The update is mostly okay, I might re-word it slightly to "No bytes are transferred, and zero is returned, if the source has reached end-of-stream".

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

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

From alanb at openjdk.java.net  Wed Feb  3 15:32:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 3 Feb 2021 15:32:43 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <rBp2Pky0zSQy1A97BNYkebti1t76mi--1FhgSZQPOng=.85e5a00d-dc78-4450-8839-6221c1260185@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
 <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>
 <rBp2Pky0zSQy1A97BNYkebti1t76mi--1FhgSZQPOng=.85e5a00d-dc78-4450-8839-6221c1260185@github.com>
Message-ID: <CZmzVTBo1trr6iszJ1jXBV6bqdrHCV-yFh51G3v2xnE=.e1464303-c814-456a-be55-1aba109ea614@github.com>

On Tue, 2 Feb 2021 23:42:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Marked as reviewed by rriggs (Reviewer).
>
> **Alternate Specifications**
> 
> Alternate specifications are possible. Ignoring more precise naming, e.g., `getExtensionOrElseEmptyString()` for the original version above, some possible options are:
> 
> 1. `String getExtension(`) returns the extension or the empty string if no extension found
> 2. `String getExtension()` returns the extension or `null` if no extension found
> 3. `String getExtension(String default)` returns the extension or `default` if no extension found (may be `null`)
> 4. `Optional<String> getExtension()` returns the extension, if any, contained in an `Optional`
> 
> Option 1 is that originally proposed. Option 2 is identical but returns null instead of the empty string if there is no extension. This is consistent with other methods in `Path` such as `getRoot()`, `getParent()`, and `getFileName()`. Option 3 allows the possibility to supply the value to be returned if no extension is found. Option 4 wraps the extension string or `null` in an `Optional`.
> 
> If one wanted to be able to retain the internal structure of the extension as a `Path`, then one could instead define two methods:
> 
> `Path Path.getExtension()`
> `String Path.getExtensionString()`
> 
> as part of the point is the user not being obliged to call `toString()`. Here `getExtension()` would be implemented in the platform-specific `Path` classes, and `getExtensionString()` would be a default method in the `Path` interface.
> 
> In all cases, when the `Path` represents a root component, then the extension is indeterminate (empty or `null`, depending).

Thanks for listing down the options. We'll need to spend more time working through potential use cases and narrow down the possible APIs. Having a default value or Optional.orElse has some appeal to cover the cases where the Path does not have a file name or extension.

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

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

From sebastian.stenzel at gmail.com  Wed Feb  3 15:49:26 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Wed, 3 Feb 2021 16:49:26 +0100
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <6f063488-5fb6-df44-a874-f48293c6e1f0@oracle.com>
References: <6f063488-5fb6-df44-a874-f48293c6e1f0@oracle.com>
Message-ID: <8850DBCF-8DC6-4046-93B2-3EC6FB05D098@gmail.com>


> Am 03.02.2021 um 15:03 schrieb Alan Bateman <Alan.Bateman at oracle.com>:
> 
> Also moving/combining files and significantly changing them at the same time means the diffs are harder to read.

Just to save you some time: the PR has three separate commits, the first of them purely focused on moving stuff between files, actual code changes are in the two later commits.

I forgot to mention that.

From github.com+828220+forax at openjdk.java.net  Wed Feb  3 16:45:41 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 3 Feb 2021 16:45:41 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <CZmzVTBo1trr6iszJ1jXBV6bqdrHCV-yFh51G3v2xnE=.e1464303-c814-456a-be55-1aba109ea614@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
 <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>
 <rBp2Pky0zSQy1A97BNYkebti1t76mi--1FhgSZQPOng=.85e5a00d-dc78-4450-8839-6221c1260185@github.com>
 <CZmzVTBo1trr6iszJ1jXBV6bqdrHCV-yFh51G3v2xnE=.e1464303-c814-456a-be55-1aba109ea614@github.com>
Message-ID: <A7aHrjGrqzGwB4iDL1lsfgvCKcaNOAVU_pYbi56CwII=.1ef8c891-0f29-4d50-b1f0-4b40d4f8e3b3@github.com>

On Wed, 3 Feb 2021 15:29:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> **Alternate Specifications**
>> 
>> Alternate specifications are possible. Ignoring more precise naming, e.g., `getExtensionOrElseEmptyString()` for the original version above, some possible options are:
>> 
>> 1. `String getExtension(`) returns the extension or the empty string if no extension found
>> 2. `String getExtension()` returns the extension or `null` if no extension found
>> 3. `String getExtension(String default)` returns the extension or `default` if no extension found (may be `null`)
>> 4. `Optional<String> getExtension()` returns the extension, if any, contained in an `Optional`
>> 
>> Option 1 is that originally proposed. Option 2 is identical but returns null instead of the empty string if there is no extension. This is consistent with other methods in `Path` such as `getRoot()`, `getParent()`, and `getFileName()`. Option 3 allows the possibility to supply the value to be returned if no extension is found. Option 4 wraps the extension string or `null` in an `Optional`.
>> 
>> If one wanted to be able to retain the internal structure of the extension as a `Path`, then one could instead define two methods:
>> 
>> `Path Path.getExtension()`
>> `String Path.getExtensionString()`
>> 
>> as part of the point is the user not being obliged to call `toString()`. Here `getExtension()` would be implemented in the platform-specific `Path` classes, and `getExtensionString()` would be a default method in the `Path` interface.
>> 
>> In all cases, when the `Path` represents a root component, then the extension is indeterminate (empty or `null`, depending).
>
> Thanks for listing down the options. We'll need to spend more time working through potential use cases and narrow down the possible APIs. Having a default value or Optional.orElse has some appeal to cover the cases where the Path does not have a file name or extension.

Using an Optional forces a user to read the javadoc (or worst guess), so i'm not sure it's a good idea to use it here because most people will just want the extension not a long speech about the filename being potentially null.

For me using "" when the extension doesn't exist whatever the reason is more pragmatic.

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

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

From rriggs at openjdk.java.net  Wed Feb  3 17:52:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 3 Feb 2021 17:52:47 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <A7aHrjGrqzGwB4iDL1lsfgvCKcaNOAVU_pYbi56CwII=.1ef8c891-0f29-4d50-b1f0-4b40d4f8e3b3@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
 <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>
 <rBp2Pky0zSQy1A97BNYkebti1t76mi--1FhgSZQPOng=.85e5a00d-dc78-4450-8839-6221c1260185@github.com>
 <CZmzVTBo1trr6iszJ1jXBV6bqdrHCV-yFh51G3v2xnE=.e1464303-c814-456a-be55-1aba109ea614@github.com>
 <A7aHrjGrqzGwB4iDL1lsfgvCKcaNOAVU_pYbi56CwII=.1ef8c891-0f29-4d50-b1f0-4b40d4f8e3b3@github.com>
Message-ID: <5fL5lxIxwbuUOHNNNy0HdLA7aGQrm2sFlI__8K40pR4=.58429046-4783-4b6e-a3ff-4c1f3b3eedb6@github.com>

On Wed, 3 Feb 2021 16:42:39 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Thanks for listing down the options. We'll need to spend more time working through potential use cases and narrow down the possible APIs. Having a default value or Optional.orElse has some appeal to cover the cases where the Path does not have a file name or extension.
>
> Using an Optional forces a user to read the javadoc (or worst guess), so i'm not sure it's a good idea to use it here because most people will just want the extension not a long speech about the filename being potentially null.
> 
> For me using "" when the extension doesn't exist whatever the reason is more pragmatic.

Choice 3, the equivalent of getOrDefault, is compact and exposes explicitly the case where no extension is present with very little overhead.

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

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

From kustos at gmx.net  Wed Feb  3 20:02:08 2021
From: kustos at gmx.net (Philippe Marschall)
Date: Wed, 3 Feb 2021 21:02:08 +0100
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <addf994f-ee6a-c9f7-535e-50f1dce454f7@gmx.net>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
 <addf994f-ee6a-c9f7-535e-50f1dce454f7@gmx.net>
Message-ID: <a8f94169-9953-e511-572e-e87788dfa592@gmx.net>



On 17.01.21 18:48, Philippe Marschall wrote:
> ...
>
> To be honest backing out of the StreamDecoder changes looks like a good
> comprise to me to reduce the risk while still improving throughput and
> reducing allocation rate, especially in the on-heap path.

I gave it some more thought and propose to back out of the StreamDecoder
changes. While that leaves some optimization potential unused it keeps
the patch smaller, the risk lower and avoids any throughput regressions.

> Looking a bit further I wonder if CharArrayReader and StringReader
> should implement #read(CharBuffer) as well and call CharBuffer#put
> directly. And maybe even #transferTo(Writer).

I did have a look at this [1] for coders LATIN1(0) and UTF16(1) as well
as 128 and 1024 char sized readers for both on- and off-heap buffers.

CharArrayReader#read(CharBuffer)

on-heap
Higher throughput than master but slightly lower throughput than the
current PR. I don? t know why that is, maybe the additional checks in
CharBuffer show up here.

off-heap
Higher throughput than master or the PR, all intermediate allocation is
gone.

StringReader#read(CharBuffer)

on-heap
Higher throughput than master but slightly lower throughput than the
current PR. I don? t know why that is, maybe the additional checks in
CharBuffer show up here. The situation is similar to CharArrayReader.


off-heap
Lower throughput but all intermediate allocation is gone. What shows up
here is the lack of an optimized #put(String) method for off-heap
CharBuffers like was done in JDK-8011135 for on-heap buffers.

Based on this is propose to add CharArrayReader#read(CharBuffer),
assuming it is still in the scope of the bug. I wouldn't add
StringReader#read(CharBuffer) due to the throughput regression. I think
#transferTo(Writer) would be out of the scope of the bug. Is that ok?

  [1]
https://github.com/marschall/reader-benchmarks/blob/master/src/main/java/com/github/marschall/readerbenchmarks/CharsequenceReaderBenchmarks.java

Cheers
Philippe

From mli at openjdk.java.net  Thu Feb  4 08:14:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 08:14:41 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case
In-Reply-To: <Soo652LfwozalX36p2w2Ggba_I1GYgMeNkG2yfDOfbU=.e77ae223-0c87-4b6b-9f94-2be61ef5e67c@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <lK6op_K6p4UTYWK8tVi1W04fc0vQQnIEcEPcZhKtHvM=.18a486ac-e1d0-480d-8f52-4ee9deb5541a@github.com>
 <Soo652LfwozalX36p2w2Ggba_I1GYgMeNkG2yfDOfbU=.e77ae223-0c87-4b6b-9f94-2be61ef5e67c@github.com>
Message-ID: <QXDl04G_jXTqd7pc6bWSSmOgUiETu_O3vVz8d1iC-rk=.c68eeb22-5b5a-4871-9eac-54c8aaa75b94@github.com>

On Wed, 3 Feb 2021 05:30:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> interesting, why it keeps failing? I just modified the javadoc in the patch. is this an environment issue?
>
> @AlanBateman @bplb Hi Alan, Brian, do you know how can I avoid the failures in pre-submit tests? I don't think my patch will introduce the failures, any clue or suggestion?
> Thanks

Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks

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

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

From hedongbo at huawei.com  Thu Feb  4 08:55:08 2021
From: hedongbo at huawei.com (hedongbo)
Date: Thu, 4 Feb 2021 08:55:08 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
 <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com> 
Message-ID: <8FC616E5EC1A774287430B1CC2696FE3047164BE@dggeml513-mbx.china.huawei.com>

Hi Alan, is this 8u webrev ok? I saw that you said patch was fine in the last email, so I added jdk8u-fix-request label to JDK-6878250, but Andrew said that the patch had not been reviewed. Do I need to make any modifications to the patch?


webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/

bug: https://bugs.openjdk.java.net/browse/JDK-6878250


Thanks,
dongbohe

From: hedongbo
Sent: Wednesday, February 3, 2021 6:44 PM
To: 'Alan Bateman' <Alan.Bateman at oracle.com>
Cc: nio-dev at openjdk.java.net
Subject: RE: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws IllegalBlockingModeException on closed channel


Thank you for your review, Alan.



I changed the bug to JDK-6878250, and added jdk8-fix label on JDK-6878250

webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/

bug: https://bugs.openjdk.java.net/browse/JDK-6878250



At the same time, I have sent an email to jdk-updates-dev to backport JDK-8246707 to jdk11u



Thanks,
dongbohe

From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Wednesday, February 3, 2021 1:23 AM
To: hedongbo <hedongbo at huawei.com<mailto:hedongbo at huawei.com>>; nio-dev at openjdk.java.net<mailto:nio-dev at openjdk.java.net>
Subject: Re: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws IllegalBlockingModeException on closed channel

On 02/02/2021 09:33, hedongbo wrote:
Yes, I want to fix this on 8. Webrev is also for 8.
Backport JDK-8246707 to 11 can solve this problem in 11, and I am doing this backport.

Okay. Feel free to re-open JDK-8260875 if it easier for you. I'm not involved in JDK updates so you'll need to follow the process for the updates releases (the patch to SocketAdaptor in your patch is fine).

JDK-8246707 is a different issue. This is the throwing of AsynchronousCloseException instead of ClosedClosedException which can be confusing. That could be fixed in 11u, should not be an issue in 8u.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210204/93f00b1a/attachment.htm>

From mli at openjdk.java.net  Thu Feb  4 12:05:07 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 12:05:07 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v4]
In-Reply-To: <UFWKK7Ycsf1QDfP6vPUw3Q6mgcKtw3MNod21CcRGA9s=.66f82b84-8bdf-4b8f-9d9d-4abf140e0764@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <YXaa2BXgT7rGwRH7FDrbBFvjQGNxIXg-9eycC4zzBnU=.829dede5-6878-49dc-9a54-cc37b6ad42bc@github.com>
 <UFWKK7Ycsf1QDfP6vPUw3Q6mgcKtw3MNod21CcRGA9s=.66f82b84-8bdf-4b8f-9d9d-4abf140e0764@github.com>
Message-ID: <NW1kRJLYvxAsot4h6wNe7W3RmvvOEhEjhVwOk9Pv2XU=.5cd0926a-37a2-489a-a32c-5d22ce28bf19@github.com>

On Wed, 3 Feb 2021 14:07:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 646:
> 
>> 644:      * and has fewer than {@code count} bytes immediately available in its
>> 645:      * input buffer. No bytes are transferred if the source channel has reached
>> 646:      * the end-of-stream in which case zero will be returned.
> 
> Thanks for dropping the apiNote that mentions -1 and return value.
> 
> The update is mostly okay, I might re-word it slightly to "No bytes are transferred, and zero is returned, if the source has reached end-of-stream".

Thanks Alan, just modified as you suggested, I think it's better.

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

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

From mli at openjdk.java.net  Thu Feb  4 12:05:06 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Feb 2021 12:05:06 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v5]
In-Reply-To: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
Message-ID: <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>

> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
> 
> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

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

  JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2329/files
  - new: https://git.openjdk.java.net/jdk/pull/2329/files/b9ab224f..5039f264

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

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

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

From Alan.Bateman at oracle.com  Thu Feb  4 14:06:16 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 4 Feb 2021 14:06:16 +0000
Subject: [EXTERNAL] Re: Bug in Files.isSameFile(Path,Path)
In-Reply-To: <DM5PR21MB17842C1750584B4DE5DE2FC0A6B59@DM5PR21MB1784.namprd21.prod.outlook.com>
References: <31383fa0-ba8f-1e29-8d3a-950f34c724b0@freedom.nl>
 <AM6PR03MB4389E24F6BB9C9933889D997FF1A0@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <505f6548-382b-f85c-bc89-b70bfae9e294@freedom.nl>
 <DM6PR21MB1468569CDF508EF079122F08F51A0@DM6PR21MB1468.namprd21.prod.outlook.com>
 <828f16b7-c438-9827-70fa-49ac15fcb20f@oracle.com>
 <DM6PR21MB1641EAEC982B4450AF1F878BA6140@DM6PR21MB1641.namprd21.prod.outlook.com>
 <ba999d5a-564c-cb61-14bb-519190e3fab0@oracle.com>
 <DM6PR21MB1468A315AFEF45B14A2AB53EF5140@DM6PR21MB1468.namprd21.prod.outlook.com>
 <BN7PR21MB163613BBB01CC8863AA1547AA6100@BN7PR21MB1636.namprd21.prod.outlook.com>
 <0fb92dd2-7319-25ed-2d74-74445dc5aa8a@oracle.com>
 <DM6PR21MB1641267734BB6A8375113DD1A6EF0@DM6PR21MB1641.namprd21.prod.outlook.com>
 <b581a793-6cb9-f8db-5592-d70637dab746@oracle.com>
 <MW2PR2101MB181769932B678AD5676810B7A6E60@MW2PR2101MB1817.namprd21.prod.outlook.com>
 <DM5PR21MB17842C1750584B4DE5DE2FC0A6B59@DM5PR21MB1784.namprd21.prod.outlook.com>
Message-ID: <07354b86-316b-c4b2-5a27-dd143d2ba80d@oracle.com>

On 02/02/2021 21:56, Nhat Nguyen wrote:
> Hi Alan,
>
> It has been a while since we last had this conversation. I just want to ask if
> you are still interested in investigating more into this issue?
>
Thanks for the reminder. Yes, it would be great to continue the 
investigation if you have the cycles.

I think we were in agreement to re-implement isSameFile. If we can move 
away from checking volume/file IDs with GetFinalPathNameByHandle then 
that would be great but I think we need to make sure that it doesn't 
introduce any inconsistencies with toRealPath. I think we also want to 
make sure that the approach works with as many different file systems as 
there is a history of problems with some configurations (CIFS servers, 
SAMBA, WebDAV, ...). There was also discussion on use 64-bit file IDs 
and GetFileInformationByHandleEx so that would be good to explore too. 
Our discussion touched on having a fallback approach too but it would be 
nice not to need that, partly because it would be code that isn't 
exercised during regular testing.

-Alan.



From alanb at openjdk.java.net  Thu Feb  4 14:14:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 4 Feb 2021 14:14:39 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v5]
In-Reply-To: <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
Message-ID: <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>

On Thu, 4 Feb 2021 12:05:06 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
>> 
>> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case

Marked as reviewed by alanb (Reviewer).

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

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

From Alan.Bateman at oracle.com  Thu Feb  4 14:22:41 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 4 Feb 2021 14:22:41 +0000
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <8850DBCF-8DC6-4046-93B2-3EC6FB05D098@gmail.com>
References: <6f063488-5fb6-df44-a874-f48293c6e1f0@oracle.com>
 <8850DBCF-8DC6-4046-93B2-3EC6FB05D098@gmail.com>
Message-ID: <72a6ab84-8bfd-6116-8493-9b02da11c27d@oracle.com>


On 03/02/2021 15:49, Sebastian Stenzel wrote:
>
> Just to save you some time: the PR has three separate commits, the first of them purely focused on moving stuff between files, actual code changes are in the two later commits.
>
> I forgot to mention that.
Ack! I will try to look at it more closely in the next few days.

-Alan

From alanb at openjdk.java.net  Thu Feb  4 14:23:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 4 Feb 2021 14:23:42 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v5]
In-Reply-To: <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
Message-ID: <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>

On Thu, 4 Feb 2021 14:11:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to better describe "no bytes available" case
>
> Marked as reviewed by alanb (Reviewer).

> Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks

Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".

> BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.

Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.

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

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

From Alan.Bateman at oracle.com  Thu Feb  4 14:31:04 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 4 Feb 2021 14:31:04 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE3047164BE@dggeml513-mbx.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
 <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE3047164BE@dggeml513-mbx.china.huawei.com>
Message-ID: <f5d4bcc7-6bc7-a51b-c49e-3690d8ccff94@oracle.com>

On 04/02/2021 08:55, hedongbo wrote:
>
> Hi Alan, is this 8u webrev ok? I saw that you said patch was fine in 
> the last email, so I added jdk8u-fix-request label to JDK-6878250, but 
> Andrew said that the patch had not been reviewed. Do I need to make 
> any modifications to the patch?
>
> webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/ 
> <http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/>
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6878250 
> <https://bugs.openjdk.java.net/browse/JDK-6878250>
>
>
I'm not involved the JDK 8 update releases. The update to 
SocketAdaptor.java is good for JDK-6878250. The test in the webrev isn't 
testing the right scenario. Also if the thread created by 
testReadAfterClose throws an exception then it's not communicated to the 
main thread. To create the scenario you need to configure the 
SocketChannel to be non-blocking, close it, then check that 
ClosedChannelException is thrown.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210204/e9da8086/attachment.htm>

From roger.riggs at oracle.com  Thu Feb  4 14:57:47 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 4 Feb 2021 09:57:47 -0500
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <f5d4bcc7-6bc7-a51b-c49e-3690d8ccff94@oracle.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
 <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE3047164BE@dggeml513-mbx.china.huawei.com>
 <f5d4bcc7-6bc7-a51b-c49e-3690d8ccff94@oracle.com>
Message-ID: <551e3701-24f5-f21c-06d4-9c3c3006b727@oracle.com>

Reviews for 8u are done on a different email list:

 ??? jdk-updates-dev at openjdk.java.net

Regards, Roger


On 2/4/21 9:31 AM, Alan Bateman wrote:
> On 04/02/2021 08:55, hedongbo wrote:
>>
>> Hi Alan, is this 8u webrev ok? I saw that you said patch was fine in 
>> the last email, so I added jdk8u-fix-request label to JDK-6878250, 
>> but Andrew said that the patch had not been reviewed. Do I need to 
>> make any modifications to the patch?
>>
>> webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/ 
>> <http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-6878250 
>> <https://bugs.openjdk.java.net/browse/JDK-6878250>
>>
>>
> I'm not involved the JDK 8 update releases. The update to 
> SocketAdaptor.java is good for JDK-6878250. The test in the webrev 
> isn't testing the right scenario. Also if the thread created by 
> testReadAfterClose throws an exception then it's not communicated to 
> the main thread. To create the scenario you need to configure the 
> SocketChannel to be non-blocking, close it, then check that 
> ClosedChannelException is thrown.
>
> -Alan

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

From mli at openjdk.java.net  Fri Feb  5 00:51:40 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Feb 2021 00:51:40 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v5]
In-Reply-To: <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
 <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
Message-ID: <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>

On Thu, 4 Feb 2021 14:20:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks
> 
> Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".
> 
Thanks Alan, just finalized it.
> > BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.
> 
> Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.
Got it.

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

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

From hedongbo at huawei.com  Fri Feb  5 02:18:20 2021
From: hedongbo at huawei.com (hedongbo)
Date: Fri, 5 Feb 2021 02:18:20 +0000
Subject: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws
 IllegalBlockingModeException on closed channel
In-Reply-To: <551e3701-24f5-f21c-06d4-9c3c3006b727@oracle.com>
References: <8FC616E5EC1A774287430B1CC2696FE30470B0BC@dggeml513-mbx.china.huawei.com>
 <9ecdf89d-3e31-3fb0-f9bf-0d5d9eed28fe@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE30470B56B@dggeml513-mbx.china.huawei.com>
 <a43bc8c2-b7a4-6d9d-f5a1-3a67504f7111@oracle.com>
 <8FC616E5EC1A774287430B1CC2696FE3047164BE@dggeml513-mbx.china.huawei.com>
 <f5d4bcc7-6bc7-a51b-c49e-3690d8ccff94@oracle.com>
 <551e3701-24f5-f21c-06d4-9c3c3006b727@oracle.com>
Message-ID: <8FC616E5EC1A774287430B1CC2696FE304718572@dggeml513-mbx.china.huawei.com>

Thanks Alan and Roger for your advice.


Thanks,
dongbohe

From: Roger Riggs [mailto:roger.riggs at oracle.com]
Sent: Thursday, February 4, 2021 10:58 PM
To: hedongbo <hedongbo at huawei.com>
Cc: nio-dev at openjdk.java.net
Subject: Re: RFR: 8260875 (sc)SocketAdaptor$SocketInputStream read throws IllegalBlockingModeException on closed channel

Reviews for 8u are done on a different email list:

    jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>

Regards, Roger

On 2/4/21 9:31 AM, Alan Bateman wrote:
On 04/02/2021 08:55, hedongbo wrote:

Hi Alan, is this 8u webrev ok? I saw that you said patch was fine in the last email, so I added jdk8u-fix-request label to JDK-6878250, but Andrew said that the patch had not been reviewed. Do I need to make any modifications to the patch?


webrev: http://cr.openjdk.java.net/~dongbohe/6878250/webrev.00/

bug: https://bugs.openjdk.java.net/browse/JDK-6878250

I'm not involved the JDK 8 update releases. The update to SocketAdaptor.java is good for JDK-6878250. The test in the webrev isn't testing the right scenario. Also if the thread created by testReadAfterClose throws an exception then it's not communicated to the main thread. To create the scenario you need to configure the SocketChannel to be non-blocking, close it, then check that ClosedChannelException is thrown.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210205/bd252ad1/attachment.htm>

From michaelm at openjdk.java.net  Fri Feb  5 09:58:55 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 5 Feb 2021 09:58:55 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix domain
 sockets
Message-ID: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>

Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.

The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.

Thanks,
Michael

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

Commit messages:
 - update
 - update
 - update
 - update
 - update after Alan's first review
 - Merge branch 'master' into 8252971-socket-attributes
 - test update
 - initial fix for review

Changes: https://git.openjdk.java.net/jdk/pull/2424/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2424&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252971
  Stats: 241 lines in 8 files changed: 226 ins; 9 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424

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

From dfuchs at openjdk.java.net  Fri Feb  5 12:06:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 5 Feb 2021 12:06:44 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <wirN28T4X5jn4q5kS-3CbfsgvYOc4AEJ6RWAeFr2Fqk=.05ddb819-5b41-4be2-bca4-ba94eb58e8df@github.com>

On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

test/jdk/java/nio/channels/unixdomain/FileAttributes.java line 82:

> 80: 
> 81:             // Check deletion
> 82:             assertTrue(f.delete(), "File.delete failed");

What happens to the socket if you delete the file before closing the socket? Isn't that going to cause trouble?

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

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

From michaelm at openjdk.java.net  Fri Feb  5 12:10:42 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 5 Feb 2021 12:10:42 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets
In-Reply-To: <wirN28T4X5jn4q5kS-3CbfsgvYOc4AEJ6RWAeFr2Fqk=.05ddb819-5b41-4be2-bca4-ba94eb58e8df@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <wirN28T4X5jn4q5kS-3CbfsgvYOc4AEJ6RWAeFr2Fqk=.05ddb819-5b41-4be2-bca4-ba94eb58e8df@github.com>
Message-ID: <syjn_SJDLZDgHeXPNnalvdGTi_DCAPNREpCjhN3SI6s=.e1518eed-c020-44a8-8dae-6b74515f9ade@github.com>

On Fri, 5 Feb 2021 12:03:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> test/jdk/java/nio/channels/unixdomain/FileAttributes.java line 82:
> 
>> 80: 
>> 81:             // Check deletion
>> 82:             assertTrue(f.delete(), "File.delete failed");
> 
> What happens to the socket if you delete the file before closing the socket? Isn't that going to cause trouble?

Deleting the file prevents new connections from being accepted, but doesn't cause any problems for the channel itself. Since the test is finished at that point I don't think there is a problem.

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

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

From dfuchs at openjdk.java.net  Fri Feb  5 12:40:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 5 Feb 2021 12:40:40 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <8o3-JUwwHvgrxB13p7pajzQeBBzu9WwoU-4__Ys-YNk=.9f963011-7352-4a6d-be81-2dd0f0669c8e@github.com>

On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

This look reasonable to me - but I am not an expert on windows native APIs.
The test seems good and comprehensive though - I particularly like the fact that it tests for `isDirectory`, `isRegularFile`, `isSymlink` and `isOther`, and that it verifies that the socket file can be deleted in the end.

Please wait for a second opinion before integrating.
Also consider whether to write a release note - since you re-enabling support for some versions of Windows for which it was disabled.

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

Marked as reviewed by dfuchs (Reviewer).

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

From michaelm at openjdk.java.net  Fri Feb  5 22:28:10 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 5 Feb 2021 22:28:10 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

 - Merge branch 'master' into 8252971-socket-attributes
 - update
 - update
 - update
 - update
 - update after Alan's first review
 - Merge branch 'master' into 8252971-socket-attributes
 - test update
 - initial fix for review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/fb6c719d..b61686f4

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

  Stats: 10870 lines in 557 files changed: 6876 ins; 2384 del; 1610 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424

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

From alanb at openjdk.java.net  Sat Feb  6 17:15:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 6 Feb 2021 17:15:52 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
Message-ID: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>

On Fri, 5 Feb 2021 22:28:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - update
>  - update
>  - update
>  - update after Alan's first review
>  - Merge branch 'master' into 8252971-socket-attributes
>  - test update
>  - initial fix for review

The changes are a bit disruptive but I agree are necessary to improve the experience when socket files are encountered on the file system. I have focused on the changes to the implementation, I see Daniel is focused on the test so I only lightly skimmed that.

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344:

> 342:                                 Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT),
> 343:                                 0L);
> 344:                     fc.close();

checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on.

Minor nit is the params to newFileChannel is are mis-aligned now.

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 866:

> 864: 
> 865:         try {
> 866:             // needs one additional flag to open a Unix domain socket

The comment here is confusing as there are two flags.

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 859:

> 857: 
> 858:     /**
> 859:      * returns INVALID_HANDLE_VALUE if path is not a socket

Can you change this to "Returns".

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

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

From michaelm at openjdk.java.net  Sat Feb  6 20:38:45 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sat, 6 Feb 2021 20:38:45 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
 <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
Message-ID: <A1Pso96tDpq-lDjkfIC8YHkxa-EB5HD-RDiOMwV1TE4=.f5457aaf-4b8a-496e-978e-c5f5addeceff@github.com>

On Sat, 6 Feb 2021 17:09:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - update
>>  - update
>>  - update
>>  - update
>>  - update after Alan's first review
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - test update
>>  - initial fix for review
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344:
> 
>> 342:                                 Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT),
>> 343:                                 0L);
>> 344:                     fc.close();
> 
> checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on.
> 
> Minor nit is the params to newFileChannel is are mis-aligned now.

So, if the reparse point is a symbolic link, and if the target of the link does not exist, then  ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible.

>From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time.

I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned.

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

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

From michaelm at openjdk.java.net  Sat Feb  6 20:44:41 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sat, 6 Feb 2021 20:44:41 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <A1Pso96tDpq-lDjkfIC8YHkxa-EB5HD-RDiOMwV1TE4=.f5457aaf-4b8a-496e-978e-c5f5addeceff@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
 <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
 <A1Pso96tDpq-lDjkfIC8YHkxa-EB5HD-RDiOMwV1TE4=.f5457aaf-4b8a-496e-978e-c5f5addeceff@github.com>
Message-ID: <B3zP2Ia_gqYGcBP7zld_qHtXqA10QRrAv1jszgzpWpk=.f0d61b0f-6fec-490b-bbbb-b75a60e99390@github.com>

On Sat, 6 Feb 2021 20:35:58 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 344:
>> 
>>> 342:                                 Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT),
>>> 343:                                 0L);
>>> 344:                     fc.close();
>> 
>> checkAccess follows sym links and I wonder if there is any scenario where ERROR_CANT_ACCESS_FILE can be returned when respare point rather than the target cannot be accessed. This may be something the Microsoft folks can comment on.
>> 
>> Minor nit is the params to newFileChannel is are mis-aligned now.
>
> So, if the reparse point is a symbolic link, and if the target of the link does not exist, then  ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible.
> 
> From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time.
> 
> I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned.

Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket.

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

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

From alanb at openjdk.java.net  Sun Feb  7 09:18:46 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 7 Feb 2021 09:18:46 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <B3zP2Ia_gqYGcBP7zld_qHtXqA10QRrAv1jszgzpWpk=.f0d61b0f-6fec-490b-bbbb-b75a60e99390@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
 <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
 <A1Pso96tDpq-lDjkfIC8YHkxa-EB5HD-RDiOMwV1TE4=.f5457aaf-4b8a-496e-978e-c5f5addeceff@github.com>
 <B3zP2Ia_gqYGcBP7zld_qHtXqA10QRrAv1jszgzpWpk=.f0d61b0f-6fec-490b-bbbb-b75a60e99390@github.com>
Message-ID: <IBomnXLWl5KAyRF95GCQslMcnkVV84SzkFMPvwyCbuk=.f8393694-94de-43f3-a5a3-53419dff1b7a@github.com>

On Sat, 6 Feb 2021 20:41:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> So, if the reparse point is a symbolic link, and if the target of the link does not exist, then  ERROR_FILE_NOT_FOUND is returned. I've tested and confirmed this. It's also what you would expect because you would expect usage of symbolic links to be transparent and the same error code to be returned as when traversing a path and some element of the path does not exist, or isn't accessible.
>> 
>> From what I can see ERROR_CANT_ACCESS_FILE can be returned for other reasons such as file corruption, which I think would be likely to return the same error again the second time.
>> 
>> I've also done some manual testing of other kinds of reparse point (junctions and mount points) and have tried various "target not existing" type of scenarios and ERROR_CANT_ACCESS_FILE is never returned.
>
> Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket.

Moving it to a separate method would make it easier to maintain and discuss here but I would really prefer if it checked the reparse tag and re-throw the original exception if the tag is IO_REPARSE_TAG_SYMLINK. That way it wouldn't get tripped up by ERROR_CANT_ACCESS_FILE being thrown for other reasons, e.g. sym link -> sym link -> target where an intermediate sym link can't be accessed.

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

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

From michaelm at openjdk.java.net  Sun Feb  7 19:08:02 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 7 Feb 2021 19:08:02 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <IBomnXLWl5KAyRF95GCQslMcnkVV84SzkFMPvwyCbuk=.f8393694-94de-43f3-a5a3-53419dff1b7a@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
 <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
 <A1Pso96tDpq-lDjkfIC8YHkxa-EB5HD-RDiOMwV1TE4=.f5457aaf-4b8a-496e-978e-c5f5addeceff@github.com>
 <B3zP2Ia_gqYGcBP7zld_qHtXqA10QRrAv1jszgzpWpk=.f0d61b0f-6fec-490b-bbbb-b75a60e99390@github.com>
 <IBomnXLWl5KAyRF95GCQslMcnkVV84SzkFMPvwyCbuk=.f8393694-94de-43f3-a5a3-53419dff1b7a@github.com>
Message-ID: <iFJwQlfJk1RaA3XWo92ySpqaAToYV04FH3L_89SDt3w=.af1f94a9-4ee6-4451-a171-7e5cd4302ac6@github.com>

On Sun, 7 Feb 2021 09:15:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Though looking at that piece of code, I think its purpose would be clearer if it were put in a separate method with a name that shows were trying to open it as a socket.
>
> Moving it to a separate method would make it easier to maintain and discuss here but I would really prefer if it checked the reparse tag and re-throw the original exception if the tag is IO_REPARSE_TAG_SYMLINK. That way it wouldn't get tripped up by ERROR_CANT_ACCESS_FILE being thrown for other reasons, e.g. sym link -> sym link -> target where an intermediate sym link can't be accessed.

Okay, I can add a check for WindowsFileAttributes.isUnixDomainSocket() in there when ERROR_CANT_ACCESS_FILE is returned.

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

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

From michaelm at openjdk.java.net  Sun Feb  7 19:08:02 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 7 Feb 2021 19:08:02 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v3]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <vVoJFHUq3IfauVDlkMcMf2jKj8ojNY_lDTOwR2UKbmE=.fffed7c7-5600-4cea-b77d-42b9eb1e7b20@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

  add specific check for unix domain socket

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/b61686f4..de2a3428

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

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

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

From michaelm at openjdk.java.net  Sun Feb  7 19:08:06 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 7 Feb 2021 19:08:06 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v2]
In-Reply-To: <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <gcdIS623PscJHH9XbZ6EAd8DAsm6Pdjx-6J4fv2CdAE=.f41c1d1a-cf25-4272-8115-eca6f479e77e@github.com>
 <0sDBzdG9eNsx5oCHRe4UJ3vnT2XmtLY2fOnhwM42uVU=.290589f2-fd20-4463-b5d1-fd0855638271@github.com>
Message-ID: <sINKYnDcmGBU2boxG6xC4nc3QR76XvEf96sdFdJzO2s=.b9e450c5-c4e4-4fce-8e9e-6fe9e94fd007@github.com>

On Sat, 6 Feb 2021 17:10:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - update
>>  - update
>>  - update
>>  - update
>>  - update after Alan's first review
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - test update
>>  - initial fix for review
>
> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 866:
> 
>> 864: 
>> 865:         try {
>> 866:             // needs one additional flag to open a Unix domain socket
> 
> The comment here is confusing as there are two flags.

Okay

> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 859:
> 
>> 857: 
>> 858:     /**
>> 859:      * returns INVALID_HANDLE_VALUE if path is not a socket
> 
> Can you change this to "Returns".

Okay

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

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

From michaelm at openjdk.java.net  Sun Feb  7 20:16:08 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 7 Feb 2021 20:16:08 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v4]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <yRqdqOYEpW-UqyX09lLSd7CCaGhEJw2_M4M7ogXOOdA=.6e2d333b-94b5-4bdd-9db0-7fe949079a01@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

 - Merge branch 'master' into 8252971-socket-attributes
 - add specific check for unix domain socket
 - Merge branch 'master' into 8252971-socket-attributes
 - update
 - update
 - update
 - update
 - update after Alan's first review
 - Merge branch 'master' into 8252971-socket-attributes
 - test update
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/fa59fe8c...746b4762

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/de2a3428..746b4762

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

  Stats: 2471 lines in 59 files changed: 1349 ins; 861 del; 261 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424

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

From alanb at openjdk.java.net  Mon Feb  8 14:06:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 8 Feb 2021 14:06:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

src/java.management/share/classes/javax/management/loading/MLet.java line 1147:

> 1145:                                       .toFile();
> 1146:                      file.deleteOnExit();
> 1147:                      Files.copy(is, file.toPath());

One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code).

The code that follows checks if the file exists, this will always be true when Files.copy succeeds.

src/java.base/share/classes/sun/net/www/MimeLauncher.java line 2:

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

Is MimeEntry.launch still used? I'm wondering if the MimeLauncher can be deleted.

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

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

From weijun at openjdk.java.net  Mon Feb  8 14:42:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 8 Feb 2021 14:42:44 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

The other security-related code changes look good to me.

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49:

> 47:         throws IOException
> 48:     {
> 49:         return is.readAllBytes();

This is also from Apache Santuario. It's better to keep it unchanged.

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

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

From jboes at openjdk.java.net  Mon Feb  8 16:21:56 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 8 Feb 2021 16:21:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
Message-ID: <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>

On Mon, 21 Dec 2020 08:19:08 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov 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.

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29:

> 27: 
> 28: import java.io.ByteArrayInputStream;
> 29: import java.io.IOException;

The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable.

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

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

From jboes at openjdk.java.net  Mon Feb  8 16:42:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 8 Feb 2021 16:42:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
Message-ID: <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>

On Mon, 8 Feb 2021 14:40:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> The other security-related code changes look good to me.

I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk

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

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

From alanb at openjdk.java.net  Mon Feb  8 16:52:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 8 Feb 2021 16:52:50 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v4]
In-Reply-To: <yRqdqOYEpW-UqyX09lLSd7CCaGhEJw2_M4M7ogXOOdA=.6e2d333b-94b5-4bdd-9db0-7fe949079a01@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <yRqdqOYEpW-UqyX09lLSd7CCaGhEJw2_M4M7ogXOOdA=.6e2d333b-94b5-4bdd-9db0-7fe949079a01@github.com>
Message-ID: <Bf4xWq2UoEKrmJPuhIDN4JY5EyvNEjcU5OfM-rISPwI=.16a53d80-8fc1-4965-a803-e4cead398465@github.com>

On Sun, 7 Feb 2021 20:16:08 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252971-socket-attributes
>  - add specific check for unix domain socket
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - update
>  - update
>  - update
>  - update after Alan's first review
>  - Merge branch 'master' into 8252971-socket-attributes
>  - test update
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/77ac60d6...746b4762

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 346:

> 344:                                 Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT),
> 345:                                 0L);
> 346:                     fc.close();

The new version looks a bit strange. As I read it, the attempt to open the file fails with ERROR_CANT_ACCESS_FILE so you then check test if the file is a socket file. That succeeds so we should be done. What is the reason for opening the file again?

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 862:

> 860:      * and a handle to the socket file if it is.
> 861:      */
> 862:     private long openSocketForReadAttributeAccess() {

The methods here throw WindowsException when they fail and might be better to keep it consistent and throw WindowsException rather than returning INVALID_HANDLE_VALUE.

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

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

From alanb at openjdk.java.net  Mon Feb  8 17:14:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 8 Feb 2021 17:14:43 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v3]
In-Reply-To: <xvL_q_NXNaVl-hZKEzDZ4CZJwlc4mblaNF5GbUGcCns=.0a8a8481-947e-4b2a-bcae-d2f183204c44@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
 <xvL_q_NXNaVl-hZKEzDZ4CZJwlc4mblaNF5GbUGcCns=.0a8a8481-947e-4b2a-bcae-d2f183204c44@github.com>
Message-ID: <_V1p_UmLJrmyxo3lEwVkiT54WdV1bYbKxio9EBb3mQo=.3fa1ec34-7c34-4bcf-ae33-eff452627c60@github.com>

On Wed, 27 Jan 2021 19:32:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8129776: Wire up MappedByteBuffer.unmapper().unmap()

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java line 97:

> 95:     // closed before traversal.  If the count is zero after decrementing, then
> 96:     // the buffer is unmapped.
> 97:     private AtomicInteger bufRefCount;

This should be final but otherwise the changes are okay..

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

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

From bpb at openjdk.java.net  Mon Feb  8 19:50:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Feb 2021 19:50:58 GMT
Subject: RFR: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed [v4]
In-Reply-To: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
Message-ID: <bXDs_LVYvCUW3nIdjznhG75iAiQxpJdhzeaLGSLsTtk=.f1a71ca0-f174-4589-9046-ac9020d5c387@github.com>

> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.

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

  8129776: Make bufRefCount AtomicInteger final

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2229/files
  - new: https://git.openjdk.java.net/jdk/pull/2229/files/e2b0219f..95fdac07

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:50:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:50:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>
Message-ID: <BdQsbXFMxgTxyaKoAeQOdJ-52AnWCrUUUmKQe_ilUaY=.74983229-9463-43a0-ac22-8ae2c48ca0fe@github.com>

On Mon, 8 Feb 2021 14:01:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 1147:
> 
>> 1145:                                       .toFile();
>> 1146:                      file.deleteOnExit();
>> 1147:                      Files.copy(is, file.toPath());
> 
> One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code).
> 
> The code that follows checks if the file exists, this will always be true when Files.copy succeeds.

fixed

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:54:48 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:54:48 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
Message-ID: <xIcOD_gjq-dnpKfNpMGm13Uax_5YLkZtatTYWgtBpGc=.78ab950f-b902-4dee-8545-9d0574d75cef@github.com>

On Mon, 8 Feb 2021 14:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49:
> 
>> 47:         throws IOException
>> 48:     {
>> 49:         return is.readAllBytes();
> 
> This is also from Apache Santuario. It's better to keep it unchanged.

reverted

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:54:47 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:54:47 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v7]
In-Reply-To: <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
 <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>
Message-ID: <NDGqsqvKpgvsi0OCV7briRodMEnNwFVseA72F4zbCG0=.5c9554cb-5116-4467-82dd-d919ed4fe5f3@github.com>

On Mon, 8 Feb 2021 16:19:17 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> Andrey Turbanov 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.
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29:
> 
>> 27: 
>> 28: import java.io.ByteArrayInputStream;
>> 29: import java.io.IOException;
> 
> The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable.

done

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:58:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:58:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/94e99817..6a8a3ae6

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

  Stats: 29 lines in 10 files changed: 16 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+471021+marschall at openjdk.java.net  Mon Feb  8 21:21:44 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 8 Feb 2021 21:21:44 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
Message-ID: <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>

On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   fix review comments

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230:

> 228:                 // Copy the entire input stream into an InputStream that does
> 229:                 // support mark
> 230:                 is = new ByteArrayInputStream(is.readAllBytes());

I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do:

PKCS7 pkcs7 = new PKCS7(is.readAllBytes());

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

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

From bpb at openjdk.java.net  Mon Feb  8 21:46:56 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Feb 2021 21:46:56 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5]
In-Reply-To: <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com>
Message-ID: <zjSsxP6j0YOpO8fX6K5p3DXbxiHWb9IrnvfAa8mavLg=.9c708009-9580-483c-9693-43c4eb2051b5@github.com>

On Tue, 26 Jan 2021 18:22:02 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit amount read to avoid BufferOverflowException
>   
>   - limit the amount read
>   - add tests

src/java.base/share/classes/java/io/Reader.java line 194:

> 192:             nread = this.read(cbuf, off, len);
> 193:             if (nread > 0)
> 194:                 target.position(target.position() + nread);

As `target` is mutable, I think you would do better to change lines 189-194 to something like:
            char cbuf[] = target.array();
            int pos = target.position();
            int rem = target.limit() - pos;
            if (rem <= 0)
                return -1;
            int off = target.arrayOffset() + pos;
            nread = this.read(cbuf, off, rem);
            if (nread > 0)
                target.position(pos + nread);

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

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

From bpb at openjdk.java.net  Mon Feb  8 21:46:55 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Feb 2021 21:46:55 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
In-Reply-To: <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>
Message-ID: <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com>

On Tue, 5 Jan 2021 17:44:20 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

src/java.base/share/classes/java/io/Reader.java line 198:

> 196:         } else {
> 197:             int remaining = target.remaining();
> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];

As `cbuf` for the off-heap case is used in a synchronized block, is there the opportunity for some sort of cached array here and would it help?

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

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

From michaelm at openjdk.java.net  Mon Feb  8 21:51:44 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 8 Feb 2021 21:51:44 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v4]
In-Reply-To: <Bf4xWq2UoEKrmJPuhIDN4JY5EyvNEjcU5OfM-rISPwI=.16a53d80-8fc1-4965-a803-e4cead398465@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <yRqdqOYEpW-UqyX09lLSd7CCaGhEJw2_M4M7ogXOOdA=.6e2d333b-94b5-4bdd-9db0-7fe949079a01@github.com>
 <Bf4xWq2UoEKrmJPuhIDN4JY5EyvNEjcU5OfM-rISPwI=.16a53d80-8fc1-4965-a803-e4cead398465@github.com>
Message-ID: <ZJhpfjRAZPUmodpv37WJnykqzoHEtUTMh_hDKiM3KRM=.6c36c825-7ef9-4dad-9a5b-3d6f8153de87@github.com>

On Mon, 8 Feb 2021 16:48:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - add specific check for unix domain socket
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - update
>>  - update
>>  - update
>>  - update
>>  - update after Alan's first review
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - test update
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/6a98ca22...746b4762
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 346:
> 
>> 344:                                 Set.of(WindowsChannelFactory.OPEN_REPARSE_POINT),
>> 345:                                 0L);
>> 346:                     fc.close();
> 
> The new version looks a bit strange. As I read it, the attempt to open the file fails with ERROR_CANT_ACCESS_FILE so you then check test if the file is a socket file. That succeeds so we should be done. What is the reason for opening the file again?

I added the test of the socket reparse tag to be 100% sure that we weren't returning false positives for other cases of ERROR_CANT_ACCESS_FILE. But, otherwise, I thought I had to open the file the same way as before to be sure that it is readable. If checking the reparse tag is sufficient then great, that simplifies the change.

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

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

From michaelm at openjdk.java.net  Mon Feb  8 22:06:20 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 8 Feb 2021 22:06:20 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v5]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <wrJeYHg08JKGp9UQ4u1FWbr0ImPqABY9Ba1LsQvUlCg=.506f87fc-4d73-4369-8de2-0912bbdf151a@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

  update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/746b4762..f644e939

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

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

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

From michaelm at openjdk.java.net  Mon Feb  8 22:06:26 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 8 Feb 2021 22:06:26 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v4]
In-Reply-To: <Bf4xWq2UoEKrmJPuhIDN4JY5EyvNEjcU5OfM-rISPwI=.16a53d80-8fc1-4965-a803-e4cead398465@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <yRqdqOYEpW-UqyX09lLSd7CCaGhEJw2_M4M7ogXOOdA=.6e2d333b-94b5-4bdd-9db0-7fe949079a01@github.com>
 <Bf4xWq2UoEKrmJPuhIDN4JY5EyvNEjcU5OfM-rISPwI=.16a53d80-8fc1-4965-a803-e4cead398465@github.com>
Message-ID: <ZPKjNq8CeLhpbopysNNo7X6Amw0xDYc1KoJITxQzFKY=.c4ec332c-78f7-43ac-bf5d-aca98324461d@github.com>

On Mon, 8 Feb 2021 16:50:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - add specific check for unix domain socket
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - update
>>  - update
>>  - update
>>  - update
>>  - update after Alan's first review
>>  - Merge branch 'master' into 8252971-socket-attributes
>>  - test update
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4e1be4ef...746b4762
>
> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 862:
> 
>> 860:      * and a handle to the socket file if it is.
>> 861:      */
>> 862:     private long openSocketForReadAttributeAccess() {
> 
> The methods here throw WindowsException when they fail and might be better to keep it consistent and throw WindowsException rather than returning INVALID_HANDLE_VALUE.

Okay

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

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

From bpb at openjdk.java.net  Mon Feb  8 22:22:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Feb 2021 22:22:58 GMT
Subject: Integrated: 8129776: The optimized Stream returned from Files.lines
 should unmap the mapped byte buffer (if created) when closed
In-Reply-To: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
References: <_KtpPLH6BbYoVB3zUUL2474m6pvqDmt_H2uszylwnRg=.1a4473ae-1252-4800-83ab-c68124b59f45@github.com>
Message-ID: <DkWTpin1rQQqyyt95yLNXFHzPSKdAFynPk0lbCWoYIM=.41851463-6703-4d2d-9401-63bdcd3ba5b3@github.com>

On Mon, 25 Jan 2021 23:55:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed change to unmap the mapped buffer shared between the root and sub-spliterators used in the optimized `Stream` implementation returned by `Files.lines()`. A reference counter is added to track the total number of spliterators sharing the buffer. It is set to 1 when the shared buffer is created, and incremented each time a sub-spliterator is created. It is decremented when traversing begins or when the spliterator is closed. If the counter is zero after it is decremented then the shared buffer is unmapped.

This pull request has now been integrated.

Changeset: 74519628
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/74519628
Stats:     58 lines in 3 files changed: 40 ins; 8 del; 10 mod

8129776: The optimized Stream returned from Files.lines should unmap the mapped byte buffer (if created) when closed

Reviewed-by: rriggs, psandoz, alanb

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

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

From michaelm at openjdk.java.net  Mon Feb  8 22:23:43 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 8 Feb 2021 22:23:43 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v4]
In-Reply-To: <ZPKjNq8CeLhpbopysNNo7X6Amw0xDYc1KoJITxQzFKY=.c4ec332c-78f7-43ac-bf5d-aca98324461d@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <yRqdqOYEpW-UqyX09lLSd7CCaGhEJw2_M4M7ogXOOdA=.6e2d333b-94b5-4bdd-9db0-7fe949079a01@github.com>
 <Bf4xWq2UoEKrmJPuhIDN4JY5EyvNEjcU5OfM-rISPwI=.16a53d80-8fc1-4965-a803-e4cead398465@github.com>
 <ZPKjNq8CeLhpbopysNNo7X6Amw0xDYc1KoJITxQzFKY=.c4ec332c-78f7-43ac-bf5d-aca98324461d@github.com>
Message-ID: <KdOW34eqwJP36HyVDUdwka18iEb-tlPql-c9mLQy6go=.8ac71f5a-58a6-4319-a871-5ef489bb0fb8@github.com>

On Mon, 8 Feb 2021 21:59:53 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 862:
>> 
>>> 860:      * and a handle to the socket file if it is.
>>> 861:      */
>>> 862:     private long openSocketForReadAttributeAccess() {
>> 
>> The methods here throw WindowsException when they fail and might be better to keep it consistent and throw WindowsException rather than returning INVALID_HANDLE_VALUE.
>
> Okay

Actually, there's a mistake in the current latest version (04). Should have tested it before pushing. Will push update shortly.

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

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

From michaelm at openjdk.java.net  Mon Feb  8 22:40:04 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 8 Feb 2021 22:40:04 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v6]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <EPCTY-5FH70r3BwGU2ApSyb4w2GFAFs6497sUnRj8tE=.47f8947f-4ddd-4865-b2dc-0183c6ec85c4@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

  fix mistake in last push

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/f644e939..c1fd3565

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

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

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

From michaelm at openjdk.java.net  Mon Feb  8 22:54:56 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 8 Feb 2021 22:54:56 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v7]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <m0hMKvL5_hyYyDdGAK45I9TnXBqkExx7g7526hvXlOI=.12481ef0-cbd1-4558-bacd-d7fb6f7d41ea@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

  update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/c1fd3565..92031fbc

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

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

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

From github.com+471021+marschall at openjdk.java.net  Tue Feb  9 11:42:34 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 9 Feb 2021 11:42:34 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
Message-ID: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>

On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   fix review comments

src/java.base/share/classes/java/util/jar/JarInputStream.java line 93:

> 91:         if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) {
> 92:             man = new Manifest();
> 93:             byte[] bytes = new BufferedInputStream(this).readAllBytes();

I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7.

In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly.

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

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

From github.com+471021+marschall at openjdk.java.net  Tue Feb  9 14:10:41 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 9 Feb 2021 14:10:41 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
In-Reply-To: <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>
 <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com>
Message-ID: <bv7giHfOsrqkG81ChnQCzoHwrHggfNER2ejUkdraB5k=.90bf4444-7c00-4fc8-acbb-dad88b38b8f7@github.com>

On Tue, 5 Jan 2021 18:10:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright years
>
> src/java.base/share/classes/java/io/Reader.java line 198:
> 
>> 196:         } else {
>> 197:             int remaining = target.remaining();
>> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];
> 
> As `cbuf` for the off-heap case is used in a synchronized block, is there the opportunity for some sort of cached array here and would it help?

That would be possible. It would help in cases where a large Reader is read into one or several relatively small off-heap CharBuffers, requiring multiple #read calls. This can only be done when the caller is able to work with only a partial input. I don't know how common this case is.

We could re-purpose #skipBuffer, it has the same maximum size (8192) but determined by a different constant (#maxSkipBufferSize instead of #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe we should even remove #maxSkipBufferSize. We could also do the reallocation and growing similar as is currently done in #skip.

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

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

From github.com+471021+marschall at openjdk.java.net  Tue Feb  9 15:31:09 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 9 Feb 2021 15:31:09 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v5]
In-Reply-To: <zjSsxP6j0YOpO8fX6K5p3DXbxiHWb9IrnvfAa8mavLg=.9c708009-9580-483c-9693-43c4eb2051b5@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <0iyhKVh5Aq4_7Smt9_-gBboOoEC0tGl5iv_QNzJLhYc=.c4145fe6-ebcc-4ac2-a623-692061f02229@github.com>
 <zjSsxP6j0YOpO8fX6K5p3DXbxiHWb9IrnvfAa8mavLg=.9c708009-9580-483c-9693-43c4eb2051b5@github.com>
Message-ID: <Y6-EeyJfttadkoLk1t3GeeDGkSl0p2oaWZ0BLMqDgJI=.0efb6fc1-e74e-4119-9b35-ef3e03f0fb6c@github.com>

On Fri, 5 Feb 2021 22:08:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Limit amount read to avoid BufferOverflowException
>>   
>>   - limit the amount read
>>   - add tests
>
> src/java.base/share/classes/java/io/Reader.java line 194:
> 
>> 192:             nread = this.read(cbuf, off, len);
>> 193:             if (nread > 0)
>> 194:                 target.position(target.position() + nread);
> 
> As `target` is mutable, I think you would do better to change lines 189-194 to something like:
>             char cbuf[] = target.array();
>             int pos = target.position();
>             int rem = target.limit() - pos;
>             if (rem <= 0)
>                 return -1;
>             int off = target.arrayOffset() + pos;
>             nread = this.read(cbuf, off, rem);
>             if (nread > 0)
>                 target.position(pos + nread);

Done

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

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

From github.com+471021+marschall at openjdk.java.net  Tue Feb  9 15:31:08 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 9 Feb 2021 15:31:08 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v6]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <IEJHmfr42EMKicp7JKt2aDEGPGNx4esNHZzAYStrn-M=.7880fae3-e349-4965-ac3c-1ba5163484f4@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with four additional commits since the last revision:

 - Update copyright year
 - Implement review comment
 - Revert StreamDecoder changes
 - Implement CharArrayReader#read(CharBuffer)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/a8531c1b..08948f93

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

  Stats: 105 lines in 3 files changed: 38 ins; 50 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

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

From alanb at openjdk.java.net  Tue Feb  9 15:36:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 9 Feb 2021 15:36:40 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v7]
In-Reply-To: <m0hMKvL5_hyYyDdGAK45I9TnXBqkExx7g7526hvXlOI=.12481ef0-cbd1-4558-bacd-d7fb6f7d41ea@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <m0hMKvL5_hyYyDdGAK45I9TnXBqkExx7g7526hvXlOI=.12481ef0-cbd1-4558-bacd-d7fb6f7d41ea@github.com>
Message-ID: <uQuAeyfvQpk9Pm4d5nOKLzor5_ljpbVSSxYM2R3sLF4=.a7a6b941-08e1-49d7-b0a3-bd7c34933e42@github.com>

On Mon, 8 Feb 2021 22:54:56 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 840:

> 838:                 throw e;
> 839:             // Object could be a Unix domain socket
> 840:             try {

Thanks for the updates, I think the fallback checking is correct everywhere now.
What would you think about inverting the above so that it only checks for a socket file when followLinks && e.lastError() == ERROR_CANT_ACCESS_FILE. That would make it more consistent with the new code in WIndowsFileSystemProvider.

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

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

From michaelm at openjdk.java.net  Wed Feb 10 07:46:02 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 10 Feb 2021 07:46:02 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v8]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <KNijeWKYcoicVy96UClF6GVsMHZ8qkf4pzCyuPkWFWA=.bb04d1d3-e852-481e-94d9-30715738e7f5@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

 - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files
 - Merge branch 'master' into 8252971-socket-attributes
 - update
 - fix mistake in last push
 - update
 - Merge branch 'master' into 8252971-socket-attributes
 - add specific check for unix domain socket
 - Merge branch 'master' into 8252971-socket-attributes
 - update
 - update
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/a7819067...70832057

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/92031fbc..70832057

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

  Stats: 9487 lines in 220 files changed: 5561 ins; 2694 del; 1232 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424

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

From michaelm at openjdk.java.net  Wed Feb 10 07:46:03 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 10 Feb 2021 07:46:03 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v7]
In-Reply-To: <uQuAeyfvQpk9Pm4d5nOKLzor5_ljpbVSSxYM2R3sLF4=.a7a6b941-08e1-49d7-b0a3-bd7c34933e42@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <m0hMKvL5_hyYyDdGAK45I9TnXBqkExx7g7526hvXlOI=.12481ef0-cbd1-4558-bacd-d7fb6f7d41ea@github.com>
 <uQuAeyfvQpk9Pm4d5nOKLzor5_ljpbVSSxYM2R3sLF4=.a7a6b941-08e1-49d7-b0a3-bd7c34933e42@github.com>
Message-ID: <0ILafV5KyqKOSm1xGyM5BU2rG3elgqHN6g94_uTIBhI=.ea4583af-588b-4534-b513-4f0f069c6cb2@github.com>

On Tue, 9 Feb 2021 15:33:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 840:
> 
>> 838:                 throw e;
>> 839:             // Object could be a Unix domain socket
>> 840:             try {
> 
> Thanks for the updates, I think the fallback checking is correct everywhere now.
> What would you think about inverting the above so that it only checks for a socket file when followLinks && e.lastError() == ERROR_CANT_ACCESS_FILE. That would make it more consistent with the new code in WIndowsFileSystemProvider.

Okay. No problem. The next revision also includes an updated test where I found some socket files weren't being cleaned up at the end of the test.

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

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

From dfuchs at openjdk.java.net  Wed Feb 10 11:12:45 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 10 Feb 2021 11:12:45 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v8]
In-Reply-To: <KNijeWKYcoicVy96UClF6GVsMHZ8qkf4pzCyuPkWFWA=.bb04d1d3-e852-481e-94d9-30715738e7f5@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <KNijeWKYcoicVy96UClF6GVsMHZ8qkf4pzCyuPkWFWA=.bb04d1d3-e852-481e-94d9-30715738e7f5@github.com>
Message-ID: <UwVZpDj2kSEySy3yB2O9nPwB7kDvAc4XowqZy3BB80w=.6ead70c2-1d52-4b87-b2ab-e7e21e48d681@github.com>

On Wed, 10 Feb 2021 07:46:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - fix mistake in last push
>  - update
>  - Merge branch 'master' into 8252971-socket-attributes
>  - add specific check for unix domain socket
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - update
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/f61a6ff5...70832057

Changes LGTM.

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

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

From bpb at openjdk.java.net  Wed Feb 10 22:00:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 10 Feb 2021 22:00:39 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
In-Reply-To: <bv7giHfOsrqkG81ChnQCzoHwrHggfNER2ejUkdraB5k=.90bf4444-7c00-4fc8-acbb-dad88b38b8f7@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>
 <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com>
 <bv7giHfOsrqkG81ChnQCzoHwrHggfNER2ejUkdraB5k=.90bf4444-7c00-4fc8-acbb-dad88b38b8f7@github.com>
Message-ID: <00ENPiXzrIWhDdjjmOuuIdo-2QZ8eomHqWlMGVy477k=.63529d3c-d238-4f67-99c1-ced4d4fa8d5b@github.com>

On Tue, 9 Feb 2021 14:08:10 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 198:
>> 
>>> 196:         } else {
>>> 197:             int remaining = target.remaining();
>>> 198:             char cbuf[] = new char[Math.min(remaining, TRANSFER_BUFFER_SIZE)];
>> 
>> As `cbuf` for the off-heap case is used in a synchronized block, is there the opportunity for some sort of cached array here and would it help?
>
> That would be possible. It would help in cases where a large Reader is read into one or several relatively small off-heap CharBuffers, requiring multiple #read calls. This can only be done when the caller is able to work with only a partial input. I don't know how common this case is.
> 
> We could re-purpose #skipBuffer, it has the same maximum size (8192) but determined by a different constant (#maxSkipBufferSize instead of #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe we should even remove #maxSkipBufferSize. We could also do the reallocation and growing similar as is currently done in #skip.

Perhaps a static final `WORK_BUFFER_SIZE` could be added with value 8192 and `maxSkipBufferSize` and `TRANSFER_BUFFER_SIZE` replaced with that? Then `skipBuffer` could be renamed to `workBuffer` and used in both `read(CharBuffer)` and `skip(long)`. That shouldn't be a problem as both uses are in synchronized blocks. Also I suggest putting the declaration of `workBuffer` just below that of `lock` instead of lower down the file where `skipBuffer` is.

Lastly you mentioned C-style array declarations like `char buf[]`. As there are only four of these in the file it might be good to just go ahead and change them, I don't think that adds much noise or risk.

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

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

From michaelm at openjdk.java.net  Thu Feb 11 09:19:05 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 11 Feb 2021 09:19:05 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v9]
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <yBu-JkumHMj2dGmNYGpb-JvpR0qwkcq8gftInoJ1Yfs=.263ee41b-b0bd-465b-9cdd-519e40b4ccab@github.com>

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

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

 - Merge branch 'master' into 8252971-socket-attributes
 - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files
 - Merge branch 'master' into 8252971-socket-attributes
 - update
 - fix mistake in last push
 - update
 - Merge branch 'master' into 8252971-socket-attributes
 - add specific check for unix domain socket
 - Merge branch 'master' into 8252971-socket-attributes
 - update
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/3bc0384d...11ae5e72

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2424/files
  - new: https://git.openjdk.java.net/jdk/pull/2424/files/70832057..11ae5e72

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

  Stats: 2988 lines in 123 files changed: 1583 ins; 865 del; 540 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2424.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2424/head:pull/2424

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

From jboes at openjdk.java.net  Thu Feb 11 16:59:39 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 11 Feb 2021 16:59:39 GMT
Subject: RFR: JDK-8260694: (fc) Add apiNote to FileChannel.transferFrom to
 better describe "no bytes available" case [v5]
In-Reply-To: <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
 <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
 <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
Message-ID: <JeXs585YfbbaUmfmVWHW4hQTMbyUwFQq1ihJfPb5XcQ=.904c1e43-2f83-43e7-a979-ad98e2e06663@github.com>

On Fri, 5 Feb 2021 00:49:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>> Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks
>> 
>> Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".
>> 
>>> BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.
>> 
>> Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.
>
>> > Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks
>> 
>> Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".
>> 
> Thanks Alan, just finalized it.
>> > BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.
>> 
>> Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.
> Got it.

Hi @Hamlin-Li, to move this forward, could you re-finalize the CSR and change the title of this PR in line with the CSR and issue?

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

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

From github.com+471021+marschall at openjdk.java.net  Fri Feb 12 09:18:10 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Fri, 12 Feb 2021 09:18:10 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:

 - Replace c-style array declarations
 - Share work buffer between #skip and #read

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/08948f93..fc29f3e6

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

  Stats: 28 lines in 1 file changed: 8 ins; 6 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

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

From github.com+471021+marschall at openjdk.java.net  Fri Feb 12 09:20:41 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Fri, 12 Feb 2021 09:20:41 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v3]
In-Reply-To: <00ENPiXzrIWhDdjjmOuuIdo-2QZ8eomHqWlMGVy477k=.63529d3c-d238-4f67-99c1-ced4d4fa8d5b@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <12KyBCHFk1ApB6qI4bPcYvsdXSWbKX9VeKc_LUsvnnM=.a0fd1617-108f-4522-b546-f6e5482cf13f@github.com>
 <5Qm08RW6xBav-dauHUS1ts314yYDMQbOyMGn-LN2b5A=.8b5dcd96-6f88-465d-b241-ced6fe692193@github.com>
 <bv7giHfOsrqkG81ChnQCzoHwrHggfNER2ejUkdraB5k=.90bf4444-7c00-4fc8-acbb-dad88b38b8f7@github.com>
 <00ENPiXzrIWhDdjjmOuuIdo-2QZ8eomHqWlMGVy477k=.63529d3c-d238-4f67-99c1-ced4d4fa8d5b@github.com>
Message-ID: <1DmQcrkGvKVBZYWrsv00WwH1UT4W-xvj86uC1kHkqHA=.4164f16e-c8e3-4e4d-80e3-79d11d52c74b@github.com>

On Wed, 10 Feb 2021 21:58:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> That would be possible. It would help in cases where a large Reader is read into one or several relatively small off-heap CharBuffers, requiring multiple #read calls. This can only be done when the caller is able to work with only a partial input. I don't know how common this case is.
>> 
>> We could re-purpose #skipBuffer, it has the same maximum size (8192) but determined by a different constant (#maxSkipBufferSize instead of #TRANSFER_BUFFER_SIZE). That would likely require it to be renamed and maybe we should even remove #maxSkipBufferSize. We could also do the reallocation and growing similar as is currently done in #skip.
>
> Perhaps a static final `WORK_BUFFER_SIZE` could be added with value 8192 and `maxSkipBufferSize` and `TRANSFER_BUFFER_SIZE` replaced with that? Then `skipBuffer` could be renamed to `workBuffer` and used in both `read(CharBuffer)` and `skip(long)`. That shouldn't be a problem as both uses are in synchronized blocks. Also I suggest putting the declaration of `workBuffer` just below that of `lock` instead of lower down the file where `skipBuffer` is.
> 
> Lastly you mentioned C-style array declarations like `char buf[]`. As there are only four of these in the file it might be good to just go ahead and change them, I don't think that adds much noise or risk.

Done. I left #transferTo(Writer) untouched for now. Firstly it is not already behind a synchronized. Secondly it writes so there is no need for repeated calls.

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

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

From alanb at openjdk.java.net  Fri Feb 12 12:59:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 12 Feb 2021 12:59:47 GMT
Subject: RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets [v9]
In-Reply-To: <yBu-JkumHMj2dGmNYGpb-JvpR0qwkcq8gftInoJ1Yfs=.263ee41b-b0bd-465b-9cdd-519e40b4ccab@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
 <yBu-JkumHMj2dGmNYGpb-JvpR0qwkcq8gftInoJ1Yfs=.263ee41b-b0bd-465b-9cdd-519e40b4ccab@github.com>
Message-ID: <iotKAc95LYxgaHmfG6CthdIukMoHdYlphSJdqHwcZK0=.41210314-b503-4ebe-b908-18393146efbd@github.com>

On Thu, 11 Feb 2021 09:19:05 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
>> 
>> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into 8252971-socket-attributes
>  - Rearrange test in WindowsPath. Change to Security.java test to explicitly delete socket files
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - fix mistake in last push
>  - update
>  - Merge branch 'master' into 8252971-socket-attributes
>  - add specific check for unix domain socket
>  - Merge branch 'master' into 8252971-socket-attributes
>  - update
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/c6c9f6f9...11ae5e72

Thanks for the updates, I think you've got this to a good place now.

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

Marked as reviewed by alanb (Reviewer).

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

From michaelm at openjdk.java.net  Fri Feb 12 13:12:43 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 12 Feb 2021 13:12:43 GMT
Subject: Integrated: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets
In-Reply-To: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
References: <TMb-AGOIphdtjtU7DpILdxsowgmJBWYipE1dn532R40=.c8ded15a-6929-4aa2-a985-ab3a359aaf3e@github.com>
Message-ID: <wPeYPVRMrs9A3vf1G7M17JfFRYTvgh6cjIYIv2vxOXY=.3964d051-7c25-444c-b927-227bc20f03e1@github.com>

On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Could I get the following change reviewed please? It fixes a problem (in JEP380) on Windows where some file operations on Unix domain sockets were not working and led to the feature being disabled on Windows 2019 Server in JDK 16. So, the fix re-enables the feature on all versions of Windows that support it.
> 
> The test checks all the file APIs that were affected by the problem. The change touches the code that handles symbolic links in Windows (since they are implemented as NTFS reparse points, like Unix sockets), but I didn't add any specific testing in this area, as I assume the existing unit tests for NIO symbolic links should cover that. If I should add more tests here, then I can do that.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: 9ffabf30
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ffabf30
Stats:     245 lines in 10 files changed: 228 ins; 10 del; 7 mod

8252971: WindowsFileAttributes does not know about Unix domain sockets

Reviewed-by: alanb

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
Message-ID: <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>

On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
>> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk
>
> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
> and checked tier2 and tier3.
> What I got:
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR   
>     >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
>     >> jtreg:test/langtools:tier2                           12    11     1     0 <<
>        jtreg:test/jaxp:tier2                               450   450     0     0   
>     ==============================
>     TEST FAILURE
> 
> 
> 
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR   
>     >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
>        jtreg:test/langtools:tier3                            0     0     0     0   
>        jtreg:test/jaxp:tier3                                 0     0     0     0   
>     ==============================
>     TEST FAILURE
> 
> 
> Failed tests:
> 
>      tier2:
>      java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>      java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>      java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>      java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>      java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>      tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>      
>      sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
>      sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
>      
>      jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>      
>      tier3:
>      sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>      sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

Then I tried to run tests separately:
## java/io/File/GetXSpace.java


    make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"

    STDERR:
    java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
            at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
            at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
            at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
            at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
            at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
            at java.base/java.io.File.toPath(File.java:2316)
            at GetXSpace.compare(GetXSpace.java:219)
            at GetXSpace.testDF(GetXSpace.java:394)
            at GetXSpace.main(GetXSpace.java:428)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
    JavaTest Message: shutting down test

    STDOUT:
    --- Testing df
    C:/Programs/cygwin64   350809332  172573816 178235516      50% /
    D:                    3702215676 2812548988 889666688      76% /cygdrive/d
    E:                    3906885628 3544182676 362702952      91% /cygdrive/e
    F:                     250057724  240917056   9140668      97% /cygdrive/f


    SecurityManager = null
    C:/Programs/cygwin64:
      df   total= 359228755968 free =            0 usable = 182513168384
      getX total= 359228755968 free = 182513168384 usable = 182513168384
    ::
      df   total= 3791068852224 free =            0 usable = 911018688512
      getX total=            0 free =            0 usable =            0

    TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
--------------------------------------------------


https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
Message-ID: <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>

On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
>> and checked tier2 and tier3.
>> What I got:
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR   
>>     >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
>>     >> jtreg:test/langtools:tier2                           12    11     1     0 <<
>>        jtreg:test/jaxp:tier2                               450   450     0     0   
>>     ==============================
>>     TEST FAILURE
>> 
>> 
>> 
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR   
>>     >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
>>        jtreg:test/langtools:tier3                            0     0     0     0   
>>        jtreg:test/jaxp:tier3                                 0     0     0     0   
>>     ==============================
>>     TEST FAILURE
>> 
>> 
>> Failed tests:
>> 
>>      tier2:
>>      java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>>      java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>>      java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>      java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>      java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>>      tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>      
>>      sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
>>      sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
>>      
>>      jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>>      
>>      tier3:
>>      sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>>      sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>
> Then I tried to run tests separately:
> ## java/io/File/GetXSpace.java
> 
> 
>     make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
> 
>     STDERR:
>     java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>             at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>             at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>             at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>             at java.base/java.io.File.toPath(File.java:2316)
>             at GetXSpace.compare(GetXSpace.java:219)
>             at GetXSpace.testDF(GetXSpace.java:394)
>             at GetXSpace.main(GetXSpace.java:428)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
>     JavaTest Message: shutting down test
> 
>     STDOUT:
>     --- Testing df
>     C:/Programs/cygwin64   350809332  172573816 178235516      50% /
>     D:                    3702215676 2812548988 889666688      76% /cygdrive/d
>     E:                    3906885628 3544182676 362702952      91% /cygdrive/e
>     F:                     250057724  240917056   9140668      97% /cygdrive/f
> 
> 
>     SecurityManager = null
>     C:/Programs/cygwin64:
>       df   total= 359228755968 free =            0 usable = 182513168384
>       getX total= 359228755968 free = 182513168384 usable = 182513168384
>     ::
>       df   total= 3791068852224 free =            0 usable = 911018688512
>       getX total=            0 free =            0 usable =            0
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
> --------------------------------------------------
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.

## java/net/MulticastSocket/MulticastAddresses.java

    make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"

    STDOUT:
    Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /129.1.1.1
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress) Failed: No route to host: no further information
    Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /0:0:0:0:0:0:0:1
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /0:0:0:0:0:0:8101:101
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /fe80:0:0:0:a00:20ff:fee5:bc02
        joinGroup(InetAddress)
        Passed: Not a multicast address
    STDERR:
    java.lang.Exception: 1 test(s) failed - see log file.
            at MulticastAddresses.runTest(MulticastAddresses.java:93)
            at MulticastAddresses.main(MulticastAddresses.java:138)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.Exception
    JavaTest Message: shutting down test


    TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.


I connected debbuger and got this stack trace:

    java.net.NoRouteToHostException: No route to host: no further information
        at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
        at java.base/sun.nio.ch.Net.join6(Net.java:734)
        at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
        at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
        at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
        at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
        at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
        at MulticastAddresses.runTest(MulticastAddresses.java:56)
        at MulticastAddresses.main(MulticastAddresses.java:138)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
        at java.base/java.lang.Thread.run(Thread.java:831)
        
Not sure what actual cause. Will investigate further.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
Message-ID: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>

On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> The other security-related code changes look good to me.
>
> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk

I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
and checked tier2 and tier3.
What I got:

    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR   
    >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
    >> jtreg:test/langtools:tier2                           12    11     1     0 <<
       jtreg:test/jaxp:tier2                               450   450     0     0   
    ==============================
    TEST FAILURE




    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR   
    >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
       jtreg:test/langtools:tier3                            0     0     0     0   
       jtreg:test/jaxp:tier3                                 0     0     0     0   
    ==============================
    TEST FAILURE


Failed tests:

     tier2:
     java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
     java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
     java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
     java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
     java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
     tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
     
     sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
     sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
     
     jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
     
     tier3:
     sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
     sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:14:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:14:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
Message-ID: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>

On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Then I tried to run tests separately:
>> ## java/io/File/GetXSpace.java
>> 
>> 
>>     make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
>> 
>>     STDERR:
>>     java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>>             at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>>             at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>             at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>>             at java.base/java.io.File.toPath(File.java:2316)
>>             at GetXSpace.compare(GetXSpace.java:219)
>>             at GetXSpace.testDF(GetXSpace.java:394)
>>             at GetXSpace.main(GetXSpace.java:428)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
>>     JavaTest Message: shutting down test
>> 
>>     STDOUT:
>>     --- Testing df
>>     C:/Programs/cygwin64   350809332  172573816 178235516      50% /
>>     D:                    3702215676 2812548988 889666688      76% /cygdrive/d
>>     E:                    3906885628 3544182676 362702952      91% /cygdrive/e
>>     F:                     250057724  240917056   9140668      97% /cygdrive/f
>> 
>> 
>>     SecurityManager = null
>>     C:/Programs/cygwin64:
>>       df   total= 359228755968 free =            0 usable = 182513168384
>>       getX total= 359228755968 free = 182513168384 usable = 182513168384
>>     ::
>>       df   total= 3791068852224 free =            0 usable = 911018688512
>>       getX total=            0 free =            0 usable =            0
>> 
>>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>> --------------------------------------------------
>> 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.
>
> ## java/net/MulticastSocket/MulticastAddresses.java
> 
>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
> 
>     STDOUT:
>     Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /129.1.1.1
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress) Failed: No route to host: no further information
>     Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /0:0:0:0:0:0:0:1
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /0:0:0:0:0:0:8101:101
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /fe80:0:0:0:a00:20ff:fee5:bc02
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     STDERR:
>     java.lang.Exception: 1 test(s) failed - see log file.
>             at MulticastAddresses.runTest(MulticastAddresses.java:93)
>             at MulticastAddresses.main(MulticastAddresses.java:138)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
> 
> 
> I connected debbuger and got this stack trace:
> 
>     java.net.NoRouteToHostException: No route to host: no further information
>         at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>         at java.base/sun.nio.ch.Net.join6(Net.java:734)
>         at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>         at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>         at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>         at MulticastAddresses.runTest(MulticastAddresses.java:56)
>         at MulticastAddresses.main(MulticastAddresses.java:138)
>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>         at java.base/java.lang.Thread.run(Thread.java:831)
>         
> Not sure what actual cause. Will investigate further.

## java/net/MulticastSocket/SetLoopbackMode.java

    make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
    
    
    STDOUT:
    IPv6 can be used
    Default network interface: null

    Test will use multicast group: /ff01:0:0:0:0:0:0:1
    NetworkInterface.getByInetAddress(grp): null
    STDERR:
    java.net.NoRouteToHostException: No route to host: no further information
            at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
            at java.base/sun.nio.ch.Net.join6(Net.java:734)
            at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
            at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
            at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
            at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
            at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
            at SetLoopbackMode.main(SetLoopbackMode.java:132)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
    
Cause looks similar to `MulticastAddresses`: virtualbox network interface:
Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
    joinGroup(InetAddress) Failed: No route to host: no further information
Will investigate futher.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:34:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:34:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
Message-ID: <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>

On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/net/MulticastSocket/MulticastAddresses.java
>> 
>>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
>> 
>>     STDOUT:
>>     Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /129.1.1.1
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress) Failed: No route to host: no further information
>>     Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /0:0:0:0:0:0:0:1
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /0:0:0:0:0:0:8101:101
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /fe80:0:0:0:a00:20ff:fee5:bc02
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     STDERR:
>>     java.lang.Exception: 1 test(s) failed - see log file.
>>             at MulticastAddresses.runTest(MulticastAddresses.java:93)
>>             at MulticastAddresses.main(MulticastAddresses.java:138)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.Exception
>>     JavaTest Message: shutting down test
>> 
>> 
>>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>> 
>> 
>> I connected debbuger and got this stack trace:
>> 
>>     java.net.NoRouteToHostException: No route to host: no further information
>>         at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>>         at java.base/sun.nio.ch.Net.join6(Net.java:734)
>>         at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>>         at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>>         at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>>         at MulticastAddresses.runTest(MulticastAddresses.java:56)
>>         at MulticastAddresses.main(MulticastAddresses.java:138)
>>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>         at java.base/java.lang.Thread.run(Thread.java:831)
>>         
>> Not sure what actual cause. Will investigate further.
>
> ## java/net/MulticastSocket/SetLoopbackMode.java
> 
>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>     
>     
>     STDOUT:
>     IPv6 can be used
>     Default network interface: null
> 
>     Test will use multicast group: /ff01:0:0:0:0:0:0:1
>     NetworkInterface.getByInetAddress(grp): null
>     STDERR:
>     java.net.NoRouteToHostException: No route to host: no further information
>             at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>             at java.base/sun.nio.ch.Net.join6(Net.java:734)
>             at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>             at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>             at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>             at SetLoopbackMode.main(SetLoopbackMode.java:132)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>     
> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
> Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>     joinGroup(InetAddress) Failed: No route to host: no further information
> Will investigate futher.

## java/nio/file/Files/CopyAndMove.java    
    
    make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
    
    STDOUT:
    Seed from RandomFactory = 704532001916725417L
    STDERR:
    dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
    dir2: .\name1900089232270637553 (NTFS)
    java.lang.RuntimeException: AtomicMoveNotSupportedException expected
            at CopyAndMove.testMove(CopyAndMove.java:369)
            at CopyAndMove.main(CopyAndMove.java:74)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected

Checked in debugger:

    Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
    Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
    sameDevice = false

https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:55:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:55:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
Message-ID: <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>

On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/net/MulticastSocket/SetLoopbackMode.java
>> 
>>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>>     
>>     
>>     STDOUT:
>>     IPv6 can be used
>>     Default network interface: null
>> 
>>     Test will use multicast group: /ff01:0:0:0:0:0:0:1
>>     NetworkInterface.getByInetAddress(grp): null
>>     STDERR:
>>     java.net.NoRouteToHostException: No route to host: no further information
>>             at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>>             at java.base/sun.nio.ch.Net.join6(Net.java:734)
>>             at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>>             at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>>             at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>>             at SetLoopbackMode.main(SetLoopbackMode.java:132)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>     
>> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
>> Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>     joinGroup(InetAddress) Failed: No route to host: no further information
>> Will investigate futher.
>
> ## java/nio/file/Files/CopyAndMove.java    
>     
>     make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>     
>     STDOUT:
>     Seed from RandomFactory = 704532001916725417L
>     STDERR:
>     dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
>     dir2: .\name1900089232270637553 (NTFS)
>     java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>             at CopyAndMove.testMove(CopyAndMove.java:369)
>             at CopyAndMove.main(CopyAndMove.java:74)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
> 
> Checked in debugger:
> 
>     Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
>     Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
>     sameDevice = false
> 
> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.

## java/security/AccessController/DoPrivAccompliceTest.java

    make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"

    STDOUT:
    Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar

    Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
    Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar

    Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
    Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
    Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win
 dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
    [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
    [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
    [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
    Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
    [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
    [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
    Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
    Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win
 dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
    [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
    [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
    Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
    [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
    STDERR:
     stdout: [];
     stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
            at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
            at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
            at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
            at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
            at java.base/java.lang.System.getProperty(System.java:833)
            at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
            at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
            at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
            at DoPrivTest.main(DoPrivTest.java:29)
    ]
     exitValue = 1

    java.lang.RuntimeException: 'user' found in stderr

            at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
            at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr

    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
    
Looks like test is not ready for username `user`, which I use locally.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 22:15:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 22:15:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
Message-ID: <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwmsdteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>

On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/nio/file/Files/CopyAndMove.java    
>>     
>>     make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>>     
>>     STDOUT:
>>     Seed from RandomFactory = 704532001916725417L
>>     STDERR:
>>     dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
>>     dir2: .\name1900089232270637553 (NTFS)
>>     java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>             at CopyAndMove.testMove(CopyAndMove.java:369)
>>             at CopyAndMove.main(CopyAndMove.java:74)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>> 
>> Checked in debugger:
>> 
>>     Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
>>     Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
>>     sameDevice = false
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.
>
> ## java/security/AccessController/DoPrivAccompliceTest.java
> 
>     make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
> 
>     STDOUT:
>     Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
> 
>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>     Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
> 
>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w
 indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>     [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
>     [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
>     [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
>     Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
>     [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
>     [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w
 indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>     [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
>     [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
>     Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>     STDERR:
>      stdout: [];
>      stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
>             at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>             at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
>             at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
>             at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
>             at java.base/java.lang.System.getProperty(System.java:833)
>             at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
>             at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
>             at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
>             at DoPrivTest.main(DoPrivTest.java:29)
>     ]
>      exitValue = 1
> 
>     java.lang.RuntimeException: 'user' found in stderr
> 
>             at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
>             at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr
> 
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>     
> Looks like test is not ready for username `user`, which I use locally.

## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java

    make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"

    STDOUT:
    [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
    [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
    [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
    [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
    [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
    [00:56:54.693] TRACE: Test string code points: [0x00e9]
    [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
    [00:56:55.996] TRACE: exec: Done. Exit code: 0
    [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
    [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
    [00:56:56.188] TRACE: exec: Done. Exit code: 0
    [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
    [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
    [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
    [00:57:07.680] Command:
        jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrume
 nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
    [00:57:07.680] Output:
        WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

    [00:57:07.681] Returned: 0

    [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
    [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
    [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
    [00:57:07.746] Succeeded in building Windows Application Image package
    [00:57:07.748] TRACE: exec: Done. Exit code: 0
    [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
    [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
    [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
    [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
    [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
    [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
    [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
    [00:57:07.780] TRACE: Clearing PATH in environment
    [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
    hello: Environment supports a display
    hello: Environment supports a desktop
    [0x0065]
    jpackage test application
    args.length: 1
    e
    hello: Output file: [appOutput.txt]
    [00:57:09.302] TRACE: exec: Done. Exit code: 0
    [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
    [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
    [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
    [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
    [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
    [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
    [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
    [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
    [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
    [00:57:09.312] TRACE: Test string code points: [0x00e9]
    [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
    [00:57:09.658] TRACE: exec: Done. Exit code: 0
    [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
    [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
    [00:57:09.667] TRACE: exec: Done. Exit code: 0
    [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
    [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
    [00:57:09.670]
    jpackage argument list:
    [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]

    [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
    [00:57:18.770] Command:
        jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrume
 nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
    [00:57:18.770] Output:
        WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

    [00:57:18.770] Returned: 0

    [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
    [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
    [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
    [00:57:18.787] Succeeded in building Windows Application Image package
    [00:57:18.788] TRACE: exec: Done. Exit code: 0
    [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
    [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
    [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
    [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
    [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
    [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
    [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
    [00:57:18.808] TRACE: Clearing PATH in environment
    [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
    hello: Environment supports a display
    hello: Environment supports a desktop
    [0x0065]
    jpackage test application
    args.length: 1
    e
    hello: Output file: [appOutput.txt]
    [00:57:20.327] TRACE: exec: Done. Exit code: 0
    [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
    [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
    [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
    [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
    [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
    [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
    [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
    [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
    [00:57:20.332] [==========] 2 tests ran
    [00:57:20.333] [  PASSED  ] 0 tests
    [00:57:20.334] [  FAILED  ] 2 tests, listed below
    [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
    [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
    [00:57:20.336] 2 FAILED TESTS
    STDERR:
    java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
            at jdk.jpackage.test.TKit.error(TKit.java:293)
            at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
            at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
            at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
            at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
            at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
            at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
            at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
            at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
            at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
            at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
            at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
            at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
            at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.TKit.runTests(TKit.java:136)
            at jdk.jpackage.test.Main.runTests(Main.java:79)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
            at jdk.jpackage.test.TKit.error(TKit.java:293)
            at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
            at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
            at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
            at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
            at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
            at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
            at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
            at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
            at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
            at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
            at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
            at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
            at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.TKit.runTests(TKit.java:136)
            at jdk.jpackage.test.Main.runTests(Main.java:79)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
            at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    Caused by: java.lang.RuntimeException: 2 FAILED TESTS
            at jdk.jpackage.test.Main.reportSummary(Main.java:130)
            at jdk.jpackage.test.Main.runTests(Main.java:90)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            ... 8 more

    JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS

Oh. This one is tricky. Will investigate later.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Feb 13 10:23:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Feb 2021 10:23:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwmsdteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
Message-ID: <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>

On Fri, 12 Feb 2021 22:12:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/security/AccessController/DoPrivAccompliceTest.java
>> 
>>     make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
>> 
>>     STDOUT:
>>     Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>> 
>>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>>     Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>> 
>>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\
 windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>>     [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
>>     [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
>>     [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
>>     Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
>>     [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
>>     [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
>>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\
 windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>>     [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
>>     [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
>>     Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>>     STDERR:
>>      stdout: [];
>>      stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
>>             at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>>             at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
>>             at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
>>             at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
>>             at java.base/java.lang.System.getProperty(System.java:833)
>>             at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
>>             at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
>>             at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
>>             at DoPrivTest.main(DoPrivTest.java:29)
>>     ]
>>      exitValue = 1
>> 
>>     java.lang.RuntimeException: 'user' found in stderr
>> 
>>             at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
>>             at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr
>> 
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>>     
>> Looks like test is not ready for username `user`, which I use locally.
>
> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
> 
>     make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
> 
>     STDOUT:
>     [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
>     [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
>     [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
>     [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
>     [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
>     [00:56:54.693] TRACE: Test string code points: [0x00e9]
>     [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>     [00:56:55.996] TRACE: exec: Done. Exit code: 0
>     [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>     [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
>     [00:56:56.188] TRACE: exec: Done. Exit code: 0
>     [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
>     [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
>     [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
>     [00:57:07.680] Command:
>         jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instru
 ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>     [00:57:07.680] Output:
>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> 
>     [00:57:07.681] Returned: 0
> 
>     [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>     [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
>     [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>     [00:57:07.746] Succeeded in building Windows Application Image package
>     [00:57:07.748] TRACE: exec: Done. Exit code: 0
>     [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
>     [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>     [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>     [00:57:07.780] TRACE: Clearing PATH in environment
>     [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
>     hello: Environment supports a display
>     hello: Environment supports a desktop
>     [0x0065]
>     jpackage test application
>     args.length: 1
>     e
>     hello: Output file: [appOutput.txt]
>     [00:57:09.302] TRACE: exec: Done. Exit code: 0
>     [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
>     [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>     [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
>     [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
>     [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>     [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
>     [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
>     [00:57:09.312] TRACE: Test string code points: [0x00e9]
>     [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>     [00:57:09.658] TRACE: exec: Done. Exit code: 0
>     [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>     [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
>     [00:57:09.667] TRACE: exec: Done. Exit code: 0
>     [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
>     [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
>     [00:57:09.670]
>     jpackage argument list:
>     [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]
> 
>     [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
>     [00:57:18.770] Command:
>         jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instru
 ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>     [00:57:18.770] Output:
>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> 
>     [00:57:18.770] Returned: 0
> 
>     [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>     [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
>     [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>     [00:57:18.787] Succeeded in building Windows Application Image package
>     [00:57:18.788] TRACE: exec: Done. Exit code: 0
>     [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
>     [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>     [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>     [00:57:18.808] TRACE: Clearing PATH in environment
>     [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
>     hello: Environment supports a display
>     hello: Environment supports a desktop
>     [0x0065]
>     jpackage test application
>     args.length: 1
>     e
>     hello: Output file: [appOutput.txt]
>     [00:57:20.327] TRACE: exec: Done. Exit code: 0
>     [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
>     [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
>     [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
>     [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>     [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
>     [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
>     [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>     [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
>     [00:57:20.332] [==========] 2 tests ran
>     [00:57:20.333] [  PASSED  ] 0 tests
>     [00:57:20.334] [  FAILED  ] 2 tests, listed below
>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
>     [00:57:20.336] 2 FAILED TESTS
>     STDERR:
>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>             at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     Caused by: java.lang.RuntimeException: 2 FAILED TESTS
>             at jdk.jpackage.test.Main.reportSummary(Main.java:130)
>             at jdk.jpackage.test.Main.runTests(Main.java:90)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             ... 8 more
> 
>     JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
> 
> Oh. This one is tricky. Will investigate later.

This fours tests pass without problems, when I run them separately.

## sun/security/tools/jarsigner/TimestampCheck.java
## sun/security/tools/keytool/DefaultOptions.java
## sanity/client/SwingSet/src/ColorChooserDemoTest.java
## sanity/client/SwingSet/src/SwingSet2DemoTest.java

    make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
    
    Building target 'test' in configuration 'windows-x86_64-server-release'
    Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
    * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
    * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
    * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
    * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java

    Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
    Passed: sun/security/tools/jarsigner/TimestampCheck.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
    Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java

    Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
    Passed: sun/security/tools/keytool/DefaultOptions.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
    Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java

    Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
    Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
    Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java

    Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
    Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
    Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java

    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR
       jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
                                                             1     1     0     0
       jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
                                                             1     1     0     0
       jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
                                                             1     1     0     0
       jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
                                                             1     1     0     0
    ==============================
    TEST SUCCESS

    Finished building target 'test' in configuration 'windows-x86_64-server-release'

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Feb 13 10:59:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Feb 2021 10:59:38 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
Message-ID: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>

On Sat, 13 Feb 2021 10:20:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
>> 
>>     make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
>> 
>>     STDOUT:
>>     [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
>>     [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
>>     [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
>>     [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
>>     [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
>>     [00:56:54.693] TRACE: Test string code points: [0x00e9]
>>     [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>>     [00:56:55.996] TRACE: exec: Done. Exit code: 0
>>     [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>>     [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
>>     [00:56:56.188] TRACE: exec: Done. Exit code: 0
>>     [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
>>     [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
>>     [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
>>     [00:57:07.680] Command:
>>         jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instr
 ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>>     [00:57:07.680] Output:
>>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>> 
>>     [00:57:07.681] Returned: 0
>> 
>>     [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>>     [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
>>     [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>>     [00:57:07.746] Succeeded in building Windows Application Image package
>>     [00:57:07.748] TRACE: exec: Done. Exit code: 0
>>     [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
>>     [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>>     [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
>>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
>>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>>     [00:57:07.780] TRACE: Clearing PATH in environment
>>     [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
>>     hello: Environment supports a display
>>     hello: Environment supports a desktop
>>     [0x0065]
>>     jpackage test application
>>     args.length: 1
>>     e
>>     hello: Output file: [appOutput.txt]
>>     [00:57:09.302] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
>>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
>>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
>>     [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>     [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
>>     [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
>>     [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>     [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
>>     [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
>>     [00:57:09.312] TRACE: Test string code points: [0x00e9]
>>     [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>>     [00:57:09.658] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>>     [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
>>     [00:57:09.667] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
>>     [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
>>     [00:57:09.670]
>>     jpackage argument list:
>>     [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]
>> 
>>     [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
>>     [00:57:18.770] Command:
>>         jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instr
 ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>>     [00:57:18.770] Output:
>>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>> 
>>     [00:57:18.770] Returned: 0
>> 
>>     [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>>     [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
>>     [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>>     [00:57:18.787] Succeeded in building Windows Application Image package
>>     [00:57:18.788] TRACE: exec: Done. Exit code: 0
>>     [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
>>     [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>>     [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
>>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
>>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>>     [00:57:18.808] TRACE: Clearing PATH in environment
>>     [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
>>     hello: Environment supports a display
>>     hello: Environment supports a desktop
>>     [0x0065]
>>     jpackage test application
>>     args.length: 1
>>     e
>>     hello: Output file: [appOutput.txt]
>>     [00:57:20.327] TRACE: exec: Done. Exit code: 0
>>     [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
>>     [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
>>     [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
>>     [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>     [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
>>     [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
>>     [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>     [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
>>     [00:57:20.332] [==========] 2 tests ran
>>     [00:57:20.333] [  PASSED  ] 0 tests
>>     [00:57:20.334] [  FAILED  ] 2 tests, listed below
>>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
>>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
>>     [00:57:20.336] 2 FAILED TESTS
>>     STDERR:
>>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>             at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     Caused by: java.lang.RuntimeException: 2 FAILED TESTS
>>             at jdk.jpackage.test.Main.reportSummary(Main.java:130)
>>             at jdk.jpackage.test.Main.runTests(Main.java:90)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             ... 8 more
>> 
>>     JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>> 
>> Oh. This one is tricky. Will investigate later.
>
> This fours tests pass without problems, when I run them separately.
> 
> ## sun/security/tools/jarsigner/TimestampCheck.java
> ## sun/security/tools/keytool/DefaultOptions.java
> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
> 
>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>     
>     Building target 'test' in configuration 'windows-x86_64-server-release'
>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
> 
>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
> 
>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>     Passed: sun/security/tools/keytool/DefaultOptions.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
> 
>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
> 
>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR
>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>                                                              1     1     0     0
>     ==============================
>     TEST SUCCESS
> 
>     Finished building target 'test' in configuration 'windows-x86_64-server-release'

## jdk/jshell/ToolBasicTest.java
    
    make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"

    STDOUT:
    [TestNG] Running:
      jdk/jshell/ToolBasicTest.java

    config ReplToolTesting.setUp(): success
    test ToolBasicTest.elideStartUpFromList(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.elideStartUpFromSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.test8142447(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testAddExports(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadClasspath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadModulePath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadSourceJarClasspath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathDirectory(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathJar(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathUserHomeExpansion(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testConstrainedUpdates(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testCtrlD(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testEnvInStartUp(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackNegative(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackNormal(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackSilent(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testHistoryReference(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testIndent(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testInterrupt(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testLoadingFromArgs(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testModulePath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testModulePathUserHomeExpansion(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpen(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenFileOverHttp(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenLocalFileUrl(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenResource(): failure
    java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
     expected [3.14] but found [3,14]
            at org.testng.Assert.fail(Assert.java:94)
            at org.testng.Assert.failNotEquals(Assert.java:496)
            at org.testng.Assert.assertEquals(Assert.java:125)
            at org.testng.Assert.assertEquals(Assert.java:178)
            at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
            at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
            at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
            at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
            at java.base/java.io.PrintStream.write(PrintStream.java:536)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
            at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
            at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
            at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
            at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
            at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
            at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
            at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
            at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
            at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
            at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
            at ReplToolTesting.testRaw(ReplToolTesting.java:296)
            at ReplToolTesting.test(ReplToolTesting.java:249)
            at ReplToolTesting.test(ReplToolTesting.java:233)
            at ReplToolTesting.test(ReplToolTesting.java:229)
            at ReplToolTesting.test(ReplToolTesting.java:225)
            at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
            at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
            at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
            at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
            at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
            at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
            at org.testng.TestRunner.privateRun(TestRunner.java:773)
            at org.testng.TestRunner.run(TestRunner.java:623)
            at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
            at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
            at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
            at org.testng.SuiteRunner.run(SuiteRunner.java:259)
            at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
            at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
            at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
            at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
            at org.testng.TestNG.run(TestNG.java:1018)
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRedeclareVariableNoInit(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRemoteExit(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRerun(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRerunIdRange(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testReset(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartRetain(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartupFileOption(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStop(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testVarsWithNotActive(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testWarningUnchecked(): success

    ===============================================
    jdk/jshell/ToolBasicTest.java
    Total tests run: 38, Failures: 1, Skips: 0
    ===============================================

    STDERR:
    java.io.EOFException
            at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
            at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
            at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
            at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
            at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
            at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
            at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
            at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
            at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
            at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
            at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
            at ReplToolTesting.testRaw(ReplToolTesting.java:296)
            at ReplToolTesting.test(ReplToolTesting.java:249)
            at ReplToolTesting.test(ReplToolTesting.java:233)
            at ReplToolTesting.test(ReplToolTesting.java:229)
            at ReplToolTesting.test(ReplToolTesting.java:225)
            at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
            at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
            at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
            at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
            at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
            at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
            at org.testng.TestRunner.privateRun(TestRunner.java:773)
            at org.testng.TestRunner.run(TestRunner.java:623)
            at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
            at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
            at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
            at org.testng.SuiteRunner.run(SuiteRunner.java:259)
            at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
            at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
            at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
            at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
            at org.testng.TestNG.run(TestNG.java:1018)
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)
    java.lang.Exception: failures: 1
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.Exception
    JavaTest Message: shutting down test


    TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

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

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

From alanb at openjdk.java.net  Mon Feb 15 11:49:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Feb 2021 11:49:38 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
 <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
Message-ID: <xi_gLEAFRhno-QJ7-t9yN5roj4z8jgj8bSEqynItmMQ=.8dbd6668-ced8-461e-8bca-fb88db59aa6a@github.com>

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This fours tests pass without problems, when I run them separately.
>> 
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
>> 
>>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>>     
>>     Building target 'test' in configuration 'windows-x86_64-server-release'
>>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Passed: sun/security/tools/keytool/DefaultOptions.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR
>>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>                                                              1     1     0     0
>>     ==============================
>>     TEST SUCCESS
>> 
>>     Finished building target 'test' in configuration 'windows-x86_64-server-release'
>
> ## jdk/jshell/ToolBasicTest.java
>     
>     make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"
> 
>     STDOUT:
>     [TestNG] Running:
>       jdk/jshell/ToolBasicTest.java
> 
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromList(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.test8142447(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testAddExports(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadSourceJarClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathDirectory(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathJar(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testConstrainedUpdates(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testCtrlD(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testEnvInStartUp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNegative(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNormal(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackSilent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testHistoryReference(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testIndent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testInterrupt(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testLoadingFromArgs(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpen(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenFileOverHttp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenLocalFileUrl(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenResource(): failure
>     java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
>      expected [3.14] but found [3,14]
>             at org.testng.Assert.fail(Assert.java:94)
>             at org.testng.Assert.failNotEquals(Assert.java:496)
>             at org.testng.Assert.assertEquals(Assert.java:125)
>             at org.testng.Assert.assertEquals(Assert.java:178)
>             at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
>             at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
>             at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
>             at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
>             at java.base/java.io.PrintStream.write(PrintStream.java:536)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
>             at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
>             at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
>             at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
>             at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
>             at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
>             at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
>             at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
>             at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRedeclareVariableNoInit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRemoteExit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerun(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerunIdRange(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testReset(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartRetain(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartupFileOption(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStop(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testVarsWithNotActive(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testWarningUnchecked(): success
> 
>     ===============================================
>     jdk/jshell/ToolBasicTest.java
>     Total tests run: 38, Failures: 1, Skips: 0
>     ===============================================
> 
>     STDERR:
>     java.io.EOFException
>             at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
>             at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
>             at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
>             at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
>             at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
>             at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
>             at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.Exception: failures: 1
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
> https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

@turbanoff Can you run the tests in the en_US locale? I suspect some of these tests can't run in all locales. Also can you check your environment to ensure the file paths for F: are consistent (I suspect you have a mix of f: and F: in the environment).

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

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

From redestad at openjdk.java.net  Mon Feb 15 14:55:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Feb 2021 14:55:46 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
Message-ID: <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>

On Mon, 15 Feb 2021 11:22:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
> 
> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
> 
> Testing: tier1-3

On the best-case microbenchmark (the byte stream is all ASCII), speed-ups are quite telling:

Before:
Benchmark                                        (charsetName)  (length)  Mode  Cnt       Score       Error  Units
ByteStreamDecoder.readStringReader                    US-ASCII       256  avgt   10    2085.399 ?    66.522  ns/op
ByteStreamDecoder.readStringReader                    US-ASCII      4096  avgt   10   12466.702 ?   747.116  ns/op
ByteStreamDecoder.readStringReader                    US-ASCII     25000  avgt   10  123508.987 ?  3583.345  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-1       256  avgt   10    1894.185 ?    51.772  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-1      4096  avgt   10    8117.404 ?   594.708  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-1     25000  avgt   10   99409.792 ? 28308.936  ns/op
ByteStreamDecoder.readStringReader                       UTF-8       256  avgt   10    2090.337 ?    56.500  ns/op
ByteStreamDecoder.readStringReader                       UTF-8      4096  avgt   10   11698.221 ?   898.910  ns/op
ByteStreamDecoder.readStringReader                       UTF-8     25000  avgt   10   66568.987 ?  4204.361  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-6       256  avgt   10    3061.130 ?   120.132  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-6      4096  avgt   10   24623.494 ?  1916.362  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-6     25000  avgt   10  139138.140 ?  7109.636  ns/op
ByteStreamDecoder.readStringReader                       MS932       256  avgt   10    2612.535 ?    98.638  ns/op
ByteStreamDecoder.readStringReader                       MS932      4096  avgt   10   18843.438 ?  1767.822  ns/op
ByteStreamDecoder.readStringReader                       MS932     25000  avgt   10  119923.997 ? 18560.065  ns/op

After:
Benchmark                                        (charsetName)  (length)  Mode  Cnt       Score       Error  Units
ByteStreamDecoder.readStringReader                    US-ASCII       256  avgt   10    1556.588 ?    37.083  ns/op
ByteStreamDecoder.readStringReader                    US-ASCII      4096  avgt   10    3290.627 ?   125.327  ns/op
ByteStreamDecoder.readStringReader                    US-ASCII     25000  avgt   10   13118.794 ?   597.086  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-1       256  avgt   10    1525.460 ?    36.510  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-1      4096  avgt   10    3051.887 ?   113.036  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-1     25000  avgt   10   11401.228 ?   563.124  ns/op
ByteStreamDecoder.readStringReader                       UTF-8       256  avgt   10    1596.878 ?    43.824  ns/op
ByteStreamDecoder.readStringReader                       UTF-8      4096  avgt   10    3349.961 ?   119.278  ns/op
ByteStreamDecoder.readStringReader                       UTF-8     25000  avgt   10   13273.403 ?   591.600  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-6       256  avgt   10    1602.328 ?    44.092  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-6      4096  avgt   10    3403.312 ?   107.516  ns/op
ByteStreamDecoder.readStringReader                  ISO-8859-6     25000  avgt   10   13163.468 ?   709.642  ns/op
ByteStreamDecoder.readStringReader                       MS932       256  avgt   10    1602.837 ?    32.021  ns/op
ByteStreamDecoder.readStringReader                       MS932      4096  avgt   10    3379.439 ?    87.716  ns/op
ByteStreamDecoder.readStringReader                       MS932     25000  avgt   10   13376.980 ?   669.983  ns/op

Performance degrades when you mix in non-ASCII characters, but so does the `new String(byte[], Charset)` baseline. While there might be algorithmic refinements possible to improve on some of the non-ASCII variants I'm happy to leave that to a follow-up and keep this RFE reasonably straightforward.

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

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

From redestad at openjdk.java.net  Mon Feb 15 14:55:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Feb 2021 14:55:46 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths
Message-ID: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>

This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.

- Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
- Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
- Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.

Testing: tier1-3

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

Commit messages:
 - Safer publication of JavaLangAccess
 - Logic error
 - Move creation of JavaLangAccess up before creating System.in/out
 - Fix typo (caught by Test4625418.java)
 - Merge branch 'master' into streamdecoder
 - Let decoders use String intrinsics to inflate ASCII-only bytes
 - Remove trailing spaces
 - Add microbenchmark
 - Simplify and improve StreamDecoder/-Encoder

Changes: https://git.openjdk.java.net/jdk/pull/2574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2574&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261744
  Stats: 706 lines in 13 files changed: 300 ins; 107 del; 299 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574

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

From redestad at openjdk.java.net  Mon Feb 15 15:19:01 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Feb 2021 15:19:01 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
Message-ID: <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>

> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
> 
> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
> 
> Testing: tier1-3

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

  Revert rem assertions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2574/files
  - new: https://git.openjdk.java.net/jdk/pull/2574/files/8da49e16..b0bf8cfb

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

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

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

From jboes at openjdk.java.net  Mon Feb 15 18:18:39 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Feb 2021 18:18:39 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
 <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
Message-ID: <lR915nPeGioI4oTObfzDIcoVACkXvusnR7rF5R86k10=.739f8477-c380-4012-921e-335b937c2aea@github.com>

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This fours tests pass without problems, when I run them separately.
>> 
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
>> 
>>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>>     
>>     Building target 'test' in configuration 'windows-x86_64-server-release'
>>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Passed: sun/security/tools/keytool/DefaultOptions.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR
>>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>                                                              1     1     0     0
>>     ==============================
>>     TEST SUCCESS
>> 
>>     Finished building target 'test' in configuration 'windows-x86_64-server-release'
>
> ## jdk/jshell/ToolBasicTest.java
>     
>     make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"
> 
>     STDOUT:
>     [TestNG] Running:
>       jdk/jshell/ToolBasicTest.java
> 
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromList(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.test8142447(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testAddExports(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadSourceJarClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathDirectory(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathJar(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testConstrainedUpdates(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testCtrlD(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testEnvInStartUp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNegative(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNormal(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackSilent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testHistoryReference(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testIndent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testInterrupt(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testLoadingFromArgs(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpen(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenFileOverHttp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenLocalFileUrl(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenResource(): failure
>     java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
>      expected [3.14] but found [3,14]
>             at org.testng.Assert.fail(Assert.java:94)
>             at org.testng.Assert.failNotEquals(Assert.java:496)
>             at org.testng.Assert.assertEquals(Assert.java:125)
>             at org.testng.Assert.assertEquals(Assert.java:178)
>             at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
>             at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
>             at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
>             at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
>             at java.base/java.io.PrintStream.write(PrintStream.java:536)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
>             at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
>             at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
>             at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
>             at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
>             at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
>             at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
>             at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
>             at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRedeclareVariableNoInit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRemoteExit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerun(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerunIdRange(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testReset(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartRetain(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartupFileOption(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStop(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testVarsWithNotActive(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testWarningUnchecked(): success
> 
>     ===============================================
>     jdk/jshell/ToolBasicTest.java
>     Total tests run: 38, Failures: 1, Skips: 0
>     ===============================================
> 
>     STDERR:
>     java.io.EOFException
>             at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
>             at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
>             at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
>             at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
>             at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
>             at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
>             at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.Exception: failures: 1
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
> https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

Hi @turbanoff, I ran tier 1-3 in our build and test system and can't reproduce the errors, they seem to be specific to the environment, as Alan hinted at. I also ran the jdk_jfr tests, which came back all clear. 
On another note, let's drop the change in sun.net.www.MimeLauncher, it's a jdk-internal class that is no longer used and can likely be removed. I opened a separate issue for that: https://bugs.openjdk.java.net/browse/JDK-8261750.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 18:33:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 18:33:00 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes from MimeLauncher

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6a8a3ae6..6614a10f

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

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

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

From mcimadamore at openjdk.java.net  Mon Feb 15 18:53:42 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 15 Feb 2021 18:53:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
Message-ID: <bGxQrdluW173rFjTwG5zYUl1cZwn8lvGizAGigtKVjY=.b3ddba92-d8f0-48d3-a99e-4a102c447832@github.com>

On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes from MimeLauncher

The changes to sjavac changes look good

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

Marked as reviewed by mcimadamore (Reviewer).

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

From alanb at openjdk.java.net  Mon Feb 15 19:25:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Feb 2021 19:25:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
Message-ID: <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>

On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes from MimeLauncher

src/java.management/share/classes/javax/management/loading/MLet.java line 1149:

> 1147:                      file.deleteOnExit();
> 1148:                      Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
> 1149:                      if (file.exists()) {

You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 19:47:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 19:47:00 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  remove unnecessary file.exists() check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6614a10f..6e71e961

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 19:47:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 19:47:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
 <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>
Message-ID: <7bSIORe_urCOaP-rcSwcaRkhFU0rymCRLOk5s3t3PF4=.c340769a-e407-44c1-8704-fc7ea5eb7411@github.com>

On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes from MimeLauncher
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 1149:
> 
>> 1147:                      file.deleteOnExit();
>> 1148:                      Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
>> 1149:                      if (file.exists()) {
> 
> You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds.

You are right. Fixed.

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

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

From github.com+471021+marschall at openjdk.java.net  Mon Feb 15 19:59:43 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 15 Feb 2021 19:59:43 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
Message-ID: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>

On Mon, 15 Feb 2021 11:30:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
>> 
>> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
>> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
>> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
>> 
>> Testing: tier1-3
>
> On the best-case microbenchmark (the byte stream is all ASCII), speed-ups are quite telling:
> 
> Before:
> Benchmark                                        (charsetName)  (length)  Mode  Cnt       Score       Error  Units
> ByteStreamDecoder.readStringReader                    US-ASCII       256  avgt   10    2085.399 ?    66.522  ns/op
> ByteStreamDecoder.readStringReader                    US-ASCII      4096  avgt   10   12466.702 ?   747.116  ns/op
> ByteStreamDecoder.readStringReader                    US-ASCII     25000  avgt   10  123508.987 ?  3583.345  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-1       256  avgt   10    1894.185 ?    51.772  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-1      4096  avgt   10    8117.404 ?   594.708  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-1     25000  avgt   10   99409.792 ? 28308.936  ns/op
> ByteStreamDecoder.readStringReader                       UTF-8       256  avgt   10    2090.337 ?    56.500  ns/op
> ByteStreamDecoder.readStringReader                       UTF-8      4096  avgt   10   11698.221 ?   898.910  ns/op
> ByteStreamDecoder.readStringReader                       UTF-8     25000  avgt   10   66568.987 ?  4204.361  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-6       256  avgt   10    3061.130 ?   120.132  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-6      4096  avgt   10   24623.494 ?  1916.362  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-6     25000  avgt   10  139138.140 ?  7109.636  ns/op
> ByteStreamDecoder.readStringReader                       MS932       256  avgt   10    2612.535 ?    98.638  ns/op
> ByteStreamDecoder.readStringReader                       MS932      4096  avgt   10   18843.438 ?  1767.822  ns/op
> ByteStreamDecoder.readStringReader                       MS932     25000  avgt   10  119923.997 ? 18560.065  ns/op
> 
> After:
> Benchmark                                        (charsetName)  (length)  Mode  Cnt       Score       Error  Units
> ByteStreamDecoder.readStringReader                    US-ASCII       256  avgt   10    1556.588 ?    37.083  ns/op
> ByteStreamDecoder.readStringReader                    US-ASCII      4096  avgt   10    3290.627 ?   125.327  ns/op
> ByteStreamDecoder.readStringReader                    US-ASCII     25000  avgt   10   13118.794 ?   597.086  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-1       256  avgt   10    1525.460 ?    36.510  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-1      4096  avgt   10    3051.887 ?   113.036  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-1     25000  avgt   10   11401.228 ?   563.124  ns/op
> ByteStreamDecoder.readStringReader                       UTF-8       256  avgt   10    1596.878 ?    43.824  ns/op
> ByteStreamDecoder.readStringReader                       UTF-8      4096  avgt   10    3349.961 ?   119.278  ns/op
> ByteStreamDecoder.readStringReader                       UTF-8     25000  avgt   10   13273.403 ?   591.600  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-6       256  avgt   10    1602.328 ?    44.092  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-6      4096  avgt   10    3403.312 ?   107.516  ns/op
> ByteStreamDecoder.readStringReader                  ISO-8859-6     25000  avgt   10   13163.468 ?   709.642  ns/op
> ByteStreamDecoder.readStringReader                       MS932       256  avgt   10    1602.837 ?    32.021  ns/op
> ByteStreamDecoder.readStringReader                       MS932      4096  avgt   10    3379.439 ?    87.716  ns/op
> ByteStreamDecoder.readStringReader                       MS932     25000  avgt   10   13376.980 ?   669.983  ns/op
> 
> Performance degrades when you mix in non-ASCII characters, but so does the `new String(byte[], Charset)` baseline. While there might be algorithmic refinements possible to improve on some of the non-ASCII variants I'm happy to leave that to a follow-up and keep this RFE reasonably straightforward.

Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?

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

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

From redestad at openjdk.java.net  Mon Feb 15 20:37:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Feb 2021 20:37:39 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
 <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>
Message-ID: <Diq8n-0j-RdDUxHCFmlyen5iCcxpKfHuDGakUhXkBOc=.c54259f1-9a65-4ea3-98f0-2aaaa8222a65@github.com>

On Mon, 15 Feb 2021 19:56:32 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?

Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.

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

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

From alanb at openjdk.java.net  Tue Feb 16 07:42:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 16 Feb 2021 07:42:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
Message-ID: <VUKHVu4XUJspWcev-cgNUDbKQWjIJZlg3pHgbn8u808=.e291d039-2af1-4d6e-ba17-bc38f8daee54@github.com>

On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   remove unnecessary file.exists() check

Thanks for perceiving with this one. I think you've addressed all issues in the latest revision.

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

Marked as reviewed by alanb (Reviewer).

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

From redestad at openjdk.java.net  Tue Feb 16 13:48:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Feb 2021 13:48:43 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <Diq8n-0j-RdDUxHCFmlyen5iCcxpKfHuDGakUhXkBOc=.c54259f1-9a65-4ea3-98f0-2aaaa8222a65@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
 <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>
 <Diq8n-0j-RdDUxHCFmlyen5iCcxpKfHuDGakUhXkBOc=.c54259f1-9a65-4ea3-98f0-2aaaa8222a65@github.com>
Message-ID: <r_Mje1QscdeuUSMskIVrEvfEqUOBAMVxhhwiskUIroE=.853e2c06-07a8-406a-99f4-a40ba01c25da@github.com>

On Mon, 15 Feb 2021 20:34:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
> 
> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.

Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617

It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication.

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

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

From alanb at openjdk.java.net  Tue Feb 16 15:08:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 16 Feb 2021 15:08:38 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <r_Mje1QscdeuUSMskIVrEvfEqUOBAMVxhhwiskUIroE=.853e2c06-07a8-406a-99f4-a40ba01c25da@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
 <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>
 <Diq8n-0j-RdDUxHCFmlyen5iCcxpKfHuDGakUhXkBOc=.c54259f1-9a65-4ea3-98f0-2aaaa8222a65@github.com>
 <r_Mje1QscdeuUSMskIVrEvfEqUOBAMVxhhwiskUIroE=.853e2c06-07a8-406a-99f4-a40ba01c25da@github.com>
Message-ID: <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com>

On Tue, 16 Feb 2021 13:45:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
>> 
>> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.
>
>> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
>> 
>> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.
> 
> Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617
> 
> It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication.

This looks a really good change and it's great can these decoders get the benefit of the instrinics work.

ISO_8869_1.decodeArrayLoop using JLA.inflate looks a bit strange and maybe we can rename the method in the shared secret to inflatedCopy or just copy. or just add a comment. The reason is that code outside of java.lang shouldn't know anything about String's internals and inflation.

The reformatting changes to StreamEncoder/StreamDecoder make it hard to see if there are any actual changes. Is there anything we should look at? It's okay to include this cleanup, I can't tell what happened with this source file.

I want to study the change System.setJavaLangAccess a bit further to understand why this is needed (I know there is a awkward bootstrapping issue here).

I expect Naoto will want to review this PR too.

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

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

From redestad at openjdk.java.net  Tue Feb 16 15:16:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Feb 2021 15:16:38 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
 <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>
 <Diq8n-0j-RdDUxHCFmlyen5iCcxpKfHuDGakUhXkBOc=.c54259f1-9a65-4ea3-98f0-2aaaa8222a65@github.com>
 <r_Mje1QscdeuUSMskIVrEvfEqUOBAMVxhhwiskUIroE=.853e2c06-07a8-406a-99f4-a40ba01c25da@github.com>
 <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com>
Message-ID: <IxxVs4R4ggIEhhWJHGABveVIHyfsXzYDLugKbJyJdhY=.91d343b5-ed8c-4770-9844-ffb551bf61c3@github.com>

On Tue, 16 Feb 2021 15:05:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
>>> 
>>> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.
>> 
>> Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617
>> 
>> It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication.
>
> This looks a really good change and it's great can these decoders get the benefit of the instrinics work.
> 
> ISO_8869_1.decodeArrayLoop using JLA.inflate looks a bit strange and maybe we can rename the method in the shared secret to inflatedCopy or just copy. or just add a comment. The reason is that code outside of java.lang shouldn't know anything about String's internals and inflation.
> 
> The reformatting changes to StreamEncoder/StreamDecoder make it hard to see if there are any actual changes. Is there anything we should look at? It's okay to include this cleanup, I can't tell what happened with this source file.
> 
> I want to study the change System.setJavaLangAccess a bit further to understand why this is needed (I know there is a awkward bootstrapping issue here).
> 
> I expect Naoto will want to review this PR too.

I added the `Inflated copy from byte[] to char[], as defined by StringLatin1` comment to the `inflate` method in `JavaLangAccess`, but you're probably right and it would be good to make the name more explicit when exporting it outside of the package internal use. How about `inflateBytesToChars`?

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

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

From redestad at openjdk.java.net  Tue Feb 16 15:53:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Feb 2021 15:53:38 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <ivbs5OM__Dbsaos4hl6Y46ro0IjuWS1VBPGflXwJeaQ=.be6ee85f-b574-43a0-af30-e1eab5b33912@github.com>
 <6tROAk1LyJ8PstwiHo36kKTTILhe3GYbqH8ynB8Y2dM=.8adc158d-89fb-45c0-a138-e41d97c5f743@github.com>
 <Diq8n-0j-RdDUxHCFmlyen5iCcxpKfHuDGakUhXkBOc=.c54259f1-9a65-4ea3-98f0-2aaaa8222a65@github.com>
 <r_Mje1QscdeuUSMskIVrEvfEqUOBAMVxhhwiskUIroE=.853e2c06-07a8-406a-99f4-a40ba01c25da@github.com>
 <28qBwyuK3o49JhpwdN1OI07cZ7uNcol7DRxjKiUzZRk=.56bf5bf9-7cc8-45fd-abfd-c78207997b38@github.com>
Message-ID: <AK1L96KSS7LpjPyJJvP68awcV8oFU5hyApTzVEMgR28=.c97ceb2a-4ea9-41df-ac20-0aa95d13ed0f@github.com>

On Tue, 16 Feb 2021 15:05:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The reformatting changes to StreamEncoder/StreamDecoder make it hard to see if there are any actual changes. Is there anything we should look at? It's okay to include this cleanup, I can't tell what happened with this source file.
> 

Apart from a few things being made final that weren't, and a flattening of a back-to-back Charset lookup in one of the constructors its mostly formatting cleanups.

> I want to study the change System.setJavaLangAccess a bit further to understand why this is needed (I know there is a awkward bootstrapping issue here).

Right, I'm not exactly sure why the more limited changes I attempted in 5f4e87f failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible.

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

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

From jboes at openjdk.java.net  Tue Feb 16 17:23:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 16 Feb 2021 17:23:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:44:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:44:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
 <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>
Message-ID: <04LMLK3YO1cEPtchQl39EhAgeSN2mvEdQONQg_UzLKc=.7d1ce34f-04b6-4248-ba32-efec0c24b915@github.com>

On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   fix review comments
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230:
> 
>> 228:                 // Copy the entire input stream into an InputStream that does
>> 229:                 // support mark
>> 230:                 is = new ByteArrayInputStream(is.readAllBytes());
> 
> I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do:
> 
> PKCS7 pkcs7 = new PKCS7(is.readAllBytes());

Good idea. Will improve.
By the way, code in `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)`  looks suspicious: it reads only `InputStream.available()` bytes, which doesn't make much sense to me.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:47:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:47:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
 <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>
Message-ID: <NsXuEr-MY1rbBYudsF_FG2EIDaJY-_QpzqgR4myHQ_g=.ee29d6c1-4eb8-414a-a722-67bb950c3894@github.com>

On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   fix review comments
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 93:
> 
>> 91:         if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) {
>> 92:             man = new Manifest();
>> 93:             byte[] bytes = new BufferedInputStream(this).readAllBytes();
> 
> I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7.
> 
> In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly.

Usage of `BufferedInputStream` removed

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:58:57 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:58:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v12]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <ZbjR8LxLcrLYtzwOCUh2PO9NtNI25iXTQwbpRJb3YKU=.bafdce7c-94ca-41b0-87df-5ab52f03e9c5@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6e71e961..1b30471d

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

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

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

From naoto at openjdk.java.net  Tue Feb 16 19:53:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 16 Feb 2021 19:53:41 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
Message-ID: <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>

On Mon, 15 Feb 2021 15:19:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
>> 
>> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
>> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
>> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert rem assertions

Great improvement! Looks good to me overall. I wondered about the changes in JLA as Alan already mentioned.

src/java.base/share/classes/java/lang/String.java line 1017:

> 1015:      * @return the number of bytes successfully decoded, at most len
> 1016:      */
> 1017:     /* package-private */

Some more explanation would be helpful here, as it is accessed from System for shared secrets.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 48:

> 46: import jdk.internal.module.ServicesCatalog;
> 47: import jdk.internal.reflect.ConstantPool;
> 48: import jdk.internal.vm.annotation.IntrinsicCandidate;

Not needed.

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

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

From redestad at openjdk.java.net  Tue Feb 16 20:22:20 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Feb 2021 20:22:20 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v3]
In-Reply-To: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
Message-ID: <sIRgq23FItAEV-Ii9t3CVREi3eNxo-o_hNzSZn2LpWY=.362da47c-5424-4fa2-a309-93ef74c4790e@github.com>

> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
> 
> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
> 
> Testing: tier1-3

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Copyrights
 - Review fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2574/files
  - new: https://git.openjdk.java.net/jdk/pull/2574/files/b0bf8cfb..367be2a5

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

  Stats: 15 lines in 10 files changed: 1 ins; 1 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574

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

From redestad at openjdk.java.net  Tue Feb 16 20:22:25 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Feb 2021 20:22:25 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
 <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
Message-ID: <d7UYSV5CO9E2hNl-Kdphn2vL4VLQLvEt41LwPEWhAng=.a1c45cd9-d57f-4b69-924a-c199c2a69fce@github.com>

On Tue, 16 Feb 2021 19:48:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert rem assertions
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 48:
> 
>> 46: import jdk.internal.module.ServicesCatalog;
>> 47: import jdk.internal.reflect.ConstantPool;
>> 48: import jdk.internal.vm.annotation.IntrinsicCandidate;
> 
> Not needed.

Fixed

> src/java.base/share/classes/java/lang/String.java line 1017:
> 
>> 1015:      * @return the number of bytes successfully decoded, at most len
>> 1016:      */
>> 1017:     /* package-private */
> 
> Some more explanation would be helpful here, as it is accessed from System for shared secrets.

Ok, added a short comment

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

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

From bpb at openjdk.java.net  Tue Feb 16 23:45:47 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 16 Feb 2021 23:45:47 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <FTke6oVlaDcxPk-daShaF2dmGHG6VphYyl6zhwrAz4U=.9f56e79b-620c-4652-9e29-e1152a881fd7@github.com>
References: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
 <FTke6oVlaDcxPk-daShaF2dmGHG6VphYyl6zhwrAz4U=.9f56e79b-620c-4652-9e29-e1152a881fd7@github.com>
Message-ID: <Ogt1s4knTU8l-sPavQA31anqbuV7CCyo5JMUiLRbKxc=.84b0f812-ea92-4247-ad01-2b46ee73c5ef@github.com>

On Wed, 3 Feb 2021 12:05:48 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> I want to discuss the changes of this PR in three sections:
>> 
>> # Deduplications
>> The main focus was to deduplicate code:
>> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I made added an abstract method `UnixUserDefinedAttributeView. maxNameLength()` and kept the other two.
>> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix. BSD-specific adjustments are now done in C.
>> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
>> - For the latter I hade to combine `UnixConstants.ENODATA` and `UnixConstants.ENOATTR` to a platform-agnostic `UnixConstants.XATTR_NOT_FOUND` ??  Warning: While `ENODATA` is no longer used JDK-internally, it might have been used via reflection in downstream projects, thus causing regressions. Maintainers should decide, if we might want to keep `ENODATA` additionally to the new `XATTR_NOT_FOUND`.
>> - Deduplicated code inside of *NativeDispatcher's methods `copyExtendedAttributes(int ofd, int nfd)` and `list()`
>> 
>> # Cleanup / Improvements
>> - On AIX (or other Unix Platforms not explicitly supporting xattr), calling related native methods will result in `ENOTSUP`
>> - `NativeBuffer implements AutoCloseable` and used try-with-resource statements where applicable
>> - changed loop to recursive function for creation of larger buffer, if `flistxattr` fails due to `ERANGE` error (max recursion depth is 5, I don't expect performance benefits from loop unrolling, therefore chose reduced cyclomatic complexity over performance)
>> - Added `UnixNativeDispatcher.SUPPORTS_XATTR` capability and added a shortcut to `UnixFileStore. isExtendedAttributesEnabled(...)` to skip I/O that is known to fail
>> - Removed legacy `dlsym` for xattr-related Linux system calls (fixes JDK-8260691)
>> 
>> # Fixes
>> - `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` now correctly copies xattr on macOS/BSD ([invocation was missing before](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72))
>> - no longer [access `dst.arrayOffset()` without checking](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L201) if `dst.hasArray()` during `read()`. Code is now symmetric with `write()`
>> - fixed [potential resource leak of `nb` during `write()`](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L258), if `file.openForAttributeAccess(...)` fails
>> 
>> 
>> Please note, that while the tests succeed on macOS, ~~so far I didn't manage to run `jtreg:test/jdk/java/nio/file/attribute/` on a Linux CI system due to lack of knowledge or will power ??~~ Edit: Tests succeed on Linux, too.
>
> Ok I managed to get jtreg running in a Linux container now. Looks good:
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/nio/file/attribute               10    10     0     0   
> ==============================
> TEST SUCCESS
> 
> Finished building target 'run-test' in configuration 'linux-x86_64-server-release'

>From what I can tell these changes look all right, but I think it would be easier to understand them if they were broken up into separate PRs. One problem here is that apparently this PR was created from a branch which already had the three commits on it. This causes there to be only one webrev encompassing all the changes in the three commits at once. Had the PR been created from a branch containing only the first commit and the other commits added one by one, then at least there would be an incremental webrev showing the changes made from one commit to the next.

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

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

From bpb at openjdk.java.net  Tue Feb 16 23:54:41 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 16 Feb 2021 23:54:41 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
Message-ID: <Wi1oVqQQU2X7y_jCkhKBgiU9b41jTIHyimz5YFUntgw=.f66745a3-95a8-4986-b1df-dd873a829427@github.com>

On Tue, 5 Jan 2021 00:48:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A couple of implementation notes:
>> 
>> Reader#read(CharBuffer)
>> 
>> on-heap case
>> 
>> I introduced a dedicated path for the on-heap case and directly read into the backing array. This completely avoids the intermediate allocation and copy. Compared to the initial proposal the buffer position is updated. This has to be done because we bypass the buffer and directly read into the array. This also handles the case that #read returns -1.
>> 
>> I am using a c-style array declaration because the rest of the class uses it.
>> 
>> off-heap case
>> 
>> I limit the intermadiate allocation to TRANSFER_BUFFER_SIZE. In order to reduce the total intermediate allocation we now call #read multiple times until the buffer is full or EOF is reached. This changes the behavior slightly as now possibly more data is read. However this should contribute to reduce the overall intermediate allocations.
>> 
>> A lock is acquired to keep the the read atomic. This is consistent with #skip which also holds a lock over multiple #read calls. This is inconsistent with #transferTo which does not acquire a lock over multiple #read calls. 
>> 
>> The implementation took inspiration from java.io.InputStream#readNBytes(int).
>> 
>> InputStreamReader#read(CharBuffer)
>> 
>> Since StreamDecoder is a Reader as well we can simply delegate.
>> 
>> StreamDecoder#read(CharBuffer)
>> 
>> Interestingly this was not implemented even though StreamDecoder internally works on NIO buffers.
>> 
>> on-heap case
>> 
>> We see a performance improvement and the elimination of all intermediate allocation.
>> 
>> StreamDecoder#read(char[], int, int) and InputStreamReader#read(char[], int, int) may get a small improvement as we no longer #slice the buffer.
>> 
>> off-heap case
>> 
>> We see the elimination of all intermediate allocation but a performance penalty because we hit the slow path in #decodeLoop. There is a trade-off here, we could improve the performance to previous levels by introducing intermediate allocation again. I don't know how much the users of off-heap buffers care about introducing intermediate allocation vs maximum throughput.
>> 
>> I was struggling to come up with microbenchmarks because the built in InputStream and Reader implementations are finite but JMH calls the benchmark methods repeatably. I ended up implementing custom infinite InputStream and Reader implementations. The code can be found there:
>> 
>> https://github.com/marschall/reader-benchmarks/tree/master/src/main/java/com/github/marschall/readerbenchmarks
>> 
>> An Excel with charts can be found here:
>> 
>> https://github.com/marschall/reader-benchmarks/raw/master/src/main/resources/4926314.xlsx
>> 
>> I looked for java.io.Reader#read(CharBuffer) users in the JDK and only found java.util.Scanner#readInput(). I wrote a microbenchmark for this but only found minuscule improvements due to regex dominating the runtime.
>> 
>> There seem to be no direct Reader tests in the tier1 suite, the initial code was wrong because I forgot to update the buffer code position but I only found out because some Scanner tests failed.
>
> I changed the JBS issue summary to match the title of this PR so that integration blocker is removed.
> 
> How does the off-heap performance of `InputStreamReader.read(CharBuffer)` compare for the case where only the change to `Reader` is made versus if all your proposed changes are applied?
> 
> Some kind of specific test should likely be included.
> 
> Note that the more recent copyright year is now 2021.

I think the implementation changes here look good. I don't know however whether there is enough coverage in the tests. These should verify that the `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of `read(CharBuffer)` are accurate. If there is already sufficient coverage in the tests in `test/jdk/java/io` then that is good enough and nothing need be added.

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

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

From bpb at openjdk.java.net  Tue Feb 16 23:54:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 16 Feb 2021 23:54:43 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
Message-ID: <cZvuz7rqH6oCKMQZIWGTlS4gbaNil4LlNaoU1NcwE-w=.3a08ce05-02fa-4bcb-8d73-d404f0fe592f@github.com>

On Fri, 12 Feb 2021 09:18:10 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read

test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 34:

> 32: import org.testng.annotations.Test;
> 33: 
> 34: import java.io.*;

It's generally better not to use a wild card.

test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 73:

> 71:         }
> 72: 
> 73:         buffer.clear();

I think `buffer.rewind()` would be more in keeping with the specification verbiage although there will be no practical effect here. Same comment applies below and in the other test `ReadCharBuffer`.

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

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

From sebastian.stenzel at gmail.com  Wed Feb 17 06:10:08 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 07:10:08 +0100
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <Ogt1s4knTU8l-sPavQA31anqbuV7CCyo5JMUiLRbKxc=.84b0f812-ea92-4247-ad01-2b46ee73c5ef@github.com>
References: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
 <FTke6oVlaDcxPk-daShaF2dmGHG6VphYyl6zhwrAz4U=.9f56e79b-620c-4652-9e29-e1152a881fd7@github.com>
 <Ogt1s4knTU8l-sPavQA31anqbuV7CCyo5JMUiLRbKxc=.84b0f812-ea92-4247-ad01-2b46ee73c5ef@github.com>
Message-ID: <AD4BAE9B-8B48-494A-92DF-3F9686CC8D57@gmail.com>


> On 17. Feb 2021, at 00:45, Brian Burkhalter <bpb at openjdk.java.net> wrote:
> 
> From what I can tell these changes look all right, but I think it would be easier to understand them if they were broken up into separate PRs. One problem here is that apparently this PR was created from a branch which already had the three commits on it. This causes there to be only one webrev encompassing all the changes in the three commits at once. Had the PR been created from a branch containing only the first commit and the other commits added one by one, then at least there would be an incremental webrev showing the changes made from one commit to the next.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2363

Ok, then I would propose to close and recreate the PR.

I see two options: Push the first commit, wait for a review, push further commits.

Or: Have only the first commit in this new PR, create a second PR. This requires you to create another ticket for cleanup tasks.

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Feb 17 08:44:40 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 08:44:40 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <Ogt1s4knTU8l-sPavQA31anqbuV7CCyo5JMUiLRbKxc=.84b0f812-ea92-4247-ad01-2b46ee73c5ef@github.com>
References: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
 <FTke6oVlaDcxPk-daShaF2dmGHG6VphYyl6zhwrAz4U=.9f56e79b-620c-4652-9e29-e1152a881fd7@github.com>
 <Ogt1s4knTU8l-sPavQA31anqbuV7CCyo5JMUiLRbKxc=.84b0f812-ea92-4247-ad01-2b46ee73c5ef@github.com>
Message-ID: <q4dpsIcxJspBcp0ZPeGiqJzSNs-POdumKaTtoi5IZU4=.5e811c8a-ff1f-47a0-99b0-871f5b2f2f11@github.com>

On Tue, 16 Feb 2021 23:42:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ok I managed to get jtreg running in a Linux container now. Looks good:
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/nio/file/attribute               10    10     0     0   
>> ==============================
>> TEST SUCCESS
>> 
>> Finished building target 'run-test' in configuration 'linux-x86_64-server-release'
>
> From what I can tell these changes look all right, but I think it would be easier to understand them if they were broken up into separate PRs. One problem here is that apparently this PR was created from a branch which already had the three commits on it. This causes there to be only one webrev encompassing all the changes in the three commits at once. Had the PR been created from a branch containing only the first commit and the other commits added one by one, then at least there would be an incremental webrev showing the changes made from one commit to the next.

Closing this in favour of #2604

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Feb 17 08:44:41 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 08:44:41 GMT
Subject: Withdrawn: JDK-8260966 (fs) Consolidate Linux and macOS
 implementations of UserDefinedFileAttributeView
In-Reply-To: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
References: <f1A5FUO2mPIipzPQdCey1KwP9itMQ_EoN6oIShatX88=.35ae90cd-7fab-401f-863e-170cd3abcc28@github.com>
Message-ID: <vW7oyUvaVCOTdGbwn3kkpQ6Dk84AR8NAuINC6WEMAhw=.3120ff7e-c80b-4a7f-bb49-fb042d5b26b2@github.com>

On Tue, 2 Feb 2021 21:23:04 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

> I want to discuss the changes of this PR in three sections:
> 
> # Deduplications
> The main focus was to deduplicate code:
> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I made added an abstract method `UnixUserDefinedAttributeView. maxNameLength()` and kept the other two.
> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix. BSD-specific adjustments are now done in C.
> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
> - For the latter I hade to combine `UnixConstants.ENODATA` and `UnixConstants.ENOATTR` to a platform-agnostic `UnixConstants.XATTR_NOT_FOUND` ??  Warning: While `ENODATA` is no longer used JDK-internally, it might have been used via reflection in downstream projects, thus causing regressions. Maintainers should decide, if we might want to keep `ENODATA` additionally to the new `XATTR_NOT_FOUND`.
> - Deduplicated code inside of *NativeDispatcher's methods `copyExtendedAttributes(int ofd, int nfd)` and `list()`
> 
> # Cleanup / Improvements
> - On AIX (or other Unix Platforms not explicitly supporting xattr), calling related native methods will result in `ENOTSUP`
> - `NativeBuffer implements AutoCloseable` and used try-with-resource statements where applicable
> - changed loop to recursive function for creation of larger buffer, if `flistxattr` fails due to `ERANGE` error (max recursion depth is 5, I don't expect performance benefits from loop unrolling, therefore chose reduced cyclomatic complexity over performance)
> - Added `UnixNativeDispatcher.SUPPORTS_XATTR` capability and added a shortcut to `UnixFileStore. isExtendedAttributesEnabled(...)` to skip I/O that is known to fail
> - Removed legacy `dlsym` for xattr-related Linux system calls (fixes JDK-8260691)
> 
> # Fixes
> - `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` now correctly copies xattr on macOS/BSD ([invocation was missing before](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72))
> - no longer [access `dst.arrayOffset()` without checking](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L201) if `dst.hasArray()` during `read()`. Code is now symmetric with `write()`
> - fixed [potential resource leak of `nb` during `write()`](https://github.com/openjdk/jdk/blob/jdk-17+7/src/java.base/linux/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java#L258), if `file.openForAttributeAccess(...)` fails
> 
> 
> Please note, that while the tests succeed on macOS, ~~so far I didn't manage to run `jtreg:test/jdk/java/nio/file/attribute/` on a Linux CI system due to lack of knowledge or will power ??~~ Edit: Tests succeed on Linux, too.

This pull request has been closed without being integrated.

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Feb 17 08:58:09 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 08:58:09 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of
 UserDefinedFileAttributeView
Message-ID: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>

Deduplicated code in these classes:
- `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`.
- `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions.
- `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`

For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587)

This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72).

I plan to add further commits to clean up this code, once the deduplication is reviewed.

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

Commit messages:
 - deduplicate FileStore.isExtendedAttributesEnabled(...)
 - Deduplicate LinuxUserDefinedFileAttributeView + BsdUserDefinedFileAttributeView

Changes: https://git.openjdk.java.net/jdk/pull/2604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2604&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260966
  Stats: 1163 lines in 16 files changed: 162 ins; 964 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2604/head:pull/2604

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

From alanb at openjdk.java.net  Wed Feb 17 09:24:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Feb 2021 09:24:39 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
Message-ID: <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>

On Wed, 17 Feb 2021 08:41:43 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

> Deduplicated code in these classes:
> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`.
> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions.
> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
> 
> For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587)
> 
> This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72).
> 
> I plan to add further commits to clean up this code, once the deduplication is reviewed.

Thanks for spitting up the steps in the refactoring as it makes it easier to review. One other thing that is still creating noise in the patch is that I think your IDE or editor has changed the formatting to 8 space indent in several places where the original code in LinuxUserDefinedFileAttributeView.java was 4 space indent. We've typically used 4 space indent in this code. If you revert those indentations then I think it will reduce the size of the patch and make it easy for us to see where the real changes are.

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

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

From sebastian.stenzel at gmail.com  Wed Feb 17 09:48:25 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 10:48:25 +0100
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
Message-ID: <6686D817-1BDE-4261-8864-1A8A6699A2E2@gmail.com>


> On 17. Feb 2021, at 10:24, Alan Bateman <alanb at openjdk.java.net> wrote:
> 
> On Wed, 17 Feb 2021 08:41:43 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:
> 
>> Deduplicated code in these classes:
>> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`.
>> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions.
>> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
>> 
>> For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587)
>> 
>> This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72).
>> 
>> I plan to add further commits to clean up this code, once the deduplication is reviewed.
> 
> Thanks for spitting up the steps in the refactoring as it makes it easier to review. One other thing that is still creating noise in the patch is that I think your IDE or editor has changed the formatting to 8 space indent in several places where the original code in LinuxUserDefinedFileAttributeView.java was 4 space indent. We've typically used 4 space indent in this code. If you revert those indentations then I think it will reduce the size of the patch and make it easy for us to see where the real changes are.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2604

Can you show me an example, where you see an 8 space indentation?

From alanb at openjdk.java.net  Wed Feb 17 09:56:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Feb 2021 09:56:50 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
Message-ID: <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>

On Wed, 17 Feb 2021 09:22:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Deduplicated code in these classes:
>> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`.
>> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions.
>> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
>> 
>> For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587)
>> 
>> This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72).
>> 
>> I plan to add further commits to clean up this code, once the deduplication is reviewed.
>
> Thanks for spitting up the steps in the refactoring as it makes it easier to review. One other thing that is still creating noise in the patch is that I think your IDE or editor has changed the formatting to 8 space indent in several places where the original code in LinuxUserDefinedFileAttributeView.java was 4 space indent. We've typically used 4 space indent in this code. If you revert those indentations then I think it will reduce the size of the patch and make it easy for us to see where the real changes are.

> _Mailing list message from [Sebastian Stenzel](mailto:sebastian.stenzel at gmail.com) on [nio-dev](mailto:nio-dev at openjdk.java.net):_
> 
> Can you show me an example, where you see an 8 space indentation?

UnixUserDefinedFileAttributeView L41, L58, L73, L125-126, L151-152, L207, ...  so looks like changes from the original code in LinuxUserDefinedFileAttributeView, might be the IDE did it. It's not a big deal, just noise in the patch.

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Feb 17 10:09:59 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 10:09:59 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView [v2]
In-Reply-To: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
Message-ID: <q0xg6CKDxVL3NdswoU21fFhfNJbk2dh1I58UEOsgIcU=.fa2cb48a-f80e-4229-8214-366575b23020@github.com>

> Deduplicated code in these classes:
> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`.
> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions.
> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()`
> 
> For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587)
> 
> This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72).
> 
> I plan to add further commits to clean up this code, once the deduplication is reviewed.

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

  Restored indentation from former LinuxUserDefinedFileAttributeView and LinuxNativeDispatcher

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2604/files
  - new: https://git.openjdk.java.net/jdk/pull/2604/files/062c53aa..79b623c2

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

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Wed Feb 17 13:12:40 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Wed, 17 Feb 2021 13:12:40 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
 <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>
Message-ID: <GkjTi3pCpFJFekVtDDnJjSjAy3P7UkSwB4uSHT-DPqQ=.d92de7e3-6816-4ae4-9bc3-aa2c008241b2@github.com>

On Wed, 17 Feb 2021 09:53:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks for spitting up the steps in the refactoring as it makes it easier to review. One other thing that is still creating noise in the patch is that I think your IDE or editor has changed the formatting to 8 space indent in several places where the original code in LinuxUserDefinedFileAttributeView.java was 4 space indent. We've typically used 4 space indent in this code. If you revert those indentations then I think it will reduce the size of the patch and make it easy for us to see where the real changes are.
>
>> _Mailing list message from [Sebastian Stenzel](mailto:sebastian.stenzel at gmail.com) on [nio-dev](mailto:nio-dev at openjdk.java.net):_
>> 
>> Can you show me an example, where you see an 8 space indentation?
> 
> UnixUserDefinedFileAttributeView L41, L58, L73, L125-126, L151-152, L207, ...  so looks like changes from the original code in LinuxUserDefinedFileAttributeView, might be the IDE did it. It's not a big deal, just noise in the patch.

@bplb @AlanBateman Now that there is a webrev just for the deduplication, can I already amend further changes or wait for each set of changes to be reviewed individually? Sorry, I'm still new to the processes.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Feb 17 14:51:52 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Feb 2021 14:51:52 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible
Message-ID: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>

Non-static classes hold a link to their parent classes, which in many cases can be avoided.

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

Commit messages:
 - 8261880: Change nested classes in java.base to static nested classes where possible

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

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

From alanb at openjdk.java.net  Wed Feb 17 15:39:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Feb 2021 15:39:42 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
Message-ID: <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>

On Fri, 12 Feb 2021 09:18:10 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read

src/java.base/share/classes/java/io/Reader.java line 221:

> 219:                     // if the last call to read returned -1 or the number of bytes
> 220:                     // requested have been read then break
> 221:                 } while (n >= 0 && remaining > 0);

The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder.

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

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

From redestad at openjdk.java.net  Wed Feb 17 16:27:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Feb 2021 16:27:40 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible
In-Reply-To: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
Message-ID: <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>

On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192:

> 190: 
> 191:     /* Placeholder class for DelegatingMethodHandles generated ahead of time */
> 192:     static final class Holder {}

For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Feb 17 16:38:04 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Feb 2021 16:38:04 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
Message-ID: <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>

On Wed, 17 Feb 2021 16:24:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192:
> 
>> 190: 
>> 191:     /* Placeholder class for DelegatingMethodHandles generated ahead of time */
>> 192:     static final class Holder {}
> 
> For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not.

I'll just revert them

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Feb 17 16:38:03 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Feb 2021 16:38:03 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
Message-ID: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

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

  8261880: Remove static from declarations of Holder nested classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2589/files
  - new: https://git.openjdk.java.net/jdk/pull/2589/files/5650cce4..c6f9cf6b

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

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

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

From github.com+7806504+liach at openjdk.java.net  Wed Feb 17 16:38:04 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Wed, 17 Feb 2021 16:38:04 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
 <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
Message-ID: <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>

On Wed, 17 Feb 2021 16:32:39 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line 192:
>> 
>>> 190: 
>>> 191:     /* Placeholder class for DelegatingMethodHandles generated ahead of time */
>>> 192:     static final class Holder {}
>> 
>> For the four `Holder` classes in `java.lang.invoke`, the class is generated when running jlink via `java.lang.invoke.GenerateJLIClassesHelper`. To stay in sync with the definition you'd have to update that code. Also, since these `Holder` classes will only contain static methods and are never instantiated then I'm not sure it matters whether the classes are static or not.
>
> I'll just revert them

For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors.

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

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

From alanb at openjdk.java.net  Wed Feb 17 17:24:46 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Feb 2021 17:24:46 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
 <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
 <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>
Message-ID: <vnqgSD6xTUObnu2ModbBdi5Lv2a4w_dMC7lA88abJ8s=.3a325124-b181-4fc2-9e5b-c922f3dea2ba@github.com>

On Wed, 17 Feb 2021 17:19:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Great improvement! Looks good to me overall. I wondered about the changes in JLA as Alan already mentioned.
>
>> Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible.
> 
> The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done.

> but you're probably right and it would be good to make the name more explicit when exporting it outside of the package internal use. How about `inflateBytesToChars`?

That should be okay.

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

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

From alanb at openjdk.java.net  Wed Feb 17 17:24:46 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Feb 2021 17:24:46 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
 <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
Message-ID: <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>

On Tue, 16 Feb 2021 19:51:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert rem assertions
>
> Great improvement! Looks good to me overall. I wondered about the changes in JLA as Alan already mentioned.

> Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible.

The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done.

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

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

From redestad at openjdk.java.net  Wed Feb 17 17:27:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Feb 2021 17:27:56 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
 <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
 <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>
Message-ID: <OtixXl1Wa5_9MCYwFiYnGzeMHGf-mNhmI2RYvKmxjP8=.66c14fad-5ee9-4332-b290-a0d56c99a990@github.com>

On Wed, 17 Feb 2021 16:35:02 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> I'll just revert them
>
> For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors.

Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9.

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

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

From github.com+828220+forax at openjdk.java.net  Wed Feb 17 17:44:47 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 17 Feb 2021 17:44:47 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <OtixXl1Wa5_9MCYwFiYnGzeMHGf-mNhmI2RYvKmxjP8=.66c14fad-5ee9-4332-b290-a0d56c99a990@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <UZy1V-oDmJvUKTbOmvY0wCGZTp2i4PCIkfSXadeRhPk=.b1b22b62-dbc0-4eb5-ab93-b961bba222d1@github.com>
 <yxujdsJJTu7oxQtJzizVrnC9qRSfHLWaqm1MTM6VcJM=.3371ad65-45fa-4cf0-81c7-9771fc6630ed@github.com>
 <PPTUVPzAXS-n0tLmdpQjmkropBQ_O4VtLeTrxcU7wEY=.40ee9124-65f7-405c-9a7f-18a31e6a6871@github.com>
 <OtixXl1Wa5_9MCYwFiYnGzeMHGf-mNhmI2RYvKmxjP8=.66c14fad-5ee9-4332-b290-a0d56c99a990@github.com>
Message-ID: <zBnyv_oN9SrC_4C-zuzrW2bh79mbX5BmujBk8MPLgL0=.bbcf56a4-1bc9-4bf7-9d54-0cfd8cbcd30d@github.com>

On Wed, 17 Feb 2021 17:24:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> For static methods, since in java language you cannot declare static method in instance inner classes, I'd say making them static makes more sense language-wise. Also making them static reduces compiler synthetic instance field and constructors.
>
> Incidentally, Java-the-language allows static methods in inner instance classes since JDK 16. And I'm not sure this was ever a restriction at the JVMS level since we've been generating static methods (using ASM) into these inner instance classes since at least JDK 9.

Inner classes doesn't really exist for the JVM, it's just an attribute (in fact, a pair of attributes) that is read/write by javac (it's very similar to the way generics work).
So it is Ok to have static methods in inner classes since Java 1.1 from the JVM POV with the caveat that you may not be all to call them from Java-the-language.
Also since Java 11, inner classes are also nestmate and those attributes (NestHost/NestMembers) change the behavior of the VM.

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

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

From bpb at openjdk.java.net  Wed Feb 17 18:09:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 17 Feb 2021 18:09:39 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <GkjTi3pCpFJFekVtDDnJjSjAy3P7UkSwB4uSHT-DPqQ=.d92de7e3-6816-4ae4-9bc3-aa2c008241b2@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
 <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>
 <GkjTi3pCpFJFekVtDDnJjSjAy3P7UkSwB4uSHT-DPqQ=.d92de7e3-6816-4ae4-9bc3-aa2c008241b2@github.com>
Message-ID: <z4Thba6HiKZhHvh3Yjx71aVSl0uFcYHr7o8dSG-SXB4=.9531593e-64ef-464c-84db-913cca16e7c7@github.com>

On Wed, 17 Feb 2021 13:10:03 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>>> _Mailing list message from [Sebastian Stenzel](mailto:sebastian.stenzel at gmail.com) on [nio-dev](mailto:nio-dev at openjdk.java.net):_
>>> 
>>> Can you show me an example, where you see an 8 space indentation?
>> 
>> UnixUserDefinedFileAttributeView L41, L58, L73, L125-126, L151-152, L207, ...  so looks like changes from the original code in LinuxUserDefinedFileAttributeView, might be the IDE did it. It's not a big deal, just noise in the patch.
>
> @bplb @AlanBateman Now that there is a webrev just for the deduplication, can I already amend further changes or wait for each set of changes to be reviewed individually? Sorry, I'm still new to the processes.

It might be better to split the changes across two or three PRs, as appropriate.

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

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

From alanb at openjdk.java.net  Wed Feb 17 20:24:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Feb 2021 20:24:44 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <z4Thba6HiKZhHvh3Yjx71aVSl0uFcYHr7o8dSG-SXB4=.9531593e-64ef-464c-84db-913cca16e7c7@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
 <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>
 <GkjTi3pCpFJFekVtDDnJjSjAy3P7UkSwB4uSHT-DPqQ=.d92de7e3-6816-4ae4-9bc3-aa2c008241b2@github.com>
 <z4Thba6HiKZhHvh3Yjx71aVSl0uFcYHr7o8dSG-SXB4=.9531593e-64ef-464c-84db-913cca16e7c7@github.com>
Message-ID: <Icyw1dz2_2qjmpbD3kY9cfUI72LtBaxRy4w3ivVYWao=.a3f02e49-fb00-427f-b617-83cfc76d36a0@github.com>

On Wed, 17 Feb 2021 18:06:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> @bplb @AlanBateman Now that there is a webrev just for the deduplication, can I already amend further changes or wait for each set of changes to be reviewed individually? Sorry, I'm still new to the processes.
>
> It might be better to split the changes across two or three PRs, as appropriate.

Thanks for the update patch, this is much easier to read now. Overall I think this looks good with only a few minor discussion points that I'll add to the PR. I agree with @bplb that it's best to integrate this once we've finished the review. Another issue/PR can be used for the other refactoring/modernization that you want to do.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Feb 18 07:15:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Feb 2021 07:15:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
Message-ID: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>

On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

@FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

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

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

From jboes at openjdk.java.net  Thu Feb 18 10:38:41 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 18 Feb 2021 10:38:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <8pRy5JBdXXoJzu35O6aFHAUALWZ__OBbdganHZKu1FE=.f5fcf42b-eab5-49a6-9450-4942c933f39d@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746
>
> @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

To re-integrate, just run the /integrate command again. 

Before doing that, could someone from security libs acknowledge the changes in their area?

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

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

From chegar at openjdk.java.net  Thu Feb 18 11:54:40 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 18 Feb 2021 11:54:40 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <8erqBs2u14oRGdt-KmCGy9IGLZnv5k1tqwm57BSnjBQ=.4e8133b8-f287-43a0-94d3-da136336e56b@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

The changes in java/net look ok to me.

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

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

From mullan at openjdk.java.net  Thu Feb 18 19:24:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 18 Feb 2021 19:24:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
Message-ID: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>

On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   remove unnecessary file.exists() check

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:

> 226:         try {
> 227:             if (is.markSupported() == false) {
> 228:                 // Copy the entire input stream into an InputStream that does

I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.

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

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

From github.com+471021+marschall at openjdk.java.net  Thu Feb 18 20:01:44 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Thu, 18 Feb 2021 20:01:44 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <vnqgSD6xTUObnu2ModbBdi5Lv2a4w_dMC7lA88abJ8s=.3a325124-b181-4fc2-9e5b-c922f3dea2ba@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
 <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
 <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>
 <vnqgSD6xTUObnu2ModbBdi5Lv2a4w_dMC7lA88abJ8s=.3a325124-b181-4fc2-9e5b-c922f3dea2ba@github.com>
Message-ID: <SUQfRqK0ia27jJzctph4FTacj0DgnApZaalR6K0WEU0=.8bb6a2e0-8f50-4e05-8864-f0e675318019@github.com>

On Wed, 17 Feb 2021 17:22:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible.
>> 
>> The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done.
>
>> but you're probably right and it would be good to make the name more explicit when exporting it outside of the package internal use. How about `inflateBytesToChars`?
> 
> That should be okay.

> > > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
> > 
> > 
> > Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem very reasonable, which I was thinking of exploring next as a separate RFE.
> 
> Maybe I misunderstood. The intrinsified method you point out here pre-dates the work in JDK 9 to similarly intrinsify char[]->byte[] compaction in StringUTF16, see https://bugs.openjdk.java.net/browse/JDK-6896617
> 
> It might be worthwhile cleaning this up. Not having to route via SharedSecrets -> JavaLangAccess does speed things up during startup/interpretation, at the cost of some code duplication.

My understanding was ISO_8859_1$Encoder.implEncodeISOArray and StringUTF16.compress are ultimately hooked up to the same intrinsic. I find it inconsistent that ISO_8859_1$Encoder access an encoding intrinsitc directly while ISO_8859_1$Decoder and others access a decoding intrinsic indirectly through JavaLangAccess. I realize this RFE is about decoding so keeping encoding to a different RFE may indeed be better.

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

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

From github.com+471021+marschall at openjdk.java.net  Thu Feb 18 20:19:40 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Thu, 18 Feb 2021 20:19:40 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
 <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>
Message-ID: <TaWFELa3-vGaqDgFq2FsT-wko2X1kk1eE7OIbCmOr0E=.2181c428-834b-4495-8676-a937349800ee@github.com>

On Wed, 17 Feb 2021 15:37:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace c-style array declarations
>>  - Share work buffer between #skip and #read
>
> src/java.base/share/classes/java/io/Reader.java line 221:
> 
>> 219:                     // if the last call to read returned -1 or the number of bytes
>> 220:                     // requested have been read then break
>> 221:                 } while (n >= 0 && remaining > 0);
> 
> The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder.

Right. So you propose to revert the off-heap path to the current master? That would be fine with me. The original bug and my motivation was only about the backing array case, the rest crept in. That would certainly keep the risk and impact lower.

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

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

From bpb at openjdk.java.net  Thu Feb 18 20:38:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 18 Feb 2021 20:38:43 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
 <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>
Message-ID: <GKi4tkOIYe--ZT77birhG2W9jPJf3m23xwEmgNvN6Ug=.c20a1072-0ebe-4f27-84de-83d4f647bf5e@github.com>

On Wed, 17 Feb 2021 15:37:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace c-style array declarations
>>  - Share work buffer between #skip and #read
>
> src/java.base/share/classes/java/io/Reader.java line 221:
> 
>> 219:                     // if the last call to read returned -1 or the number of bytes
>> 220:                     // requested have been read then break
>> 221:                 } while (n >= 0 && remaining > 0);
> 
> The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder.

I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks.

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

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

From redestad at openjdk.java.net  Thu Feb 18 23:16:00 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Feb 2021 23:16:00 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v4]
In-Reply-To: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
Message-ID: <SgPWX9p35xyErLl59gPCQgUyZjjVLSW1yjrNvh1drIQ=.8ed0b3a9-d8da-43c5-9415-234075bb47ec@github.com>

> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
> 
> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
> 
> Testing: tier1-3

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

  Revert JavaLangAccessImpl changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2574/files
  - new: https://git.openjdk.java.net/jdk/pull/2574/files/367be2a5..e2316007

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

  Stats: 176 lines in 2 files changed: 6 ins; 10 del; 160 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2574/head:pull/2574

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

From redestad at openjdk.java.net  Thu Feb 18 23:19:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Feb 2021 23:19:39 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
 <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
 <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>
Message-ID: <iLtrM211Pb2wqwKdS0gZ5fNiVsgWGXIiadfd5VPnNT0=.677af047-aa72-45b8-91e2-8313281c8bd9@github.com>

On Wed, 17 Feb 2021 17:19:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Right, I'm not exactly sure why the more limited changes I attempted in [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e) failed. In that change I simply changed the initialization order, which made the failing (closed) tests pass locally - but not in our CI. Since this is in initPhase1 there should be no concurrency possible.
> 
> The Reference Handler thread is started by the initializer in jl.ref.Reference so could be a candidate. The Finalizer thread is another but this should VM.awaitInitLevel(1) and not touch JLA until initPhase1 is done.

Turns out the native code called by `SystemProps.initProperties();` can initialize a `CharsetDecoder` if `sun.jnu.encoding` is set to certain values, and this tripped up the initialization to cause `getJavaLangAccess` to be called before `setJavaLangAccess`. By moving `setJavaLangAccess` to the very start of `initPhase1` we avoid this possibility, and limit churn.

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

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

From bpb at openjdk.java.net  Fri Feb 19 00:40:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 19 Feb 2021 00:40:02 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
Message-ID: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>

This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.

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

Commit messages:
 - 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test

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

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

From mli at openjdk.java.net  Fri Feb 19 00:50:40 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Feb 2021 00:50:40 GMT
Subject: RFR: JDK-8260694: (fc) Clarify FileChannel.transferFrom to better
 describe "no bytes available" case [v5]
In-Reply-To: <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
 <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
 <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
Message-ID: <qX7cY-_47fwPPKif3R3mqQFCI4vSYpGyDV4XcKXzi8I=.ae548477-f508-4d92-904f-3632f55b99e7@github.com>

On Fri, 5 Feb 2021 00:49:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>> Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks
>> 
>> Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".
>> 
>>> BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.
>> 
>> Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.
>
>> > Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks
>> 
>> Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".
>> 
> Thanks Alan, just finalized it.
>> > BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.
>> 
>> Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.
> Got it.

> Hi @Hamlin-Li, to move this forward, could you re-finalize the CSR and change the title of this PR in line with the CSR and issue?

Hi Julia,
Thanks for reminding. I have just changed the pr title and re-finalized the CSR.
( Sorry for the delayed reply, I have been on a long vacation. )

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

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

From mli at openjdk.java.net  Fri Feb 19 06:21:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Feb 2021 06:21:38 GMT
Subject: RFR: JDK-8260694: (fc) Clarify FileChannel.transferFrom to better
 describe "no bytes available" case [v5]
In-Reply-To: <qX7cY-_47fwPPKif3R3mqQFCI4vSYpGyDV4XcKXzi8I=.ae548477-f508-4d92-904f-3632f55b99e7@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
 <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
 <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
 <qX7cY-_47fwPPKif3R3mqQFCI4vSYpGyDV4XcKXzi8I=.ae548477-f508-4d92-904f-3632f55b99e7@github.com>
Message-ID: <i3OYR1s5pIkCaINZQJcHjQ8iVWso5y58ufdTzCsz8BU=.6d96b0d0-29d5-481e-a2b6-545c1302356e@github.com>

On Fri, 19 Feb 2021 00:48:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>> > Hi Alan, CSR is created at https://bugs.openjdk.java.net/browse/JDK-8261135. Thanks
>>> 
>>> Thanks, I've tweaked it a bit and reduced the specification section down to the changes that we have agreed in the PR. You should be able to hit "Finalize".
>>> 
>> Thanks Alan, just finalized it.
>>> > BTW, seems linux x86 fails often, I think it's safe for me to ignore the failures, please kindly let me know otherwise.
>>> 
>>> Sorry, I can't help on this as I haven't built on 32-bit for several years. There are a few people in OpenJDK that are keeping the 32-bit builds working.
>> Got it.
>
>> Hi @Hamlin-Li, to move this forward, could you re-finalize the CSR and change the title of this PR in line with the CSR and issue?
> 
> Hi Julia,
> Thanks for reminding. I have just changed the pr title and re-finalized the CSR.
> ( Sorry for the delayed reply, I have been on a long vacation. )

Seems it's ready, am I good to integrate the change?

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

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

From alanb at openjdk.java.net  Fri Feb 19 07:37:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Feb 2021 07:37:38 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <GKi4tkOIYe--ZT77birhG2W9jPJf3m23xwEmgNvN6Ug=.c20a1072-0ebe-4f27-84de-83d4f647bf5e@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
 <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>
 <GKi4tkOIYe--ZT77birhG2W9jPJf3m23xwEmgNvN6Ug=.c20a1072-0ebe-4f27-84de-83d4f647bf5e@github.com>
Message-ID: <ccNpuYEQ4J-igWvxBK36eAWY7GWRCf0FcZyeYgYsvN8=.d8c1e57a-e145-4270-b948-cf676b5d61a7@github.com>

On Thu, 18 Feb 2021 20:35:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 221:
>> 
>>> 219:                     // if the last call to read returned -1 or the number of bytes
>>> 220:                     // requested have been read then break
>>> 221:                 } while (n >= 0 && remaining > 0);
>> 
>> The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder.
>
> I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks.

Yes, let's keep bring it back to just eliminating the intermediate array when the buffer has a backing array. The other case that been examined separated if needed but we can't use the approach proposed in the current PR because it changes the semantics of read when there is a short-read followed by a blocking or exception throwing read.

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

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

From alanb at openjdk.java.net  Fri Feb 19 07:49:51 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Feb 2021 07:49:51 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v2]
In-Reply-To: <iLtrM211Pb2wqwKdS0gZ5fNiVsgWGXIiadfd5VPnNT0=.677af047-aa72-45b8-91e2-8313281c8bd9@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <S5cLioa9iwh-AivQxKg_Vyb8kdE7joDADK1hp0hVh8I=.e7ac100f-0c3e-4d2c-8877-3c646128e0f0@github.com>
 <jnwRagzs30PreCvL99d3ys7CuoRLprH6GyBfUMLcz1w=.38f9251c-1168-48da-9cb4-d2c5fd1d28ba@github.com>
 <rumGsp87gERyc240pbDaQGxHHK0mG2_MZTZ-KRJ-zkE=.9744c998-558d-4b91-8b4a-48ad2dff747d@github.com>
 <iLtrM211Pb2wqwKdS0gZ5fNiVsgWGXIiadfd5VPnNT0=.677af047-aa72-45b8-91e2-8313281c8bd9@github.com>
Message-ID: <8oM8c_hWCz1dgpCmRg_8eATS1MwlcsleJ7pATWhDYIM=.0af21dc5-d548-4355-bf71-c2cb5ccc9fc3@github.com>

On Thu, 18 Feb 2021 23:16:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Turns out the native code called by `SystemProps.initProperties();` can initialize a `CharsetDecoder` if `sun.jnu.encoding` is set to certain values, and this tripped up the initialization to cause `getJavaLangAccess` to be called before `setJavaLangAccess`. By moving `setJavaLangAccess` to the very start of `initPhase1` we avoid this possibility, and limit churn.

I assume this is tests running with -Dfile.encoding. I can go along with moving setJavaLangAccess to the start of initPhase1. I'll do another pass over the updated patch today. Good work!

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 19 08:07:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 19 Feb 2021 08:07:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
Message-ID: <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>

On Thu, 18 Feb 2021 19:21:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   remove unnecessary file.exists() check
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:
> 
>> 226:         try {
>> 227:             if (is.markSupported() == false) {
>> 228:                 // Copy the entire input stream into an InputStream that does
> 
> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.

As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code:

    PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
        private static List<X509Certificate> parsePKCS7(InputStream is)
            certs = parsePKCS7(is);
                public X509CertPath(InputStream is, String encoding)
                    return new X509CertPath(new ByteArrayInputStream(data), encoding);

    PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
        private static List<X509Certificate> parsePKCS7(InputStream is)
            certs = parsePKCS7(is);
                public X509CertPath(InputStream is, String encoding)
                    this(is, PKIPATH_ENCODING);
                        public X509CertPath(InputStream is) throws CertificateException {
                            return new X509CertPath(new ByteArrayInputStream(encoding));

![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png)

Perhaps original marking approach was lost during refactoring?

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

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

From alanb at openjdk.java.net  Fri Feb 19 08:31:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Feb 2021 08:31:50 GMT
Subject: RFR: JDK-8260694: (fc) Clarify FileChannel.transferFrom to better
 describe "no bytes available" case [v5]
In-Reply-To: <i3OYR1s5pIkCaINZQJcHjQ8iVWso5y58ufdTzCsz8BU=.6d96b0d0-29d5-481e-a2b6-545c1302356e@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
 <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
 <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
 <qX7cY-_47fwPPKif3R3mqQFCI4vSYpGyDV4XcKXzi8I=.ae548477-f508-4d92-904f-3632f55b99e7@github.com>
 <i3OYR1s5pIkCaINZQJcHjQ8iVWso5y58ufdTzCsz8BU=.6d96b0d0-29d5-481e-a2b6-545c1302356e@github.com>
Message-ID: <NQRJZ4vRK9nGrNICeG8tMRStfA1dnLxQ77quir9EniQ=.e1be4ba2-60b8-496a-9f46-4ff6966d545e@github.com>

On Fri, 19 Feb 2021 06:18:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Seems it's ready, am I good to integrate the change?

Yes, good to go, enter "/integrate" or use pr integrate.

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Fri Feb 19 08:40:40 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Fri, 19 Feb 2021 08:40:40 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <Icyw1dz2_2qjmpbD3kY9cfUI72LtBaxRy4w3ivVYWao=.a3f02e49-fb00-427f-b617-83cfc76d36a0@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
 <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>
 <GkjTi3pCpFJFekVtDDnJjSjAy3P7UkSwB4uSHT-DPqQ=.d92de7e3-6816-4ae4-9bc3-aa2c008241b2@github.com>
 <z4Thba6HiKZhHvh3Yjx71aVSl0uFcYHr7o8dSG-SXB4=.9531593e-64ef-464c-84db-913cca16e7c7@github.com>
 <Icyw1dz2_2qjmpbD3kY9cfUI72LtBaxRy4w3ivVYWao=.a3f02e49-fb00-427f-b617-83cfc76d36a0@github.com>
Message-ID: <CnTD7CGgqjQgFqUcBDCeBLKjraR1-lCF632iFKKPQao=.721c072d-0c1b-4edf-8497-91ecab790160@github.com>

On Wed, 17 Feb 2021 20:21:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It might be better to split the changes across two or three PRs, as appropriate.
>
> Thanks for the update patch, this is much easier to read now. Overall I think this looks good with only a few minor discussion points that I'll add to the PR. I agree with @bplb that it's best to integrate this once we've finished the review. Another issue/PR can be used for the other refactoring/modernization that you want to do.

I originally intended to also add one further commit that avoids unnecessary I/O in `UnixFileStore.isExtendedAttributesEnabled()` if `UnixNativeDispatcher` doesn't support xattr at all. This is not strictly deduplication but rather an enhancement, so I'm fine with deferring it to another PR.

Also, I deduplicated code inside of `UnixUserDefinedAttributeView`. While this is in the spirit of this issue, it is a quite large diff.

Just let me know, if you think there is anything more to be done in _this_ PR.

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

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

From alanb at openjdk.java.net  Fri Feb 19 09:10:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Feb 2021 09:10:43 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
Message-ID: <r7RDnK8MnNR5taQ9igf5Jk5b_Jtr2Ctg6UQG6QQsDXo=.e4961fe7-75b3-489f-81ae-a3fca4a20715@github.com>

On Fri, 19 Feb 2021 00:34:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.

src/java.base/windows/native/libnio/MappedMemoryUtils.c line 79:

> 77:             break;
> 78:         retry++;
> 79:     } while (retry < 5);

This retry is a workaround for what we think is a bug in Windows. I remember there was speculation that it was something to do with the NTFS transaction log being full. It would be useful if get a comment from someone from Microsoft on this.

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

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

From mli at openjdk.java.net  Fri Feb 19 12:38:46 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Feb 2021 12:38:46 GMT
Subject: RFR: JDK-8260694: (fc) Clarify FileChannel.transferFrom to better
 describe "no bytes available" case [v5]
In-Reply-To: <NQRJZ4vRK9nGrNICeG8tMRStfA1dnLxQ77quir9EniQ=.e1be4ba2-60b8-496a-9f46-4ff6966d545e@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
 <RmnMeCBItoMnw2jT2Z8PDGsV3FVRB8HMovdaXYqxC70=.c2fd5eda-cc50-42cb-9f84-f37a6ec36ddd@github.com>
 <agXPEzmv73DM1v_v-sENn_tpMETAcKdKC5TRXMX9kbw=.dbf9bff0-3f13-4260-b396-0954957f904f@github.com>
 <WdTIXsDzpW_9tp4xSIT5ddxfpKHYgIunfwxkqGp0f50=.ea51e186-0b39-4e6d-96ff-e9444b829a11@github.com>
 <AvJ5L0oxdEyq_0t8t3Jj2S2GgZ18gSnQ-WXKmKLYA4M=.b43859e0-e2cc-40de-a834-8fc5939a1589@github.com>
 <qX7cY-_47fwPPKif3R3mqQFCI4vSYpGyDV4XcKXzi8I=.ae548477-f508-4d92-904f-3632f55b99e7@github.com>
 <i3OYR1s5pIkCaINZQJcHjQ8iVWso5y58ufdTzCsz8BU=.6d96b0d0-29d5-481e-a2b6-545c1302356e@github.com>
 <NQRJZ4vRK9nGrNICeG8tMRStfA1dnLxQ77quir9EniQ=.e1be4ba2-60b8-496a-9f46-4ff6966d545e@github.com>
Message-ID: <AJVcOPi51YGdni6P19AzRPQvBnzRtGqyBU75KfnWlrs=.3c2ceb54-0312-46fb-bf2a-4018d90f6a2d@github.com>

On Fri, 19 Feb 2021 08:28:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Seems it's ready, am I good to integrate the change?
> 
> Yes, good to go, enter "/integrate" or use pr integrate.

Thanks Alan.

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

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

From mli at openjdk.java.net  Fri Feb 19 12:38:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Feb 2021 12:38:47 GMT
Subject: Integrated: JDK-8260694: (fc) Clarify FileChannel.transferFrom to
 better describe "no bytes available" case
In-Reply-To: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
References: <0kIbPv-ndmlrPH3iUowTkOolaE0G7Out0Q4_bZRj2fw=.8bf1fc9d-18f3-408d-9a69-81660a8a9a5b@github.com>
Message-ID: <Yd8cJ0y5J3vOwTOhyzGl32NejniFQP6nYecrSjpNXuI=.6ad659d9-b64c-423e-a9d5-aaba927ab328@github.com>

On Mon, 1 Feb 2021 02:26:23 GMT, Hamlin Li <mli at openjdk.org> wrote:

> We'd better put more detailed messages in FileChannel.transferFrom/transferTo that it will not return -1, as we met several cases where developers of framework/program assume that it will return -1 on some error conditions, e.g. EOF of src Channel of transferFrom.
> 
> please check more details in JDK-8260486, and discussion in https://mail.openjdk.java.net/pipermail/nio-dev/2021-January/008094.html

This pull request has now been integrated.

Changeset: a180a386
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a180a386
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8260694: (fc) Clarify FileChannel.transferFrom to better describe "no bytes available" case

Reviewed-by: alanb

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

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

From alanb at openjdk.java.net  Fri Feb 19 14:19:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Feb 2021 14:19:41 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v4]
In-Reply-To: <SgPWX9p35xyErLl59gPCQgUyZjjVLSW1yjrNvh1drIQ=.8ed0b3a9-d8da-43c5-9415-234075bb47ec@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <SgPWX9p35xyErLl59gPCQgUyZjjVLSW1yjrNvh1drIQ=.8ed0b3a9-d8da-43c5-9415-234075bb47ec@github.com>
Message-ID: <BpJ3HSR8OUx6Ke5RUOMYdSmmlMqkmdz_Dyo2DzKTqpI=.64949d8c-c35e-4338-bacc-0af4ccdd2ad3@github.com>

On Thu, 18 Feb 2021 23:16:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
>> 
>> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
>> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
>> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert JavaLangAccessImpl changes

Marked as reviewed by alanb (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Feb 19 14:27:42 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Feb 2021 14:27:42 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v4]
In-Reply-To: <SgPWX9p35xyErLl59gPCQgUyZjjVLSW1yjrNvh1drIQ=.8ed0b3a9-d8da-43c5-9415-234075bb47ec@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <SgPWX9p35xyErLl59gPCQgUyZjjVLSW1yjrNvh1drIQ=.8ed0b3a9-d8da-43c5-9415-234075bb47ec@github.com>
Message-ID: <SgU6Ix3EOsVmNMElDoY5gbMB1iDtSDimKFNkG_mVlSY=.86fc05c3-f7e1-4799-b25c-27255872190b@github.com>

On Thu, 18 Feb 2021 23:16:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
>> 
>> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
>> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
>> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert JavaLangAccessImpl changes

Marked as reviewed by naoto (Reviewer).

src/java.base/share/classes/java/lang/System.java line 1988:

> 1986:         // might initialize CharsetDecoders that rely on it
> 1987:         setJavaLangAccess();
> 1988: 

Good to see the init issue has been resolved with a simple reordering.

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

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

From mullan at openjdk.java.net  Fri Feb 19 15:05:42 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 19 Feb 2021 15:05:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
 <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
Message-ID: <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>

On Fri, 19 Feb 2021 08:05:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:
>> 
>>> 226:         try {
>>> 227:             if (is.markSupported() == false) {
>>> 228:                 // Copy the entire input stream into an InputStream that does
>> 
>> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.
>
> As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code:
> 
>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>         private static List<X509Certificate> parsePKCS7(InputStream is)
>             certs = parsePKCS7(is);
>                 public X509CertPath(InputStream is, String encoding)
>                     return new X509CertPath(new ByteArrayInputStream(data), encoding);
> 
>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>         private static List<X509Certificate> parsePKCS7(InputStream is)
>             certs = parsePKCS7(is);
>                 public X509CertPath(InputStream is, String encoding)
>                     this(is, PKIPATH_ENCODING);
>                         public X509CertPath(InputStream is) throws CertificateException {
>                             return new X509CertPath(new ByteArrayInputStream(encoding));
> 
> ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png)
> 
> Perhaps original marking approach was lost during refactoring?

You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later.

[1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6

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

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

From redestad at openjdk.java.net  Fri Feb 19 15:08:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Feb 2021 15:08:43 GMT
Subject: Integrated: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths
In-Reply-To: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
Message-ID: <ugh_GlBCrSJyU-4-SuG_Pk13ftcPW_qFvkA2qogMqSk=.d2ffca86-0b87-42c9-8148-d5a325814d06@github.com>

On Mon, 15 Feb 2021 11:22:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch exposes a couple of intrinsics used by String to speed up ASCII checking and byte[] -> char[] inflation, which can be used by latin1 and ASCII-compatible CharsetDecoders to speed up decoding operations.
> 
> - Fast-path implemented for all standard charsets, with up to 10x performance improvements in microbenchmarks reading Strings from ByteArrayInputStream. 
> - Cleanup of StreamDecoder/-Encoder with some minor improvements when interpreting
> - Reworked creation of JavaLangAccess to be safely published for CharsetDecoders/-Encoders used for setting up System.out/in. As JLA and these encoders are created during System.initPhase1 the current sequence caused the initialization to became unstable and a few tests were consistently getting an NPE.
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: 433096a4
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/433096a4
Stats:     557 lines in 13 files changed: 296 ins; 106 del; 155 mod

8261744: Implement CharsetDecoder ASCII and latin-1 fast-paths

Reviewed-by: naoto, alanb

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

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

From redestad at openjdk.java.net  Fri Feb 19 15:08:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Feb 2021 15:08:41 GMT
Subject: RFR: 8261744: Implement CharsetDecoder ASCII and latin-1
 fast-paths [v4]
In-Reply-To: <SgU6Ix3EOsVmNMElDoY5gbMB1iDtSDimKFNkG_mVlSY=.86fc05c3-f7e1-4799-b25c-27255872190b@github.com>
References: <y6HOoehjnkAcnlpQ3m4DfxvAjcFixeeX3XrZ91jxPw4=.eee9154c-5d78-432f-90be-8970dd48cd89@github.com>
 <SgPWX9p35xyErLl59gPCQgUyZjjVLSW1yjrNvh1drIQ=.8ed0b3a9-d8da-43c5-9415-234075bb47ec@github.com>
 <SgU6Ix3EOsVmNMElDoY5gbMB1iDtSDimKFNkG_mVlSY=.86fc05c3-f7e1-4799-b25c-27255872190b@github.com>
Message-ID: <G6KpJPSNHwAOFAaCFe8IX_xFVuROBP-7SqWNV00Ql1Y=.2a645298-6851-4c54-b48b-731add97d19b@github.com>

On Fri, 19 Feb 2021 14:24:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert JavaLangAccessImpl changes
>
> Marked as reviewed by naoto (Reviewer).

Thanks for reviewing!

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

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

From bpb at openjdk.java.net  Fri Feb 19 16:40:42 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 19 Feb 2021 16:40:42 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <r7RDnK8MnNR5taQ9igf5Jk5b_Jtr2Ctg6UQG6QQsDXo=.e4961fe7-75b3-489f-81ae-a3fca4a20715@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <r7RDnK8MnNR5taQ9igf5Jk5b_Jtr2Ctg6UQG6QQsDXo=.e4961fe7-75b3-489f-81ae-a3fca4a20715@github.com>
Message-ID: <9-i7v08FhXJ02wG8_1zDvqoBoFhci5s0jcPq2d_R-5k=.e2d898c9-0997-4bf9-966a-acceae95b90d@github.com>

On Fri, 19 Feb 2021 09:07:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.
>
> src/java.base/windows/native/libnio/MappedMemoryUtils.c line 79:
> 
>> 77:             break;
>> 78:         retry++;
>> 79:     } while (retry < 5);
> 
> This retry is a workaround for what we think is a bug in Windows. I remember there was speculation that it was something to do with the NTFS transaction log being full. It would be useful if get a comment from someone from Microsoft on this.

A full transaction log was indeed a speculation logged in the issue's comments.

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

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

From alanb at openjdk.java.net  Sun Feb 21 16:54:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 21 Feb 2021 16:54:39 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
Message-ID: <zDE3I0r8kMLhPEIUIlI-s0RAgDPVBP7cw3UjQKIkOgc=.341084c5-85f8-4f53-a8d8-4d860ec873fd@github.com>

On Fri, 19 Feb 2021 00:34:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.

src/java.base/share/classes/java/nio/MappedByteBuffer.java line 293:

> 291:             try {
> 292:                 SCOPED_MEMORY_ACCESS.force(scope(), fd, address, isSync, index, length);
> 293:             } catch (Exception unspecifiedException) {

The force method should be changed to declare that it throws IOException and that will avoid the need to catch "unexpectedException" here.

Also I think we to need to decide if the force methods should be specified to throw UncheckedIOException rather than an "unspecified exception". The API changes will need to be coordinated with Project Panama and the MappedMemorySegments.force spec.

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

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

From bpb at openjdk.java.net  Wed Feb 24 00:30:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 00:30:05 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test [v2]
In-Reply-To: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
Message-ID: <9EGfAVgSFnGy1-qIUx2hV8VU7cG6-do8lkzcBSCbU_k=.895f849f-7d78-4720-87cd-29631feabb7c@github.com>

> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 6539707: Fix whitespace error
 - 6539707: Spec force() method of MappedByteBuffer and MappedMemorySegments to throw UncheckedIOException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2636/files
  - new: https://git.openjdk.java.net/jdk/pull/2636/files/6b048efa..7199392d

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

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

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

From bpb at openjdk.java.net  Wed Feb 24 01:14:44 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 01:14:44 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test [v2]
In-Reply-To: <zDE3I0r8kMLhPEIUIlI-s0RAgDPVBP7cw3UjQKIkOgc=.341084c5-85f8-4f53-a8d8-4d860ec873fd@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <zDE3I0r8kMLhPEIUIlI-s0RAgDPVBP7cw3UjQKIkOgc=.341084c5-85f8-4f53-a8d8-4d860ec873fd@github.com>
Message-ID: <g97zfPxxldN1clkO-C2ymqHzZbHdBaACoBIjh0yZWRY=.47651c47-5854-49c1-9c57-43029596d2d3@github.com>

On Sun, 21 Feb 2021 16:51:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 6539707: Fix whitespace error
>>  - 6539707: Spec force() method of MappedByteBuffer and MappedMemorySegments to throw UncheckedIOException
>
> src/java.base/share/classes/java/nio/MappedByteBuffer.java line 293:
> 
>> 291:             try {
>> 292:                 SCOPED_MEMORY_ACCESS.force(scope(), fd, address, isSync, index, length);
>> 293:             } catch (Exception unspecifiedException) {
> 
> The underlying force method should be changed to declare that it throws IOException and that will avoid the need to catch "unexpectedException" here.
> 
> Also I think we to need to decide if the force methods should be specified to throw UncheckedIOException rather than an "unspecified exception". The API changes will need to be coordinated with Project Panama and the MappedMemorySegments.force spec.

In commit [df506b9](https://github.com/openjdk/jdk/pull/2636/commits/df506b9b09d6545982ed946d13737d5829863932), `MappedMemoryUtils.force()` is modified to rethrow an `IOException` thrown by `MappedMemoryUtils.force0()` as an `UncheckedIOException` with the `IOException` as its cause. The specifications of `force()` in `MappedByteBuffer` and `MappedMemorySegments` are modified to specify that such an `UncheckedIOException` will be thrown if the underlying operation fails.

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

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

From alanb at openjdk.java.net  Wed Feb 24 08:30:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Feb 2021 08:30:42 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test [v2]
In-Reply-To: <9EGfAVgSFnGy1-qIUx2hV8VU7cG6-do8lkzcBSCbU_k=.895f849f-7d78-4720-87cd-29631feabb7c@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <9EGfAVgSFnGy1-qIUx2hV8VU7cG6-do8lkzcBSCbU_k=.895f849f-7d78-4720-87cd-29631feabb7c@github.com>
Message-ID: <r3-eHtfVsj9RHsWd9eT9CcKQu8d6iH5JeHjeEYsLDsw=.69bc5931-054b-4afa-b56c-558ce2930948@github.com>

On Wed, 24 Feb 2021 00:30:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6539707: Fix whitespace error
>  - 6539707: Spec force() method of MappedByteBuffer and MappedMemorySegments to throw UncheckedIOException

src/java.base/share/classes/java/nio/MappedByteBuffer.java line 230:

> 228:      * @return  This buffer
> 229:      */
> 230:     public final MappedByteBuffer force() {

The 2-arg force method will need to be updated too.
Given that the methods are specified to write the buffer content back to the underlying storage device then I think it should be okay to say "If an I/O occurs writing the ...".

src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 100:

> 98:             long offset = mappingOffset(address, index);
> 99:             try {
> 100:                 force0(fd, mappingAddress(address, offset, index),

Are you going to change force0 to declare that it throws IOException? I assumed you'd need to do that to get this code to compile.

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

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

From alanb at openjdk.java.net  Wed Feb 24 08:54:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Feb 2021 08:54:42 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <MBMi2I0sim_z4rs9I1ISl4XaYOe45pDb7u-TxJbQIQc=.0472c0a4-8776-4714-9628-3623ca3fdda2@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67:

> 65:     private final SinkChannel sink;
> 66: 
> 67:     private static class Initializer

This one is okay to do.

src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java line 51:

> 49:      * Represents a service provider in the services catalog.
> 50:      */
> 51:     public static final class ServiceProvider {

This one is okay to do.

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

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

From stuefe at openjdk.java.net  Wed Feb 24 15:48:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 24 Feb 2021 15:48:40 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
Message-ID: <zZstMRm8WBAhFq9ZpG9SanpLUfqTPOh-K-WfPT1yed4=.1fe55fd7-4153-4f52-8c1f-54b9d0e0811a@github.com>

On Fri, 19 Feb 2021 00:34:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.

Hi Brian,

just some curious questions. 

Does your test case always fail to force on Windows, or only intermittently? Since I have not seen these kind of errors in a long while.

About the 3->5: were you able to reproduce it, and had better results with 5 than 3? I found an old issue in mongo and they seem to have done workaround way more aggressively (retry 1mio times or 60 seconds, whatever is faster): 
https://github.com/mongodb/mongo/blob/c0ed1fde6a726909ae99b928a711e3c38837a4ae/src/mongo/util/mmap_win.cpp#L179

Thanks, Thomas

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

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

From alanb at openjdk.java.net  Wed Feb 24 16:02:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Feb 2021 16:02:41 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <zZstMRm8WBAhFq9ZpG9SanpLUfqTPOh-K-WfPT1yed4=.1fe55fd7-4153-4f52-8c1f-54b9d0e0811a@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <zZstMRm8WBAhFq9ZpG9SanpLUfqTPOh-K-WfPT1yed4=.1fe55fd7-4153-4f52-8c1f-54b9d0e0811a@github.com>
Message-ID: <UQ9cYAfw7-V03wp9E9AuqSJmzyt2un3_wRu7WKSl1FA=.c35a0fc0-006c-4053-a4a5-29f0803a0303@github.com>

On Wed, 24 Feb 2021 15:46:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.
>
> Hi Brian,
> 
> just some curious questions. 
> 
> Does your test case always fail to force on Windows, or only intermittently? Since I have not seen these kind of errors in a long while.
> 
> About the 3->5: were you able to reproduce it, and had better results with 5 than 3? I found an old issue in mongo and they seem to have done workaround way more aggressively (retry 1mio times or 60 seconds, whatever is faster): 
> https://github.com/mongodb/mongo/blob/c0ed1fde6a726909ae99b928a711e3c38837a4ae/src/mongo/util/mmap_win.cpp#L179
> 
> Thanks, Thomas

I put in the retry loop several years ago as a workaround to what we thought at the time was a Windows bug. It was very intermittent and seem to be load related. I suspect this issue really needs someone from the Windows team to comment.

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

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

From bpb at openjdk.java.net  Wed Feb 24 16:47:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 16:47:43 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test [v2]
In-Reply-To: <r3-eHtfVsj9RHsWd9eT9CcKQu8d6iH5JeHjeEYsLDsw=.69bc5931-054b-4afa-b56c-558ce2930948@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <9EGfAVgSFnGy1-qIUx2hV8VU7cG6-do8lkzcBSCbU_k=.895f849f-7d78-4720-87cd-29631feabb7c@github.com>
 <r3-eHtfVsj9RHsWd9eT9CcKQu8d6iH5JeHjeEYsLDsw=.69bc5931-054b-4afa-b56c-558ce2930948@github.com>
Message-ID: <0DhkmBzghNv0CoiLF7benn4pNSgtM9l8UEzNkseirfs=.fb889ce0-0b8f-44c2-88a2-11cc92809930@github.com>

On Wed, 24 Feb 2021 08:26:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 6539707: Fix whitespace error
>>  - 6539707: Spec force() method of MappedByteBuffer and MappedMemorySegments to throw UncheckedIOException
>
> src/java.base/share/classes/java/nio/MappedByteBuffer.java line 230:
> 
>> 228:      * @return  This buffer
>> 229:      */
>> 230:     public final MappedByteBuffer force() {
> 
> The 2-arg force method will need to be updated too.
> Given that the methods are specified to write the buffer content back to the underlying storage device then I think it should be okay to say "If an I/O occurs writing the ...".

Will change.

> src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 100:
> 
>> 98:             long offset = mappingOffset(address, index);
>> 99:             try {
>> 100:                 force0(fd, mappingAddress(address, offset, index),
> 
> Are you going to change force0 to declare that it throws IOException? I assumed you'd need to do that to get this code to compile.

It compiled without that change. In general I try to at least compile if not completely test before creating a PR. It should be changed however.

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

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

From bpb at openjdk.java.net  Wed Feb 24 16:51:40 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 16:51:40 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <UQ9cYAfw7-V03wp9E9AuqSJmzyt2un3_wRu7WKSl1FA=.c35a0fc0-006c-4053-a4a5-29f0803a0303@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <zZstMRm8WBAhFq9ZpG9SanpLUfqTPOh-K-WfPT1yed4=.1fe55fd7-4153-4f52-8c1f-54b9d0e0811a@github.com>
 <UQ9cYAfw7-V03wp9E9AuqSJmzyt2un3_wRu7WKSl1FA=.c35a0fc0-006c-4053-a4a5-29f0803a0303@github.com>
Message-ID: <eIc0VOJZ7wVGKsAYEOdXqMzgh6ZLLwiA33vBc5YhWP0=.0b0668cb-0703-4ffb-95b6-a559a4708fef@github.com>

On Wed, 24 Feb 2021 16:00:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Brian,
>> 
>> just some curious questions. 
>> 
>> Does your test case always fail to force on Windows, or only intermittently? Since I have not seen these kind of errors in a long while.
>> 
>> About the 3->5: were you able to reproduce it, and had better results with 5 than 3? I found an old issue in mongo and they seem to have done workaround way more aggressively (retry 1mio times or 60 seconds, whatever is faster): 
>> https://github.com/mongodb/mongo/blob/c0ed1fde6a726909ae99b928a711e3c38837a4ae/src/mongo/util/mmap_win.cpp#L179
>> 
>> Thanks, Thomas
>
> I put in the retry loop several years ago as a workaround to what we thought at the time was a Windows bug. It was very intermittent and seem to be load related. I suspect this issue really needs someone from the Windows team to comment.

The test was based on the one in the issue. I have not coerced it to fail. It is designed to fail on Windows only in case we can catch the flush failure. As far as I am concerned the retry iteration count increase could be removed from this issue altogether and the flush failure addressed in a different issue after there are comments from Microsoft. The present issue in fact ought to be renamed to something like "Mapped memory force methods should be specified to throw UncheckedIOExcreption".

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

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

From bpb at openjdk.java.net  Wed Feb 24 17:22:57 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 17:22:57 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test [v3]
In-Reply-To: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
Message-ID: <5j7kjawYpjMEzLyAu95LdpVbKP76fElJAMLsDZaDFEI=.4b772aea-f494-4bb3-8e14-57728cf929f2@github.com>

> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`.

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

  6539707: MMU.force0() -> throw IOException; MBB.force(int,int) -> specify throws UncheckedIOException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2636/files
  - new: https://git.openjdk.java.net/jdk/pull/2636/files/7199392d..e41ac28a

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

  Stats: 17 lines in 3 files changed: 10 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2636/head:pull/2636

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

From stuefe at openjdk.java.net  Wed Feb 24 17:32:41 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 24 Feb 2021 17:32:41 GMT
Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an
 IOException in a very simple test
In-Reply-To: <eIc0VOJZ7wVGKsAYEOdXqMzgh6ZLLwiA33vBc5YhWP0=.0b0668cb-0703-4ffb-95b6-a559a4708fef@github.com>
References: <TW62skjlaues42CSRGTtB92NyehMGTDqmOtsY1puiHU=.71381f57-5d64-45c3-a33b-52f709521fce@github.com>
 <zZstMRm8WBAhFq9ZpG9SanpLUfqTPOh-K-WfPT1yed4=.1fe55fd7-4153-4f52-8c1f-54b9d0e0811a@github.com>
 <UQ9cYAfw7-V03wp9E9AuqSJmzyt2un3_wRu7WKSl1FA=.c35a0fc0-006c-4053-a4a5-29f0803a0303@github.com>
 <eIc0VOJZ7wVGKsAYEOdXqMzgh6ZLLwiA33vBc5YhWP0=.0b0668cb-0703-4ffb-95b6-a559a4708fef@github.com>
Message-ID: <v_-GLN5Y5JzYSLa89sqByAIMT_GxdspNUBtVa8wlKk8=.a73e52b7-5c02-4d92-91f1-888620faee45@github.com>

On Wed, 24 Feb 2021 16:48:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I put in the retry loop several years ago as a workaround to what we thought at the time was a Windows bug. It was very intermittent and seem to be load related. I suspect this issue really needs someone from the Windows team to comment.
>
> The test was based on the one in the issue. I have not coerced it to fail. It is designed to fail on Windows only in case we can catch the flush failure. As far as I am concerned the retry iteration count increase could be removed from this issue altogether and the flush failure addressed in a different issue after there are comments from Microsoft. The present issue in fact ought to be renamed to something like "Mapped memory force methods should be specified to throw UncheckedIOExcreption".

Alan, Brian, thanks for the clarifications. 

Luckily, we have more participation from Microsoft than we had in the past, so the chance of getting feedback is higher.

Cheers, Thomas

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

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

From bpb at openjdk.java.net  Wed Feb 24 22:53:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 22:53:00 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v7]
In-Reply-To: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
Message-ID: <gUi8I-WjowssRERLNseb0hj1AmSoydxketj_6c6bh3M=.98cd7ff0-9f2f-4ea5-8965-016b82277758@github.com>

> 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.       ->

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

  8057113: Change Path.getExtension() to accept a default return value in case the extension is indeterminate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2319/files
  - new: https://git.openjdk.java.net/jdk/pull/2319/files/22c3ccec..0c864bd2

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

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

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

From bpb at openjdk.java.net  Wed Feb 24 22:53:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 24 Feb 2021 22:53:01 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v3]
In-Reply-To: <5fL5lxIxwbuUOHNNNy0HdLA7aGQrm2sFlI__8K40pR4=.58429046-4783-4b6e-a3ff-4c1f3b3eedb6@github.com>
References: <oMckDRkrX8lqRMCmDaMydUG8Vth7o-EmZWW8YsOZC8U=.67db01a3-4849-46bc-b257-b46a300f720a@github.com>
 <BKprSg_aGPa1-zjQ2FZIxXlcDLIn8-zCKsmh__0GzW4=.b7fe8919-95b4-4a8d-ad4c-3281347b12da@github.com>
 <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com>
 <rBp2Pky0zSQy1A97BNYkebti1t76mi--1FhgSZQPOng=.85e5a00d-dc78-4450-8839-6221c1260185@github.com>
 <CZmzVTBo1trr6iszJ1jXBV6bqdrHCV-yFh51G3v2xnE=.e1464303-c814-456a-be55-1aba109ea614@github.com>
 <A7aHrjGrqzGwB4iDL1lsfgvCKcaNOAVU_pYbi56CwII=.1ef8c891-0f29-4d50-b1f0-4b40d4f8e3b3@github.com>
 <5fL5lxIxwbuUOHNNNy0HdLA7aGQrm2sFlI__8K40pR4=.58429046-4783-4b6e-a3ff-4c1f3b3eedb6@github.com>
Message-ID: <_1vz3REF25jmuxPtmitx555D5BJ3JYDjQKX1C0YBKrY=.6c8b24b6-496b-4bcb-bab7-09f8266910a9@github.com>

On Wed, 3 Feb 2021 17:50:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Using an Optional forces a user to read the javadoc (or worst guess), so i'm not sure it's a good idea to use it here because most people will just want the extension not a long speech about the filename being potentially null.
>> 
>> For me using "" when the extension doesn't exist whatever the reason is more pragmatic.
>
> Choice 3, the equivalent of getOrDefault, is compact and exposes explicitly the case where no extension is present with very little overhead.

Most use cases appear to concern switching on the extension to select among several alternatives:

- Get the file format name.
- Get an image reader to read a given image file.
- Get an icon to represent a given file in a file view.
- Select an application which can open a file of a certain type.

For this a string-based `getExtension()` method would seem to be enough. It is unclear how a platform representation would add any value or even whether one could be self-consistent given that an extension is not really an element in the sense of a root component, directory, or file. Each of these represents an actual component in the file system whereas an extension could be considered a sort of attribute.

Another related operation would be to remove the extension. A couple of uses of this are:

- Input file `archive.zip` unzips to `archive/`.
- Input file `archive.tar.gz` gunzips to `archive.tar`.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Feb 25 11:07:47 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 25 Feb 2021 11:07:47 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <MBMi2I0sim_z4rs9I1ISl4XaYOe45pDb7u-TxJbQIQc=.0472c0a4-8776-4714-9628-3623ca3fdda2@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
 <MBMi2I0sim_z4rs9I1ISl4XaYOe45pDb7u-TxJbQIQc=.0472c0a4-8776-4714-9628-3623ca3fdda2@github.com>
Message-ID: <XkiSvaFi48AB2_MTKcVv6NVUy4wPhkGkTO7GLREdIM8=.9b0da781-b629-4efb-ad96-2ceb3f5ac451@github.com>

On Wed, 24 Feb 2021 08:50:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 67:
> 
>> 65:     private final SinkChannel sink;
>> 66: 
>> 67:     private static class Initializer
> 
> This one is okay to do.

Thanks for review! Could you review the rest of the code and approve this PR, if it's fine?

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

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

From alanb at openjdk.java.net  Fri Feb 26 07:00:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 26 Feb 2021 07:00:47 GMT
Subject: RFR: JDK-8262430: doclint warnings in java.base module
In-Reply-To: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
References: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
Message-ID: <nrb5ct1l59VOo0LJf_qKzwSqC66j0_khJc_Q1S5kmRc=.e3900a4a-6892-4a6c-84a4-0e189ee76354@github.com>

On Thu, 25 Feb 2021 22:59:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple doc fixes in the `java.base` module.  Two were reported by doclint; the spelling error was detected by the IDE.

I think the broken link issue is very recent as it only had to reference InetSocketAddress when preping/adding support for Unix domain sockets.

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

Marked as reviewed by alanb (Reviewer).

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

From chegar at openjdk.java.net  Fri Feb 26 08:47:41 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 26 Feb 2021 08:47:41 GMT
Subject: RFR: JDK-8262430: doclint warnings in java.base module
In-Reply-To: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
References: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
Message-ID: <kfrdaGEIFSbTvUeNQTlE_sjLL16gfo-IiqgczL0gJs8=.7a2ed252-5073-42db-99b1-20af9a28c776@github.com>

On Thu, 25 Feb 2021 22:59:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple doc fixes in the `java.base` module.  Two were reported by doclint; the spelling error was detected by the IDE.

Marked as reviewed by chegar (Reviewer).

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

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

From dfuchs at openjdk.java.net  Fri Feb 26 10:05:39 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 26 Feb 2021 10:05:39 GMT
Subject: RFR: JDK-8262430: doclint warnings in java.base module
In-Reply-To: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
References: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
Message-ID: <h_Y2eylSb7-pwu9QeDaYnv4XDvtI-ZavZdehtyWg7Pg=.111fc57e-3a1e-42dc-8a87-0949c2b0b0ba@github.com>

On Thu, 25 Feb 2021 22:59:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple doc fixes in the `java.base` module.  Two were reported by doclint; the spelling error was detected by the IDE.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From lancea at openjdk.java.net  Fri Feb 26 12:25:49 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 26 Feb 2021 12:25:49 GMT
Subject: RFR: JDK-8262430: doclint warnings in java.base module
In-Reply-To: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
References: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
Message-ID: <P0FtF-IG4ghmk7KpqVAgNy6isnn-81wPSzCe7912r9g=.8c3756b6-4fef-462a-9d16-f7efb21468ac@github.com>

On Thu, 25 Feb 2021 22:59:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple doc fixes in the `java.base` module.  Two were reported by doclint; the spelling error was detected by the IDE.

Marked as reviewed by lancea (Reviewer).

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

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

From jjg at openjdk.java.net  Fri Feb 26 15:15:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 26 Feb 2021 15:15:41 GMT
Subject: Integrated: JDK-8262430: doclint warnings in java.base module
In-Reply-To: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
References: <ARF6X2hcgH6ktqnrD5h4dPn6iMdKHPmwObpNNRV3G7I=.3cb6ba27-d1e1-44ca-beef-48ecb5a71dca@github.com>
Message-ID: <l89O6pn9V2nsQuz9QbyD8SzutkYmxjM3Lmcy7eWuPNk=.5bc995f8-0def-435d-9c80-1cce7349638a@github.com>

On Thu, 25 Feb 2021 22:59:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some simple doc fixes in the `java.base` module.  Two were reported by doclint; the spelling error was detected by the IDE.

This pull request has now been integrated.

Changeset: 3088e1e6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3088e1e6
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8262430: doclint warnings in java.base module

Reviewed-by: alanb, chegar, dfuchs, lancea

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Sat Feb 27 06:14:40 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Sat, 27 Feb 2021 06:14:40 GMT
Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations
 of UserDefinedFileAttributeView
In-Reply-To: <CnTD7CGgqjQgFqUcBDCeBLKjraR1-lCF632iFKKPQao=.721c072d-0c1b-4edf-8497-91ecab790160@github.com>
References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com>
 <O3Mkp6QfuxvJMczk5lR30I07T2xUXZJLd7_Lchp2S0o=.6311473d-d12c-4ebb-bbc9-952e32a0923d@github.com>
 <t8XaSbizszs_0CAURq-U19YfTZTDksTV0UCrvObIuvQ=.1168113c-cfbb-4af7-9d82-7b73b0b4c61b@github.com>
 <GkjTi3pCpFJFekVtDDnJjSjAy3P7UkSwB4uSHT-DPqQ=.d92de7e3-6816-4ae4-9bc3-aa2c008241b2@github.com>
 <z4Thba6HiKZhHvh3Yjx71aVSl0uFcYHr7o8dSG-SXB4=.9531593e-64ef-464c-84db-913cca16e7c7@github.com>
 <Icyw1dz2_2qjmpbD3kY9cfUI72LtBaxRy4w3ivVYWao=.a3f02e49-fb00-427f-b617-83cfc76d36a0@github.com>
 <CnTD7CGgqjQgFqUcBDCeBLKjraR1-lCF632iFKKPQao=.721c072d-0c1b-4edf-8497-91ecab790160@github.com>
Message-ID: <jvgIVvNsHZlndmYUCQcAS-ykGK368nA-qfJjPC5qPag=.c1d8ffac-d7df-408e-a7be-5aba02f2d257@github.com>

On Fri, 19 Feb 2021 08:37:17 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> Thanks for the update patch, this is much easier to read now. Overall I think this looks good with only a few minor discussion points that I'll add to the PR. I agree with @bplb that it's best to integrate this once we've finished the review. Another issue/PR can be used for the other refactoring/modernization that you want to do.
>
> I originally intended to also add one further commit that avoids unnecessary I/O in `UnixFileStore.isExtendedAttributesEnabled()` if `UnixNativeDispatcher` doesn't support xattr at all. This is not strictly deduplication but rather an enhancement, so I'm fine with deferring it to another PR.
> 
> Also, I deduplicated code inside of `UnixUserDefinedAttributeView`. While this is in the spirit of this issue, it is a quite large diff.
> 
> Just let me know, if you think there is anything more to be done in _this_ PR.

Anything I need to do to request a review?

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

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