From duke at openjdk.org  Tue Apr  1 11:19:19 2025
From: duke at openjdk.org (Stewart X Addison)
Date: Tue, 1 Apr 2025 11:19:19 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX
In-Reply-To: <4vwDv7WgmBMDFJoPfd-6x1tLac9Am8AwdD3eaoVKmBU=.067af3d9-f4ba-4352-825f-09f7816c3184@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <4vwDv7WgmBMDFJoPfd-6x1tLac9Am8AwdD3eaoVKmBU=.067af3d9-f4ba-4352-825f-09f7816c3184@github.com>
Message-ID: <c6_4iw1hsBc0ogtzn_BK7KLmVeHmDS3WxrFf5bM-Pa8=.d600f9f3-f5ff-4257-9b21-daf01ea83c57@github.com>

On Thu, 27 Mar 2025 12:57:30 GMT, Varada M <varadam at openjdk.org> wrote:

> @sxa could you please review it? Is there any additional changes required

I don't believe I can give a formal review, but I've tested your fix and it seems to resolve the issues I was seeing :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2769021292

From jkern at openjdk.org  Wed Apr  2 14:50:10 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 2 Apr 2025 14:50:10 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
Message-ID: <jQGGrdbKCEbvYiP3gLjmi-XBui4E8vA1lRdJDtEudPg=.03a28bd3-c022-4a42-8b12-f5f180f38e6e@github.com>

On Thu, 27 Mar 2025 13:19:07 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into basic.java
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView for AIX

I tried to test your changes by running

jdk/java/nio/file/attribute/
UserDefinedFileAttributeView/Basic.java

but I still get  `UserDefinedFileAttributeView not supported - skip test`

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2772804080

From bpb at openjdk.org  Thu Apr  3 01:13:26 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Apr 2025 01:13:26 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
Message-ID: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>

Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

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

Commit messages:
 - 8321591: (fs) Path.of(URI) performance (win)

Changes: https://git.openjdk.org/jdk/pull/24400/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24400&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321591
  Stats: 146 lines in 2 files changed: 91 ins; 33 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24400.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24400/head:pull/24400

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

From bpb at openjdk.org  Thu Apr  3 01:16:46 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Apr 2025 01:16:46 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
Message-ID: <bngJZek-WcRgp34l8pofMDbA8cJ9xbU6xIPm9YkGfcs=.74eeced4-833c-41f6-b26d-54c986d97ca2@github.com>

On Thu, 3 Apr 2025 01:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

Performance changes as measured by the included benchmark are shown in the following table. The input path strings in even numbered rows include redundant backslashes (`\`).

| Path String | Baseline (ops/s) | Proposal (ops/s) | Change (%) |
| ----------- | ---------------- | ---------------- | ---------- |
| C:\Users\foo\bar\gus.txt | 6199154.628 | 6734399.308 | 8.34 |
| C:\Users\\\\foo\\\\bar\gus.txt | 5152600.992 | 6991821.398 | 35.69 |
| \\\.\UNC\localhost\C$\Users\foo | 4315495.741 | 4950377.343 | 14.71 |
| \\\.\UNC\localhost\C$\\\\Users\\\\foo | 4412610.277 | 5136928.053 | 15.41 |
| \\\?\C:\Users\foo\bar\gus.txt | 5401771.850 | 6332844.341 | 17.24 |
| \\\?\C:\Users\\\\foo\bar\\\\gus.txt | 5643219.553 | 6699547.423 |18.72 |
| .\foo\bar\gus.txt | 7354450.120 | 8967738.201 | 21.94 |
| .\foo\\\\bar\\\\gus.txt | 7179405.341 | 8816331.038 | 22.80 |
| \foo\bar\gus.txt | 8137737.571 | 9738842.924 | 19.68 |
| \foo\\\\bar\\\\gus.txt | 7966882.354 | 9444461.000 | 18.55 |
| C:foo\bar\gus.txt | 7917777.448 | 8489733.707 | 7.22 |
| C:foo\\\\bar\\\\gus.txt | 6986341.760 | 8583323.842 | 22.86 |

This proposed change affects `WindowsUriSupport.fromUri` as this method invokes `WindowsPathParser.parse` which in turn invokes `WindowsPathParser.normalize`. The opportunities for performance improvement in the code of `parse` proper appear to be limited due to the complexity of the Windows path design. Other URI-specific opportunities might exist in `fromUri` itself, for example, parsing only if the path component of the URI does not meet certain conditions, e.g., if it contains a slash `/`, redundant backslahes (`\`), or an invalid character (`:`, `|`, etc.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2774087281

From varadam at openjdk.org  Thu Apr  3 07:27:55 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 3 Apr 2025 07:27:55 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
Message-ID: <XAgiGNti3_mh--r7rDqfdl_bsoiwL6f3WB2aI2F9_kc=.66c15e49-7e2a-4ae6-8446-2a80df6d15f3@github.com>

On Thu, 27 Mar 2025 13:19:07 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into basic.java
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView for AIX

The initial behavior:
`The test test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java` passes with the output UserDefinedFileAttributeView not supported - skip test. This happens because AIX does not have the necessary code changes to support UserDefinedFileAttributeView, and by default, extended attributes (EA) are disabled, returning false for AIX.

With the addition of UserDefinedFileAttributeView support:

If EA is enabled on the system, the test runs successfully without being skipped.
If EA is disabled, the test behaves as before, skipping with the same output.
To ensure the test runs correctly, EA needs to be set to version 2 on AIX for the /tmp directory where the test file is created.

Could you check whether EA is enabled on your system?

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2774726050

From dfuchs at openjdk.org  Thu Apr  3 08:43:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 3 Apr 2025 08:43:07 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
Message-ID: <lqBfM2w6bzG-jJzVoACBzZST_YPhoDkzw6IzyVFoz3o=.f5399da9-9a9b-411b-8c42-dc5c25739d1c@github.com>

On Thu, 3 Apr 2025 01:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

I skimmed through the changes and they look reasonable. I assume there are tests that already cover path normalization on windows?

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2774907498

From duke at openjdk.org  Thu Apr  3 09:23:07 2025
From: duke at openjdk.org (Stewart X Addison)
Date: Thu, 3 Apr 2025 09:23:07 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <jQGGrdbKCEbvYiP3gLjmi-XBui4E8vA1lRdJDtEudPg=.03a28bd3-c022-4a42-8b12-f5f180f38e6e@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
 <jQGGrdbKCEbvYiP3gLjmi-XBui4E8vA1lRdJDtEudPg=.03a28bd3-c022-4a42-8b12-f5f180f38e6e@github.com>
Message-ID: <XTUAUQ3si_7VYZAYIfDiZWzMUwoxFr14B0RGFL42uss=.0d22187d-452e-4381-8838-63159c0e2a7a@github.com>

On Wed, 2 Apr 2025 14:47:19 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> I tried to test your changes by running
> 
> ```
> jdk/java/nio/file/attribute/
> UserDefinedFileAttributeView/Basic.java
> ```
> 
> but I still get `UserDefinedFileAttributeView not supported - skip test`

Running `chfs ea=v2` on the appropriate file system (probably `/tmp`) is needed as well as this fix. `lsfs -q` will show the current status - if it shows `EAformat: v2` then it's in a compatible state.

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2775028772

From jkern at openjdk.org  Thu Apr  3 10:26:50 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 3 Apr 2025 10:26:50 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <XTUAUQ3si_7VYZAYIfDiZWzMUwoxFr14B0RGFL42uss=.0d22187d-452e-4381-8838-63159c0e2a7a@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
 <jQGGrdbKCEbvYiP3gLjmi-XBui4E8vA1lRdJDtEudPg=.03a28bd3-c022-4a42-8b12-f5f180f38e6e@github.com>
 <XTUAUQ3si_7VYZAYIfDiZWzMUwoxFr14B0RGFL42uss=.0d22187d-452e-4381-8838-63159c0e2a7a@github.com>
Message-ID: <9k_YUfOIEEZTQ1b0Rr25TZwB4HmCbeuhshiJwYS2ANI=.9b88f031-cce9-419d-a798-0ec42e72f43b@github.com>

On Thu, 3 Apr 2025 09:20:40 GMT, Stewart X Addison <duke at openjdk.org> wrote:

> > I tried to test your changes by running
> > ```
> > jdk/java/nio/file/attribute/
> > UserDefinedFileAttributeView/Basic.java
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > but I still get `UserDefinedFileAttributeView not supported - skip test`
> 
> Running `chfs ea=v2` on the appropriate file system (probably `/tmp`) is needed as well as this fix. `lsfs -q` will show the current status - if it shows `EAformat: v2` then it's in a compatible state.

I already did it with our administrator this morning and it looks much better now. I will further investigate and approve if I do not find anything else.

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2775254895

From alanb at openjdk.org  Thu Apr  3 12:35:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Apr 2025 12:35:03 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
Message-ID: <u767jkbN87mJVp5S64YCO8sQUXRSeWM5w2Qj2pn3lY8=.b92caafd-4889-4c61-b31c-6ab130b46652@github.com>

On Thu, 3 Apr 2025 01:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

I did a quick pass over this and eliminating the intermediate SB looks okay. I note that the JBS description says "Path.of(URI)" but the benchmark is Path.of(String).

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2775641464

From jkern at openjdk.org  Thu Apr  3 12:45:57 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 3 Apr 2025 12:45:57 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
Message-ID: <PMZ2OfonNsUlDapHL9oYW8sQjelcmSRXfOLADm7eHds=.900ec229-33fc-43eb-b3ae-225a3e0090ca@github.com>

On Thu, 27 Mar 2025 13:19:07 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into basic.java
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView for AIX

I tested the UserDefinedAttributesView on AIX. For me symlinks seem to be not supported, bat that is OK as mentioned.

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24276#pullrequestreview-2739710329

From alanb at openjdk.org  Thu Apr  3 12:57:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Apr 2025 12:57:54 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
Message-ID: <z4rLR9cyQUk6AM7mVZ1WbrXZYSHwH1ewgY2jB8LHIn8=.e70750d5-9835-458d-b8e3-e6d9630b944d@github.com>

On Thu, 27 Mar 2025 13:19:07 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into basic.java
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView for AIX

The changes to the non-AIX specific files look okay, I assume the copyright headers will be updated before the changes are integrated

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2775700220

From bpb at openjdk.org  Thu Apr  3 17:53:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Apr 2025 17:53:57 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <lqBfM2w6bzG-jJzVoACBzZST_YPhoDkzw6IzyVFoz3o=.f5399da9-9a9b-411b-8c42-dc5c25739d1c@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
 <lqBfM2w6bzG-jJzVoACBzZST_YPhoDkzw6IzyVFoz3o=.f5399da9-9a9b-411b-8c42-dc5c25739d1c@github.com>
Message-ID: <QW3kCTEOTH82iU1JpKnwKwEZBson75Xkj3oOYesAjYc=.f115f8b6-5e5d-449f-b9cc-b4886a69de32@github.com>

On Thu, 3 Apr 2025 08:40:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I assume there are tests that already cover path normalization on windows?

`Path.of` normalizes by default. There are a lot of cases tested here:

https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/Path/PathOps.java

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2776529955

From bpb at openjdk.org  Thu Apr  3 17:57:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Apr 2025 17:57:02 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <u767jkbN87mJVp5S64YCO8sQUXRSeWM5w2Qj2pn3lY8=.b92caafd-4889-4c61-b31c-6ab130b46652@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
 <u767jkbN87mJVp5S64YCO8sQUXRSeWM5w2Qj2pn3lY8=.b92caafd-4889-4c61-b31c-6ab130b46652@github.com>
Message-ID: <Um2ciM3FZ99_m0wmC0vrm_q8rdgTMRYFZpC9NK_nChk=.1f19fb67-5c8c-4d0d-8ff4-48ead8d35545@github.com>

On Thu, 3 Apr 2025 12:32:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I note that the JBS description says "Path.of(URI)" but the benchmark is Path.of(String).

Correct, hence my comments after the table above about other opportunities in `WindowsUriSupport.fromUri`. If there are none, then perhaps the issue and PR summaries should be changed accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2776535879

From varadam at openjdk.org  Thu Apr  3 18:22:43 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 3 Apr 2025 18:22:43 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@github.com>
Message-ID: <VGuU9woaaYFKSwYUA3e0t9X_U_IGqFOuoa3Tb2jKJmc=.017a21f7-d69c-4ef4-88ac-47180a9d9fc3@github.com>

On Thu, 27 Mar 2025 13:19:07 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into basic.java
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView not supported on AIX
>  - UserDefinedFileAttributeView for AIX

Thanks for the reviews. I have updated the copyright headers

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2776588899

From varadam at openjdk.org  Thu Apr  3 18:22:40 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 3 Apr 2025 18:22:40 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v3]
In-Reply-To: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
Message-ID: <cb-wNAXnTX_72YoeLC_0PyEN9MY_XVmDp5zbUGpTWCk=.da5293c1-c325-43af-a81c-37cc626637e8@github.com>

> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
> 
> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)

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

  8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24276/files
  - new: https://git.openjdk.org/jdk/pull/24276/files/6866e532..5defce85

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

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

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

From bpb at openjdk.org  Thu Apr  3 20:50:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Apr 2025 20:50:49 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <QW3kCTEOTH82iU1JpKnwKwEZBson75Xkj3oOYesAjYc=.f115f8b6-5e5d-449f-b9cc-b4886a69de32@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
 <lqBfM2w6bzG-jJzVoACBzZST_YPhoDkzw6IzyVFoz3o=.f5399da9-9a9b-411b-8c42-dc5c25739d1c@github.com>
 <QW3kCTEOTH82iU1JpKnwKwEZBson75Xkj3oOYesAjYc=.f115f8b6-5e5d-449f-b9cc-b4886a69de32@github.com>
Message-ID: <uCmyiMKx7UpXGJrES7JAI_HzvNcf3JSWvcYXrBtfpjs=.999b1309-d1a6-44de-b24e-9594a95bfc3b@github.com>

On Thu, 3 Apr 2025 17:51:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I assume there are tests that already cover path normalization on windows?

Also, this changes passes JDK tiers 1-3 CI tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2776886871

From rriggs at openjdk.org  Thu Apr  3 22:12:49 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 3 Apr 2025 22:12:49 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
Message-ID: <ZcC9b8lmWYbsu9m7yToB_2j7f098rxpcZ-6irDCB2pM=.961cdf9b-ca6c-4170-bc1e-f7e92ac0ee29@github.com>

On Thu, 3 Apr 2025 01:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

I would encourage going further with the refactoring folding two classes into one.
WindowsPathParser is all static methods but with a better name could be a record that is the parsed WindowsPath.
The parsing methods could be either static or overloaded constructors with the input string and normalization flag, invoking the canonical constructor. YMMV.

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2777105101

From mdoerr at openjdk.org  Fri Apr  4 09:02:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Apr 2025 09:02:50 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v3]
In-Reply-To: <cb-wNAXnTX_72YoeLC_0PyEN9MY_XVmDp5zbUGpTWCk=.da5293c1-c325-43af-a81c-37cc626637e8@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <cb-wNAXnTX_72YoeLC_0PyEN9MY_XVmDp5zbUGpTWCk=.da5293c1-c325-43af-a81c-37cc626637e8@github.com>
Message-ID: <UVqWKDXHeoEPQCtvsjmJGSl_eZNmWZMF0Agw39a3Wgw=.5a2c9607-e261-4aac-8dc3-af8ac40b2578@github.com>

On Thu, 3 Apr 2025 18:22:40 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

src/java.base/aix/classes/sun/nio/fs/AixFileStore.java line 119:

> 117:        return super.supportsFileAttributeView(name);
> 118:    }
> 119: 

The indentation seems to be off by one space.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24276#discussion_r2028402348

From duke at openjdk.org  Fri Apr  4 09:21:10 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 4 Apr 2025 09:21:10 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <bwYuUQer9GVoAAzOG_FL2mCeUaIHD-QK2mZIqmW7FKY=.df55d6a1-0318-4c4e-a6ab-7426702292b2@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

All requested changes are included in this PR since last week. Kindly asking to re-review / mark as reviewed, so we can proceed with the needed CSR. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2778044566

From varadam at openjdk.org  Fri Apr  4 09:25:21 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 09:25:21 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v3]
In-Reply-To: <UVqWKDXHeoEPQCtvsjmJGSl_eZNmWZMF0Agw39a3Wgw=.5a2c9607-e261-4aac-8dc3-af8ac40b2578@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <cb-wNAXnTX_72YoeLC_0PyEN9MY_XVmDp5zbUGpTWCk=.da5293c1-c325-43af-a81c-37cc626637e8@github.com>
 <UVqWKDXHeoEPQCtvsjmJGSl_eZNmWZMF0Agw39a3Wgw=.5a2c9607-e261-4aac-8dc3-af8ac40b2578@github.com>
Message-ID: <hz7AVbr2gNy9IUFjf5-yupyDf_jfIXfx37xWmQw41d8=.3abde7ba-ba8f-4744-b5fb-75f063ee79e4@github.com>

On Fri, 4 Apr 2025 09:00:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8353053: (fs) Add support for UserDefinedFileAttributeView on AIX
>
> src/java.base/aix/classes/sun/nio/fs/AixFileStore.java line 119:
> 
>> 117:        return super.supportsFileAttributeView(name);
>> 118:    }
>> 119: 
> 
> The indentation seems to be off by one space.

fixed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24276#discussion_r2028440348

From varadam at openjdk.org  Fri Apr  4 09:25:20 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 09:25:20 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v4]
In-Reply-To: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
Message-ID: <Pv2uDgMpuS-hFDf7A1RGxirmRCG9eKb_PFCusAE74PQ=.7c4b7f65-77a1-4dbf-b3ca-8ee383834e38@github.com>

> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
> 
> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)

Varada M has updated the pull request incrementally with two additional commits since the last revision:

 - 8353053: (fs) Add support for UserDefinedFileAttributeView on AIX
 - 8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24276/files
  - new: https://git.openjdk.org/jdk/pull/24276/files/5defce85..d6ef10ea

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

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

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

From mdoerr at openjdk.org  Fri Apr  4 09:57:05 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Apr 2025 09:57:05 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v3]
In-Reply-To: <hz7AVbr2gNy9IUFjf5-yupyDf_jfIXfx37xWmQw41d8=.3abde7ba-ba8f-4744-b5fb-75f063ee79e4@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <cb-wNAXnTX_72YoeLC_0PyEN9MY_XVmDp5zbUGpTWCk=.da5293c1-c325-43af-a81c-37cc626637e8@github.com>
 <UVqWKDXHeoEPQCtvsjmJGSl_eZNmWZMF0Agw39a3Wgw=.5a2c9607-e261-4aac-8dc3-af8ac40b2578@github.com>
 <hz7AVbr2gNy9IUFjf5-yupyDf_jfIXfx37xWmQw41d8=.3abde7ba-ba8f-4744-b5fb-75f063ee79e4@github.com>
Message-ID: <taCJYRDc_30i6ns9BNdlQlBCRq5KZ_gplpPCvnUe3DQ=.0e5ccaeb-06c5-4b15-9e6a-7e15e821cc86@github.com>

On Fri, 4 Apr 2025 09:22:29 GMT, Varada M <varadam at openjdk.org> wrote:

>> src/java.base/aix/classes/sun/nio/fs/AixFileStore.java line 119:
>> 
>>> 117:        return super.supportsFileAttributeView(name);
>>> 118:    }
>>> 119: 
>> 
>> The indentation seems to be off by one space.
>
> fixed!

This file uses 4 spaces. Please take another look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24276#discussion_r2028490623

From varadam at openjdk.org  Fri Apr  4 10:25:31 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 10:25:31 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v5]
In-Reply-To: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
Message-ID: <48Q0GwgOyeCT0NBwq6gmM0z7EeANYythkfkohLBHbCU=.acfc8160-231c-4a4a-b411-fbdd46d919f2@github.com>

> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
> 
> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)

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

  8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24276/files
  - new: https://git.openjdk.org/jdk/pull/24276/files/d6ef10ea..dc2be404

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

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

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

From varadam at openjdk.org  Fri Apr  4 10:25:31 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 10:25:31 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v3]
In-Reply-To: <taCJYRDc_30i6ns9BNdlQlBCRq5KZ_gplpPCvnUe3DQ=.0e5ccaeb-06c5-4b15-9e6a-7e15e821cc86@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <cb-wNAXnTX_72YoeLC_0PyEN9MY_XVmDp5zbUGpTWCk=.da5293c1-c325-43af-a81c-37cc626637e8@github.com>
 <UVqWKDXHeoEPQCtvsjmJGSl_eZNmWZMF0Agw39a3Wgw=.5a2c9607-e261-4aac-8dc3-af8ac40b2578@github.com>
 <hz7AVbr2gNy9IUFjf5-yupyDf_jfIXfx37xWmQw41d8=.3abde7ba-ba8f-4744-b5fb-75f063ee79e4@github.com>
 <taCJYRDc_30i6ns9BNdlQlBCRq5KZ_gplpPCvnUe3DQ=.0e5ccaeb-06c5-4b15-9e6a-7e15e821cc86@github.com>
Message-ID: <MUyu90zcC-nAxZ_hggU74PsEEIWtPafALRaMsOMLEoo=.225fb3a7-69ed-4fdb-b43a-b4c7d5c7f618@github.com>

On Fri, 4 Apr 2025 09:54:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> fixed!
>
> This file uses 4 spaces. Please take another look.

Thanks for pointing that out! I've corrected the indentation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24276#discussion_r2028546316

From mdoerr at openjdk.org  Fri Apr  4 10:28:59 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 4 Apr 2025 10:28:59 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v5]
In-Reply-To: <48Q0GwgOyeCT0NBwq6gmM0z7EeANYythkfkohLBHbCU=.acfc8160-231c-4a4a-b411-fbdd46d919f2@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <48Q0GwgOyeCT0NBwq6gmM0z7EeANYythkfkohLBHbCU=.acfc8160-231c-4a4a-b411-fbdd46d919f2@github.com>
Message-ID: <U9-CBKbM8o9bTYevbUN2Yb2GsaGpOmAheTGRkMPe8_U=.b5c54443-71c4-41d9-abd2-3d7706fdc320@github.com>

On Fri, 4 Apr 2025 10:25:31 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

Thanks for cleaning this up!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24276#pullrequestreview-2742533602

From varadam at openjdk.org  Fri Apr  4 10:33:27 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 10:33:27 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v5]
In-Reply-To: <48Q0GwgOyeCT0NBwq6gmM0z7EeANYythkfkohLBHbCU=.acfc8160-231c-4a4a-b411-fbdd46d919f2@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
 <48Q0GwgOyeCT0NBwq6gmM0z7EeANYythkfkohLBHbCU=.acfc8160-231c-4a4a-b411-fbdd46d919f2@github.com>
Message-ID: <PXVccQBudT9E63HJPt49zgP8jUIgfcp6N5htcEFbrb0=.d7f1364e-1cf3-4d9a-8891-fe92f9cf8b83@github.com>

On Fri, 4 Apr 2025 10:25:31 GMT, Varada M <varadam at openjdk.org> wrote:

>> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
>> 
>> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

Thanks all!

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

PR Comment: https://git.openjdk.org/jdk/pull/24276#issuecomment-2778258562

From varadam at openjdk.org  Fri Apr  4 10:33:28 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 10:33:28 GMT
Subject: Integrated: 8353053: (fs) Add support for UserDefinedFileAttributeView
 on AIX
In-Reply-To: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
Message-ID: <y6wTcZ9Cb2GT5FD4rXFp0_eFtddzUsSA2k91sRTdNCM=.8ca19c42-3bac-494a-93fd-3db427464f6a@github.com>

On Thu, 27 Mar 2025 11:37:52 GMT, Varada M <varadam at openjdk.org> wrote:

> In AIX, the JFS2 supports extended attributes which has fgetea, fsetea, flistea, femoveea APIs support fetching, setting, listing and removing extended attributes. 
> 
> JBS: [JDK-8353053](https://bugs.openjdk.org/browse/JDK-8353053)

This pull request has now been integrated.

Changeset: 1161b566
Author:    Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1161b566ca06786996cf47a4475bcdabaa24cde8
Stats:     113 lines in 6 files changed: 102 ins; 5 del; 6 mod

8353053: (fs) Add support for UserDefinedFileAttributeView on AIX

Reviewed-by: mdoerr, jkern

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

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

From rriggs at openjdk.org  Fri Apr  4 12:44:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 12:44:03 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for removal
Message-ID: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>

Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission

@Deprecated(forRemoval = true, since="25")
Is added to each class and the existing @apiNote is converted to @deprected

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

Commit messages:
 - 8353641: Deprecate core library permission classes for removal

Changes: https://git.openjdk.org/jdk/pull/24444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353641
  Stats: 47 lines in 15 files changed: 28 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

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

From dfuchs at openjdk.org  Fri Apr  4 12:56:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 4 Apr 2025 12:56:03 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <qv7HjlgLp6J5BsLK4K6AouDLE6uQWG5D1fm9xBLS_PY=.9a8d47a7-1e1e-4264-bac3-12bb66b2d13c@github.com>

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

Looks reasonable to me. Changes to LoggingPermission look good. Out of curiosity I also  looked at all usages of RuntimePermission in the JDK - I believe you caught them all - including the unexpected use in XSLT.

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

PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2778654645

From bpb at openjdk.org  Fri Apr  4 15:08:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Apr 2025 15:08:48 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <ZcC9b8lmWYbsu9m7yToB_2j7f098rxpcZ-6irDCB2pM=.961cdf9b-ca6c-4170-bc1e-f7e92ac0ee29@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
 <ZcC9b8lmWYbsu9m7yToB_2j7f098rxpcZ-6irDCB2pM=.961cdf9b-ca6c-4170-bc1e-f7e92ac0ee29@github.com>
Message-ID: <_k5QoZC5zu6SkWrLidbKzHaAuxQTuJEL36asxxLVNu8=.fd93c322-8737-45f6-b15e-c8351cdb7fd3@github.com>

On Thu, 3 Apr 2025 22:10:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I would encourage going further with the refactoring folding two classes into one.

Sounds like a good idea. I will investigate. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2779003523

From rriggs at openjdk.org  Fri Apr  4 16:39:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 16:39:27 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v2]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <-VbTKqOznNLKI7R7AHZEECmO_Gfu5aYoFpE7T2FriqY=.79b97a1a-1787-465c-b6a8-f590a01c8f9b@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

  Add SuppressWarnings to a Windows source missed earlier.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/3ae4467e..1fa560a4

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

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

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

From rriggs at openjdk.org  Fri Apr  4 18:21:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 18:21:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v3]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <WFSjet0Va39HuO_4pcHMq0VS6fn504v_fAoCE72_TRg=.e4cf6bad-fd3b-4e5c-a478-9192054bb168@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

  Updated style of @Deprecated to match most existing @Deprecated annotations
  `since` comes before `forRemoval`
  No spaces around `=`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/1fa560a4..bb18c1e6

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

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

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

From iris at openjdk.org  Fri Apr  4 18:40:50 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 4 Apr 2025 18:40:50 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v3]
In-Reply-To: <WFSjet0Va39HuO_4pcHMq0VS6fn504v_fAoCE72_TRg=.e4cf6bad-fd3b-4e5c-a478-9192054bb168@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <WFSjet0Va39HuO_4pcHMq0VS6fn504v_fAoCE72_TRg=.e4cf6bad-fd3b-4e5c-a478-9192054bb168@github.com>
Message-ID: <9XnN5LLqYWAbbv3Smz9WTvMTZcbGwpGnQJtozSQm0Co=.ba9516ba-7fdc-4694-88e4-93a78a788099@github.com>

On Fri, 4 Apr 2025 18:21:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated style of @Deprecated to match most existing @Deprecated annotations
>   `since` comes before `forRemoval`
>   No spaces around `=`

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2743835110

From rriggs at openjdk.org  Fri Apr  4 19:00:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:00:02 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

  Remove unused import of LinkPermission

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/bb18c1e6..25aa6099

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

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

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

From mullan at openjdk.org  Fri Apr  4 19:07:59 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 19:07:59 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
Message-ID: <ji0Vw4K2eD3TJSjHCWkv_goEcxz9MDwURNCM3yV2LWg=.26adbdbc-a7f5-43b0-838c-a7ed746c919e@github.com>

On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import of LinkPermission

Some copyright dates have not been updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24444#issuecomment-2779539268

From rriggs at openjdk.org  Fri Apr  4 19:15:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:15:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v5]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <x63KCZyWbSe94q9z-eouE19aFtmSCBf_XgAWNA2tXXE=.43d9f241-be4d-44dc-a8d3-c0ad8f25a741@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

  Update copyright in WindowsFileCopy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/25aa6099..c1457493

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

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

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

From mullan at openjdk.org  Fri Apr  4 19:15:29 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 4 Apr 2025 19:15:29 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v4]
In-Reply-To: <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <dFrchMH6C9V8xZsDQJo0PDn7NcpYixHxfCMaLm7ZjwI=.f2defaf4-72dc-42db-989d-1b6e6aaa5d61@github.com>
Message-ID: <lqupDkICj8xMqDWeqWRk4LXqu_ngGAW-PtSLpRAUkAc=.0bc4bc14-fc58-449e-a235-2f7721d2e82e@github.com>

On Fri, 4 Apr 2025 19:00:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import of LinkPermission

src/java.base/share/classes/java/io/FilePermission.java line 87:

> 85: 
> 86: @Deprecated(since="25", forRemoval=true)
> 87: @SuppressWarnings("removal")

Is this leftover? You already add it to the methods that need it.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 202:

> 200:     }
> 201: 
> 202:     @SuppressWarnings("removal")

This should not be necessary.

src/java.logging/share/classes/java/util/logging/LoggingPermission.java line 48:

> 46:  */
> 47: 
> 48: @Deprecated(forRemoval = true, since="25")

This order is different than other classes, maybe make it consistent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029312409
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029308725
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2029311303

From rriggs at openjdk.org  Fri Apr  4 19:22:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Apr 2025 19:22:46 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v6]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <FpwQiXKgwZOWkkHnSYhVi35mOhTqSKlv0hfIny3kwuA=.2b7f303c-9619-4b4e-9f5d-1311317627c8@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

  Remove unnecessary SuppressWarnings and correct Deprecated annotation style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/c1457493..9a9417a7

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

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

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

From duke at openjdk.org  Sat Apr  5 17:41:00 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 5 Apr 2025 17:41:00 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder)
Message-ID: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>

This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`.

A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`.

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

Commit messages:
 - Removed unused import
 - Limited to Writer.of(StringBuilder)
 - Must not change implementation of StringWriter as getBuffer would not reflect current content of internally used Writer
 - Fixed typo
 - Do not wrap Writer, but return it as-is
 - Forward flush() and close() for Flushable and Closeable
 - Draft: Test for Writer.of(Appendable)
 - Writer.of(Appendable)

Changes: https://git.openjdk.org/jdk/pull/24469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353795
  Stats: 379 lines in 4 files changed: 376 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/24469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24469/head:pull/24469

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

From duke at openjdk.org  Sun Apr  6 09:39:47 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Apr 2025 09:39:47 GMT
Subject: RFR: 8353795: Add Writer.of(StringBuilder)
In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
Message-ID: <g0lsTp2AtKgBUzS-sxX8T64b7UGEL_Cv4VadUcKdD-s=.f5e33fc9-6de7-4f81-94c2-86dc0dedba99@github.com>

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`.
> 
> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`.

Continuing from thread "[Request for Enhancement: java.io.Writer.of(Appendable) as an efficient alternative to java.io.StringWriter](https://mail.openjdk.org/pipermail/core-libs-dev/2025-March/141539.html)":

@liach wrote:
>...we can probably start drafting the API documentation of this new API `Writer.of(StringBuilder)`:
>```java
>@return a character stream that redirects to a specified StringBuilder}
><p>
>The {@code write} and {@code append} invocations are redirected to the {@code append} methods with the same parameter t>ypes on the specified StringBuilder, except {@code write(int)}, which delegates to {@code append(char)}. The {@code flush} and >{@code close} invocations have no effect.
>```
>I propose to specify this explicitly as a delegation proxy; we can infer the lack of thread safety from `StringBuilder`. (If we want, we can add an API note asking to use `StringWriter` if thread safety is needed). Also, we don't specify the `toString` behavior on the returned Writer (unlike for `StringWriter`); I think users should just use the `toString` on the `StringBuilder`.

Actually I do not see the benefit of documenting which method redirects to what other method or class, but I see that it binds us in future to today's decisions. Also I do not see what benefit notes about `StringWriter` and `toString` would be good for, as leaving it open provides most future flexibility to change eventually (just as we leave open `hashCode` and `equals`).

Having said that, instead I started the PR with a typical JavaDoc as it looks like what we did in `Reader.of()` recently.

WDYT?

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

PR Comment: https://git.openjdk.org/jdk/pull/24469#issuecomment-2781332523

From alanb at openjdk.org  Mon Apr  7 06:48:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 06:48:55 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v6]
In-Reply-To: <FpwQiXKgwZOWkkHnSYhVi35mOhTqSKlv0hfIny3kwuA=.2b7f303c-9619-4b4e-9f5d-1311317627c8@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <FpwQiXKgwZOWkkHnSYhVi35mOhTqSKlv0hfIny3kwuA=.2b7f303c-9619-4b4e-9f5d-1311317627c8@github.com>
Message-ID: <ZMH1bnmHOhkkLu3JF3q30a51Oa2gdpavKejtGOl4Vy8=.4f01975a-02ed-4096-9d96-6df22e111252@github.com>

On Fri, 4 Apr 2025 19:22:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary SuppressWarnings and correct Deprecated annotation style

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1639:

> 1637:      */
> 1638:     @SuppressWarnings("removal")
> 1639:     static volatile RuntimePermission modifyThreadPermission;

This can be removed, it's not used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2030554666

From alanb at openjdk.org  Mon Apr  7 08:44:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 08:44:58 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
Message-ID: <QcK0SZ0VNSdsTcLlpAQKweAAKX5Gzw4n9-aDUvRi_e8=.c39c60a0-bb25-4bf2-a932-a7011602ff25@github.com>

On Thu, 3 Apr 2025 01:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24400#pullrequestreview-2745995934

From alanb at openjdk.org  Mon Apr  7 08:44:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 08:44:59 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <Um2ciM3FZ99_m0wmC0vrm_q8rdgTMRYFZpC9NK_nChk=.1f19fb67-5c8c-4d0d-8ff4-48ead8d35545@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
 <u767jkbN87mJVp5S64YCO8sQUXRSeWM5w2Qj2pn3lY8=.b92caafd-4889-4c61-b31c-6ab130b46652@github.com>
 <Um2ciM3FZ99_m0wmC0vrm_q8rdgTMRYFZpC9NK_nChk=.1f19fb67-5c8c-4d0d-8ff4-48ead8d35545@github.com>
Message-ID: <JnXvGGLiP-LhIKmaBrVIgNZpuRIuImSIr9Njfn9O-b0=.65d2e4ad-4a4c-43e3-b958-009da5735cfa@github.com>

On Thu, 3 Apr 2025 17:54:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Correct, hence my comments after the table above about other opportunities in `WindowsUriSupport.fromUri`. If there are none, then perhaps the issue and PR summaries should be changed accordingly.

I think we should rename, otherwise the commit log will be a bit confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2782479819

From bpb at openjdk.org  Mon Apr  7 15:21:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 7 Apr 2025 15:21:12 GMT
Subject: RFR: 8321591: (fs) Path.of(URI) performance (win)
In-Reply-To: <JnXvGGLiP-LhIKmaBrVIgNZpuRIuImSIr9Njfn9O-b0=.65d2e4ad-4a4c-43e3-b958-009da5735cfa@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
 <u767jkbN87mJVp5S64YCO8sQUXRSeWM5w2Qj2pn3lY8=.b92caafd-4889-4c61-b31c-6ab130b46652@github.com>
 <Um2ciM3FZ99_m0wmC0vrm_q8rdgTMRYFZpC9NK_nChk=.1f19fb67-5c8c-4d0d-8ff4-48ead8d35545@github.com>
 <JnXvGGLiP-LhIKmaBrVIgNZpuRIuImSIr9Njfn9O-b0=.65d2e4ad-4a4c-43e3-b958-009da5735cfa@github.com>
Message-ID: <_-Vk73YanI1Ef6Rxpkh2zZ2ELxo6nAOUzARc5PXCYtM=.fff57e2f-c6ce-4ef4-be14-5e84cfb05345@github.com>

On Mon, 7 Apr 2025 08:42:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we should rename, otherwise the commit log will be a bit confusing.

Will do. I thinks it would also be worth filing two more related issues: one for the suggested refactoring of `WindowsPathParser`, and another to investigate improving the performance of other portions of the `URI` -> `Path` conversion.

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

PR Comment: https://git.openjdk.org/jdk/pull/24400#issuecomment-2783700768

From rriggs at openjdk.org  Mon Apr  7 17:18:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 17:18:40 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v7]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <FPgMhmaele4ojOh_5Bl80dEE3DUT68wO1cOMYpWtz0U=.47e6ff61-08dd-4626-8403-0e2ef0bf6e7b@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

  Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
  Remove dead code from ForkJoinPool.
  Add @SuppressWarnings("remove")

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/9a9417a7..322c5938

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

  Stats: 20 lines in 4 files changed: 11 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

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

From rriggs at openjdk.org  Mon Apr  7 18:40:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 7 Apr 2025 18:40:35 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

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

 - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
   SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
 - Merge branch 'master' into 8353641-deprecate-premission-classes
 - Missing suppresswarnings
 - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
   Remove dead code from ForkJoinPool.
   Add @SuppressWarnings("remove")
 - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
 - Update copyright in WindowsFileCopy
 - Remove unused import of LinkPermission
 - Updated style of @Deprecated to match most existing @Deprecated annotations
   `since` comes before `forRemoval`
   No spaces around `=`
 - Add SuppressWarnings to a Windows source missed earlier.
 - 8353641: Deprecate core library permission classes for removal
   
   Now that the Security Manager is permanently disabled, the following permission classes
   in the core libraries area can be deprecated for removal as they are no longer useful:
   FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
   RuntimePermission, and SerializablePermission
   
   @Deprecated(forRemoval = true, since="25")
   Is added to each class and the existing @apiNote is converted to @deprected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24444/files
  - new: https://git.openjdk.org/jdk/pull/24444/files/322c5938..6d3f003d

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

  Stats: 10986 lines in 240 files changed: 8087 ins; 2384 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/24444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24444/head:pull/24444

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

From bpb at openjdk.org  Mon Apr  7 18:49:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 7 Apr 2025 18:49:50 GMT
Subject: Integrated: 8321591: (fs) Improve String -> Path conversion
 performance (win)
In-Reply-To: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
References: <GH629150CjzW2tt8PGQQ37JDCfzWJU47T8DuIJRbtkQ=.873f428e-dcce-430e-aa97-a256ff3bd334@github.com>
Message-ID: <q2CVCDipcSqK0GATQWRVXhoiaONw3xyBdNsHcTXwi_0=.51f45a2d-3ff0-4990-9a7c-25935ec7b69d@github.com>

On Thu, 3 Apr 2025 01:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the performance of `WindowsPathParser.normalize` by using a `char` array to perform the normalization in place instead of appending to a `StringBuilder`. The `Result` inner class is also converted to a `record`.

This pull request has now been integrated.

Changeset: 5481021e
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5481021ee64fd457279ea7083be0f977c7ce3e3c
Stats:     146 lines in 2 files changed: 91 ins; 33 del; 22 mod

8321591: (fs) Improve String -> Path conversion performance (win)

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Tue Apr  8 06:44:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 06:44:15 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
Message-ID: <fPf4I6lx1VDVOXn0m756xJFfn5xwJ_hjYjzGJvmmdIE=.1b3ac35e-2438-4d6b-9a0b-3f52e2fe17f0@github.com>

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>  - Missing suppresswarnings
>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>    Remove dead code from ForkJoinPool.
>    Add @SuppressWarnings("remove")
>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>  - Update copyright in WindowsFileCopy
>  - Remove unused import of LinkPermission
>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>    `since` comes before `forRemoval`
>    No spaces around `=`
>  - Add SuppressWarnings to a Windows source missed earlier.
>  - 8353641: Deprecate core library permission classes for removal
>    
>    Now that the Security Manager is permanently disabled, the following permission classes
>    in the core libraries area can be deprecated for removal as they are no longer useful:
>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>    RuntimePermission, and SerializablePermission
>    
>    @Deprecated(forRemoval = true, since="25")
>    Is added to each class and the existing @apiNote is converted to @deprected

src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49:

> 47:      */
> 48:     @SuppressWarnings("removal")
> 49:     FilePermission newPermUsingAltPath(FilePermission input);

I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now.

src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443:

> 441:     @SuppressWarnings("removal")
> 442:     private void defineTransletClasses()
> 443:         throws TransformerConfigurationException {

In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032494012
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2032493150

From duke at openjdk.org  Tue Apr  8 11:27:31 2025
From: duke at openjdk.org (YuHui936)
Date: Tue, 8 Apr 2025 11:27:31 GMT
Subject: RFR: 8294068: Unconditional and eager load of nio library since
 JDK-8264744
In-Reply-To: <NnmpDgvTAcffeoO0L6hI5B3SWVdr5nbiLPTxOsplpUs=.b389ec21-c1d8-476e-9678-06c031328b9c@github.com>
References: <NnmpDgvTAcffeoO0L6hI5B3SWVdr5nbiLPTxOsplpUs=.b389ec21-c1d8-476e-9678-06c031328b9c@github.com>
Message-ID: <5LtByF2VzmXidNMEpcafwMg-zggX1KvTBj_GsCzGvHo=.0c95f751-51b2-400b-93fe-3350fbd9511e@github.com>

On Tue, 20 Sep 2022 16:47:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Move `LinuxFileSystem` native code to `LinuxNativeDispatcher`.

Files.copy() fails with EOPNOTSUPP on NFS when copy_file_range is unsupported by kernel

Detailed Description
**Environment:**
 - JDK Version: OpenJDK 21.0.3 
 - OS: Alpine Linux 3.20 (kernel 3.10) 
 - Filesystem: NFS 
 - Glibc: 2.36 (supports `copy_file_range` syscall) 
 - Container Environment: Alpine 3.20 with kernel 3.10 (lacks `copy_file_range` support)  
 **Problem:** When invoking `Files.copy(Path, Path, CopyOption)` on an NFS filesystem, the operation fails with:   
 `java.io.IOException: Operation not supported` due to error code `EOPNOTSUPP`.  
 **Root Cause Analysis:** 
 - JDK 21's `LinuxNativeDispatcher.directCopy0` attempts to use the `copy_file_range` syscall.   
 - The NFS driver in older kernels (e.g., 3.10) returns `EOPNOTSUPP` (indicating unsupported operation).   
 - JDK currently handles `EINVAL`, `ENOSYS`, and `EXDEV` by falling back to `sendfile64`, but **ignores `EOPNOTSUPP`**, leading to an unchecked exception.    **Expected Behavior:**   JDK should RESTARTABLE to `sendfile64`  when encountering `EOPNOTSUPP`.  
 **Steps to Reproduce:** 
 1. Mount an NFS filesystem in an Alpine 3.20 container (kernel 3.10).   
 2. Run the following Java code with JDK 21:      ```java    Path src = Path.of("/nfs/src.txt");    Path dst = Path.of("/nfs/dst.txt");    Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING); 
 3. Observe the exception:     java.io.IOException: Operation not supported         at java.base/sun.nio.fs.LinuxNativeDispatcher.directCopy0(Native Method)         ... (full stack trace)

Additional Context
Attach the full exception stack trace (provided in the problem description). Relevant kernel code snippet (from nfs42_proc_copy):     if (!nfs_server_capable(file_inode(dst), NFS_CAP_COPY))         return -EOPNOTSUPP; // Kernel returns EOPNOTSUPP for unsupported copy

Suggested Fix
Extend error handling in directCopy0 to catch EOPNOTSUPP.
![1](https://github.com/user-attachments/assets/781f420a-87c7-4168-8b29-d657ca28fa90)
![2](https://github.com/user-attachments/assets/84fc840f-1e4e-45bc-9426-734585414745)
![3](https://github.com/user-attachments/assets/7dc6d0ce-0fb7-444a-9590-7d10c685bed3)
![4](https://github.com/user-attachments/assets/e3bda0cd-46cd-4676-99d2-5f1683142082)

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

PR Comment: https://git.openjdk.org/jdk/pull/10362#issuecomment-2786106876

From rriggs at openjdk.org  Tue Apr  8 16:09:27 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Apr 2025 16:09:27 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <fPf4I6lx1VDVOXn0m756xJFfn5xwJ_hjYjzGJvmmdIE=.1b3ac35e-2438-4d6b-9a0b-3f52e2fe17f0@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
 <fPf4I6lx1VDVOXn0m756xJFfn5xwJ_hjYjzGJvmmdIE=.1b3ac35e-2438-4d6b-9a0b-3f52e2fe17f0@github.com>
Message-ID: <WBqp_kq9JcSAs_SXxuSSsVE6atrT18clBobXK8GRyV0=.508bbd8c-f143-4654-a734-c728b65eee06@github.com>

On Tue, 8 Apr 2025 06:41:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>>  - Missing suppresswarnings
>>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>>    Remove dead code from ForkJoinPool.
>>    Add @SuppressWarnings("remove")
>>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>>  - Update copyright in WindowsFileCopy
>>  - Remove unused import of LinkPermission
>>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>>    `since` comes before `forRemoval`
>>    No spaces around `=`
>>  - Add SuppressWarnings to a Windows source missed earlier.
>>  - 8353641: Deprecate core library permission classes for removal
>>    
>>    Now that the Security Manager is permanently disabled, the following permission classes
>>    in the core libraries area can be deprecated for removal as they are no longer useful:
>>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>>    RuntimePermission, and SerializablePermission
>>    
>>    @Deprecated(forRemoval = true, since="25")
>>    Is added to each class and the existing @apiNote is converted to @deprected
>
> src/java.base/share/classes/jdk/internal/access/JavaIOFilePermissionAccess.java line 49:
> 
>> 47:      */
>> 48:     @SuppressWarnings("removal")
>> 49:     FilePermission newPermUsingAltPath(FilePermission input);
> 
> I assume JavaIOFilePermissionAccess can be removed, nothing should be using this now.

Filed JDK-8354053 to remove as a separate issue.

> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java line 443:
> 
>> 441:     @SuppressWarnings("removal")
>> 442:     private void defineTransletClasses()
>> 443:         throws TransformerConfigurationException {
> 
> In passing, the PermissionCollection used to construct the PD here is no longer needed. If this is cleaned up then the SW wouldn't be needed.

Filed JDK-8354054 to cleanup in a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033542174
PR Review Comment: https://git.openjdk.org/jdk/pull/24444#discussion_r2033538959

From alanb at openjdk.org  Tue Apr  8 16:54:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 16:54:17 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <R2an5zwuJOJtIvKTsZJSaBKs5V6JYjFQV748hGaRfvw=.68fa6492-e974-40b9-a034-343e85a95fbe@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

I think the API docs in the latest draft looks okay. It mildly bothers me a bit is that getChars is JDK 1.0 API but the trade off with doing a new API is that it would need to be implemented by String and SB so I think the proposal on the table is okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2787087670

From duke at openjdk.org  Tue Apr  8 17:07:30 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Apr 2025 17:07:30 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <R2an5zwuJOJtIvKTsZJSaBKs5V6JYjFQV748hGaRfvw=.68fa6492-e974-40b9-a034-343e85a95fbe@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <R2an5zwuJOJtIvKTsZJSaBKs5V6JYjFQV748hGaRfvw=.68fa6492-e974-40b9-a034-343e85a95fbe@github.com>
Message-ID: <3_9EK7Fh7EyKrg-5msgTMYB-icpPwvBRL5v7bXWdsTA=.ed4bda82-a9cb-43e9-be32-416cdef6a3da@github.com>

On Tue, 8 Apr 2025 16:51:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the API docs in the latest draft looks okay. It mildly bothers me a bit is that getChars is JDK 1.0 API but the trade off with doing a new API is that it would need to be implemented by String and SB so I think the proposal on the table is okay.

Kindly asking to mark this PR as reviewed, so I will go on with the CSR next.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2787121134

From liach at openjdk.org  Tue Apr  8 18:14:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Apr 2025 18:14:32 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <4U3TP4zVn6Bg39f6rLOCDT97Zfj33DEMrJm2seoatN4=.155d1292-2a03-4b5b-ad7e-62adf9bd2be7@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

Should we ask hotspot compiler engineers for inputs on how useful this API is for allowing batch/vectorized copy and eliminating overheads of defensive copy array allocation?

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2787292309

From bpb at openjdk.org  Tue Apr  8 22:56:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Apr 2025 22:56:53 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v12]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <KE7Ucy7Riw8XDq2Lqh901Dhw4RwsTY7E3nc18LoCgrY=.727216de-4084-43d3-8437-c9644bc72fbd@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5b42c46b...3e1e15dc

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=11
  Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From duke at openjdk.org  Wed Apr  9 03:06:42 2025
From: duke at openjdk.org (duke)
Date: Wed, 9 Apr 2025 03:06:42 GMT
Subject: Withdrawn: 8069345: (fs) FileTreeWalker throws NotDirectoryException
 on file junction points
In-Reply-To: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
Message-ID: <u8OxhoAUeF0_t16K7EqkBhPZMZ8hJQh0keDIzvpVKNU=.d4fbad94-3d6c-4586-996d-0df79b78471d@github.com>

On Thu, 17 Oct 2024 00:05:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve support for Windows directory junctions.

This pull request has been closed without being integrated.

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

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

From michaelm at openjdk.org  Wed Apr  9 10:04:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 9 Apr 2025 10:04:47 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v4]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <7QqAa8kPfdRpCCwiAleAk7v53UshuArCnUvMpRR0On8=.4646bb5b-5382-437c-9e7e-9e8513698d4a@github.com>

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

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

 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - doc + copyright update
 - remove file added by mistake
 - whitespace
 - moved test
 - Merge branch 'master' into 8348986-exceptions
 - update
 - update
 - ... and 7 more: https://git.openjdk.org/jdk/compare/f7fa05f5...f5501d18

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=03
  Stats: 1000 lines in 42 files changed: 767 ins; 104 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From mullan at openjdk.org  Thu Apr 10 15:12:45 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 10 Apr 2025 15:12:45 GMT
Subject: RFR: 8353641: Deprecate core library permission classes for
 removal [v8]
In-Reply-To: <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
 <w0WNr11913xl2dqs00YEAFAnU1XFODIa8dMuDLv64Cg=.6539a99c-e7e5-4b80-8dd5-edc0f339d9f7@github.com>
Message-ID: <ikjeuMVQkSWmEtExqnCh9-x_fLondaivhSTB3cmdA48=.e3dc8213-86c2-4f03-8e6c-1e1c9eef9cc1@github.com>

On Mon, 7 Apr 2025 18:40:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
>> 
>> @Deprecated(forRemoval = true, since="25")
>> Is added to each class and the existing @apiNote is converted to @deprected
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Revert "Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions."
>    SecureClassLoader.getPermissions and URLClassLoader.getPermissions are not marked as Deprecated.
>  - Merge branch 'master' into 8353641-deprecate-premission-classes
>  - Missing suppresswarnings
>  - Mark as deprecated for removal as of jdk 25: SecureClassLoader.getPermissions, URLClassLoader.getPermissions.
>    Remove dead code from ForkJoinPool.
>    Add @SuppressWarnings("remove")
>  - Remove unnecessary SuppressWarnings and correct Deprecated annotation style
>  - Update copyright in WindowsFileCopy
>  - Remove unused import of LinkPermission
>  - Updated style of @Deprecated to match most existing @Deprecated annotations
>    `since` comes before `forRemoval`
>    No spaces around `=`
>  - Add SuppressWarnings to a Windows source missed earlier.
>  - 8353641: Deprecate core library permission classes for removal
>    
>    Now that the Security Manager is permanently disabled, the following permission classes
>    in the core libraries area can be deprecated for removal as they are no longer useful:
>    FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission,
>    RuntimePermission, and SerializablePermission
>    
>    @Deprecated(forRemoval = true, since="25")
>    Is added to each class and the existing @apiNote is converted to @deprected

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24444#pullrequestreview-2757226356

From rriggs at openjdk.org  Thu Apr 10 19:22:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Apr 2025 19:22:40 GMT
Subject: Integrated: 8353641: Deprecate core library permission classes for
 removal
In-Reply-To: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
References: <qUfpDkQdmG-9UpXQrNWML5_HOfhEpzPih1KoRUlbz5o=.ecef12b6-afd2-4437-b3b2-6e130305b06c@github.com>
Message-ID: <HtfmPyZbbd3pth_MbkOYyTAm1hO8XB4qFYP8iPteFs8=.990be209-2350-4039-b576-16681664fd20@github.com>

On Fri, 4 Apr 2025 12:37:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Now that the Security Manager is permanently disabled, the following permission classes in the core libraries area can be deprecated for removal as they are no longer useful: FilePermission, LinkPermission, LoggingPermission, PropertyPermission, ReflectPermission, RuntimePermission, and SerializablePermission
> 
> @Deprecated(forRemoval = true, since="25")
> Is added to each class and the existing @apiNote is converted to @deprected

This pull request has now been integrated.

Changeset: af5db513
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af5db513060db5f89c071f531e6111c69fcd7370
Stats:     54 lines in 17 files changed: 26 ins; 8 del; 20 mod

8353641: Deprecate core library permission classes for removal

Reviewed-by: mullan, iris

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

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

From michaelm at openjdk.org  Thu Apr 10 21:26:21 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:26:21 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>

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

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

  update to minimise code changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/f5501d18..c41146b0

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

  Stats: 208 lines in 26 files changed: 16 ins; 61 del; 131 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From michaelm at openjdk.org  Thu Apr 10 21:31:31 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 10 Apr 2025 21:31:31 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
Message-ID: <FVaEr6y4FNzivtR-V1BPH96Xaa8CgVRJ-wmNKWk0-_4=.efa83883-ab10-4b7f-bd24-e6558c86693d@github.com>

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

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

I've just updated the PR with a change that replaces the new methods of the form `throwException()` with the previous pattern of the form `throw new XException`. This reduces the code changes a bit further and is more readable.

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

PR Comment: https://git.openjdk.org/jdk/pull/23929#issuecomment-2795207656

From duke at openjdk.org  Fri Apr 11 06:36:45 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Apr 2025 06:36:45 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <4U3TP4zVn6Bg39f6rLOCDT97Zfj33DEMrJm2seoatN4=.155d1292-2a03-4b5b-ad7e-62adf9bd2be7@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <4U3TP4zVn6Bg39f6rLOCDT97Zfj33DEMrJm2seoatN4=.155d1292-2a03-4b5b-ad7e-62adf9bd2be7@github.com>
Message-ID: <5TyyklVSyjd6_Cxsbea5bqiPqKDHG6qb3Fxe-O9KAdQ=.d6292b16-d554-4ec4-babd-f8e0c18037ae@github.com>

On Tue, 8 Apr 2025 18:12:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we ask hotspot compiler engineers for inputs on how useful this API is for allowing batch/vectorized copy and eliminating overheads of defensive copy array allocation?

I have no strong feelings about that.

As it looks like we reached concensus on the proposed change, I have now copied the spec into the CSR and set it into the proposed state. Kindly asking for your reviews of the CSR, so it can rather soon proceed into the provisional state.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2795968057

From dfuchs at openjdk.org  Fri Apr 11 09:06:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 09:06:28 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
Message-ID: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>

Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

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

Commit messages:
 - 8353642: Deprecate networking permission classes for removal

Changes: https://git.openjdk.org/jdk/pull/24592/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353642
  Stats: 58 lines in 12 files changed: 36 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

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

From dfuchs at openjdk.org  Fri Apr 11 10:01:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 10:01:26 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

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

  Missing white spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24592/files
  - new: https://git.openjdk.org/jdk/pull/24592/files/e9dc4146..9b371b3a

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

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

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

From dfuchs at openjdk.org  Fri Apr 11 10:01:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 10:01:26 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <YMuW-8YlyN8IL-7hdfdCko8FUw2PTf-WQ20Clz9ZU7A=.d0c0dbcd-8918-43a2-85a4-8f6afdee9c72@github.com>

On Fri, 11 Apr 2025 09:00:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

The CSR is also ready to be reviewed at [https://bugs.openjdk.org/browse/JDK-8354406](https://bugs.openjdk.org/browse/JDK-8354406)

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796425675

From djelinski at openjdk.org  Fri Apr 11 11:00:26 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 11:00:26 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>

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

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

src/java.base/share/classes/java/net/HttpURLConnection.java line 617:

> 615:      * {@link java.security.AllPermission}.
> 616:      */
> 617:     @Deprecated(since = "25")

can this (and all other getPermission methods) be "forRemoval=true"?

src/java.base/share/classes/java/security/CodeSource.java line 468:

> 466:                 }
> 467:                 @SuppressWarnings("removal")
> 468:                 var result = this.sp.implies(that.sp);

Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039291810
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039304662

From djelinski at openjdk.org  Fri Apr 11 11:12:40 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 11:12:40 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
Message-ID: <jSKaMQwnV-o2JekwUPSkleTLlt78kd239YomdDoyS5w=.584cebff-fb5f-4b68-8fc6-ad23eb42a81b@github.com>

On Fri, 11 Apr 2025 10:55:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing white spaces
>
> src/java.base/share/classes/java/security/CodeSource.java line 468:
> 
>> 466:                 }
>> 467:                 @SuppressWarnings("removal")
>> 468:                 var result = this.sp.implies(that.sp);
> 
> Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere).

also the JavaDoc of the implies method references the SocketPermission. That will also need to be cleaned up at some point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039324745

From djelinski at openjdk.org  Fri Apr 11 11:19:27 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 11:19:27 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <jtpf0LUuSokcX2C4Wv97UaLGB5krwE2ULefADEhr2e4=.ba0029ec-f85d-4335-99d6-008748109c6c@github.com>

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

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

src/java.base/share/classes/java/net/SocketPermission.java line 1311:

> 1309: 
> 1310: @SuppressWarnings("removal")
> 1311: @Deprecated(since = "25", forRemoval = true)

this class is internal, no need to deprecate

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039335050

From dfuchs at openjdk.org  Fri Apr 11 11:34:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 11:34:32 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
Message-ID: <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>

On Fri, 11 Apr 2025 10:45:20 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing white spaces
>
> src/java.base/share/classes/java/net/HttpURLConnection.java line 617:
> 
>> 615:      * {@link java.security.AllPermission}.
>> 616:      */
>> 617:     @Deprecated(since = "25")
> 
> can this (and all other getPermission methods) be "forRemoval=true"?

Possibly. @AlanBateman may have some thoughts on this.

> src/java.base/share/classes/java/net/SocketPermission.java line 1311:
> 
>> 1309: 
>> 1310: @SuppressWarnings("removal")
>> 1311: @Deprecated(since = "25", forRemoval = true)
> 
> this class is internal, no need to deprecate

It helps getting warnings at the place where the class is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039358351
PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039360730

From dfuchs at openjdk.org  Fri Apr 11 11:34:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 11:34:33 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <jSKaMQwnV-o2JekwUPSkleTLlt78kd239YomdDoyS5w=.584cebff-fb5f-4b68-8fc6-ad23eb42a81b@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <jSKaMQwnV-o2JekwUPSkleTLlt78kd239YomdDoyS5w=.584cebff-fb5f-4b68-8fc6-ad23eb42a81b@github.com>
Message-ID: <_lrzJTVqcfATXdXToFeL69PLIu9LRQ37BFmmlFYvTWQ=.8e3a7e15-e5a5-45dc-b0d1-362950b51939@github.com>

On Fri, 11 Apr 2025 11:10:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/CodeSource.java line 468:
>> 
>>> 466:                 }
>>> 467:                 @SuppressWarnings("removal")
>>> 468:                 var result = this.sp.implies(that.sp);
>> 
>> Will we need to rewrite this code without SocketPermissions? Can we remove it, maybe? It is only used by CodeSource.implies, which is not used by the JDK (but may be used elsewhere).
>
> also the JavaDoc of the implies method references the SocketPermission. That will also need to be cleaned up at some point.

That will be left over for someone in security-libs to cleanup this code at their convenience before we remove SocketException.

Hmmm... If the public API references SocketException we might have to deprecate in this PR too. Not sure what the implications are. Maybe @seanjmullan can advise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039353439

From alanb at openjdk.org  Fri Apr 11 11:37:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Apr 2025 11:37:36 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
Message-ID: <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>

On Fri, 11 Apr 2025 11:30:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/HttpURLConnection.java line 617:
>> 
>>> 615:      * {@link java.security.AllPermission}.
>>> 616:      */
>>> 617:     @Deprecated(since = "25")
>> 
>> can this (and all other getPermission methods) be "forRemoval=true"?
>
> Possibly. @AlanBateman may have some thoughts on this.

I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039366899

From dfuchs at openjdk.org  Fri Apr 11 11:50:24 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 11:50:24 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
 <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>
Message-ID: <LgSm4MVnNgaaLWF2VWlsvXj4eEfe6R442QPXSdvdSRw=.c8bf4811-1a8c-4d03-8e2a-3faaf2739516@github.com>

On Fri, 11 Apr 2025 11:34:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Possibly. @AlanBateman may have some thoughts on this.
>
> I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs.

Thanks - I will do that then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039391997

From djelinski at openjdk.org  Fri Apr 11 12:04:24 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 12:04:24 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>

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

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

The GHA failure (Windows) appears to be related.

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796715234

From dfuchs at openjdk.org  Fri Apr 11 12:33:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 12:33:25 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>
Message-ID: <Z9HsGkpg6rIKrOFz7aGLdX3jpC7eO4gs6WtxagvnItw=.1eb795a2-1ccb-4a80-9670-cacf4ceb8990@github.com>

On Fri, 11 Apr 2025 12:01:52 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The GHA failure (Windows) appears to be related.

Yes - I missed one windows specific file in my original patch. I have a test running in the CI and I am waiting for it to pass before updating the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796783392

From michaelm at openjdk.org  Fri Apr 11 13:49:27 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 11 Apr 2025 13:49:27 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v2]
In-Reply-To: <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
Message-ID: <oNcT5NhnJBf4nc_GxNkTSfF90dPovQ2WtN6-YDmnJ6I=.e4d37950-018f-4f7f-a834-b5c52aaaacec@github.com>

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

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing white spaces

src/java.base/share/classes/java/security/CodeSource.java line 461:

> 459:                 if (this.sp == null) {
> 460:                     @SuppressWarnings("removal")
> 461:                     var _ = this.sp = new SocketPermission(thisHost, "resolve");

What's the reason for the `var _ =` bit ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039598335

From dfuchs at openjdk.org  Fri Apr 11 13:56:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 13:56:18 GMT
Subject: RFR: 8353642: Deprecate networking permission classes for removal
 [v3]
In-Reply-To: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
Message-ID: <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>

> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.

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

  Review feedback. Deprecate getPermission for removal.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24592/files
  - new: https://git.openjdk.org/jdk/pull/24592/files/9b371b3a..d47a31d1

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

  Stats: 22 lines in 7 files changed: 5 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/24592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24592/head:pull/24592

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

From dfuchs at openjdk.org  Fri Apr 11 14:00:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 14:00:32 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v2]
In-Reply-To: <Z9HsGkpg6rIKrOFz7aGLdX3jpC7eO4gs6WtxagvnItw=.1eb795a2-1ccb-4a80-9670-cacf4ceb8990@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <j4b_gXM-5ivPvPDfWtOHF9AE8HkWx0odnBZwr4Ijb9A=.05e0ba61-c877-4d51-9505-de6fb204984e@github.com>
 <Z9HsGkpg6rIKrOFz7aGLdX3jpC7eO4gs6WtxagvnItw=.1eb795a2-1ccb-4a80-9670-cacf4ceb8990@github.com>
Message-ID: <BuLdKGcqJo1LsA8UIAdI8N_it8N1Pz7JWIaupRdfnqw=.ff804f7a-18c1-49e5-b99f-d6f3e9589ed3@github.com>

On Fri, 11 Apr 2025 12:31:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The GHA failure (Windows) appears to be related.

Should be fixed now

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

PR Comment: https://git.openjdk.org/jdk/pull/24592#issuecomment-2796995066

From dfuchs at openjdk.org  Fri Apr 11 14:00:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 14:00:33 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v2]
In-Reply-To: <LgSm4MVnNgaaLWF2VWlsvXj4eEfe6R442QPXSdvdSRw=.c8bf4811-1a8c-4d03-8e2a-3faaf2739516@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <VVsLW1rJ2dziTJr5D5L7SOx3jvUKVeoxQ-Eyd2Ulv2U=.9224f800-eed5-4ada-bd8f-835a8c83ee47@github.com>
 <k0nTRZe9px2bRgNruCYr0XuYaBxFo2Bqm32Ld0fiyhc=.6c1e9e91-1e97-466d-bfb8-f6fe58427103@github.com>
 <rfBaIvhdw5kWJ3JJmezz5-aD0b0n8U5frLH8pF0EL8w=.61e58686-1469-4157-afd9-cced4459c23e@github.com>
 <LgSm4MVnNgaaLWF2VWlsvXj4eEfe6R442QPXSdvdSRw=.c8bf4811-1a8c-4d03-8e2a-3faaf2739516@github.com>
Message-ID: <BBBvtz4i_6VVHeVJntpm_b2nypOm9JLfSaYz5omSPTU=.92715c6a-13c7-4b98-93b7-90b1e891716c@github.com>

On Fri, 11 Apr 2025 11:47:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I think we should at least consider deprecating URLConnection.getPermission and HttpURLConnection.getPermission for removal, only because I don't immediately see the advantage of doing it in two steps for these two APIs.
>
> Thanks - I will do that then

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039614980

From dfuchs at openjdk.org  Fri Apr 11 14:00:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Apr 2025 14:00:34 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v2]
In-Reply-To: <oNcT5NhnJBf4nc_GxNkTSfF90dPovQ2WtN6-YDmnJ6I=.e4d37950-018f-4f7f-a834-b5c52aaaacec@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <C6NoaRHG-oWV85gSnasDfTmE9FRJYrdd3tm3Zp6Cp3Q=.db8a7375-2faf-40d9-9cde-62896f1195d6@github.com>
 <oNcT5NhnJBf4nc_GxNkTSfF90dPovQ2WtN6-YDmnJ6I=.e4d37950-018f-4f7f-a834-b5c52aaaacec@github.com>
Message-ID: <GUqHGPI6S5Nysb7tacLGdPU_Hk3dUjClN3g6KVgAxPY=.ae30e73c-8395-4847-af67-5b672005ee38@github.com>

On Fri, 11 Apr 2025 13:47:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing white spaces
>
> src/java.base/share/classes/java/security/CodeSource.java line 461:
> 
>> 459:                 if (this.sp == null) {
>> 460:                     @SuppressWarnings("removal")
>> 461:                     var _ = this.sp = new SocketPermission(thisHost, "resolve");
> 
> What's the reason for the `var _ =` bit ?

`@SuppressWarnings` can not be applied to a an expression - it needs a (variable/method/class) declaration

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24592#discussion_r2039613130

From michaelm at openjdk.org  Fri Apr 11 14:58:29 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 11 Apr 2025 14:58:29 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v3]
In-Reply-To: <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
Message-ID: <O9SFskwbY-Q6p3u7Q_BTkCod6iA8Ls9McAP4G4PO7to=.4f050136-617d-436b-8154-66f3988cc830@github.com>

On Fri, 11 Apr 2025 13:56:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback. Deprecate getPermission for removal.

Looks fine to me.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2760620879

From djelinski at openjdk.org  Fri Apr 11 15:50:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 11 Apr 2025 15:50:43 GMT
Subject: RFR: 8353642: Deprecate URL::getPermission method and networking
 permission classes for removal [v3]
In-Reply-To: <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
References: <Tvn6pY3UgWnxSpl86JFq8Wr4w4j6p-T-56w3_gBdPUU=.b7dc9165-d38e-43a4-9456-d66765d296fb@github.com>
 <fHztT09Z_JIq9JVtvI-zGxXeod2hd9uyxP3Y7-6SAUo=.fd5a6971-274b-4969-a5ee-bacec4e5bbb9@github.com>
Message-ID: <OX_57jdbwWi7r1eTelim-rEzme-amJv7aT9-Ytgfmos=.8795af33-bea9-440a-97fc-860766699001@github.com>

On Fri, 11 Apr 2025 13:56:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find her a patch that deprecate networking permission classes for removal. The method `URL::getPermission` now serves little  purpose and is also deprecated. That method was overridden in subclasses and specified to return some of the deprecated permissions.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback. Deprecate getPermission for removal.

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24592#pullrequestreview-2760802017

From alanb at openjdk.org  Sat Apr 12 05:51:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 12 Apr 2025 05:51:33 GMT
Subject: RFR: 8343157: Examine large files for character encoding/decoding
In-Reply-To: <k9cqhVlXhsouupBsTJqjibR8LrQuH8LwB3LElvbFHn0=.51e125bf-8e7c-40d3-9fed-338b8e32e1d3@github.com>
References: <k9cqhVlXhsouupBsTJqjibR8LrQuH8LwB3LElvbFHn0=.51e125bf-8e7c-40d3-9fed-338b8e32e1d3@github.com>
Message-ID: <DiV_0kWa3kuQzdh_OaiMs2-4vdShXD-0IlQzMaesYXc=.8cc70396-1d24-4411-8015-dfa14ebe0fe3@github.com>

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing old charset test cases that verify new charset implementations (as of JDK7). Removed tests/files are actual charset implementations used in pre-JDK7, which have been used for comparing the results. Since those "new" implementations have been used since then, I believe it is OK to retire those old test cases.

Okay to delete, no real value keeping these.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24597#pullrequestreview-2762069633

From dfuchs at openjdk.org  Mon Apr 14 14:24:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 14 Apr 2025 14:24:51 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
Message-ID: <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>

On Thu, 10 Apr 2025 21:26:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

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

src/java.base/share/classes/java/net/NetworkInterface.java line 329:

> 327:         } else {
> 328:             throw new IllegalArgumentException(
> 329:                 formatMsg("invalid address type%s", filterNetInfo(addr.toString()).prefixWith(": ")));

OK - I see that `addr` cannot be null if we reach here.

src/java.base/share/classes/java/net/Proxy.java line 101:

> 99:             throw new IllegalArgumentException(
> 100:                 formatMsg("type " + type + " is not compatible with address %s",
> 101:                           filterNetInfo(sa.toString())

You will get NullPointerException instead of IllegalArgumentException if `sa` is `null`. I suggest using `String.valueOf(sa)` rather than `sa.toString()` to preserve the pre-existing behaviour.

src/java.base/share/classes/java/net/Proxy.java line 102:

> 100:                 formatMsg("type " + type + " is not compatible with address %s",
> 101:                           filterNetInfo(sa.toString())
> 102:                                .replaceWith("type " + sa.getClass().toString())));

You will have to guard against sa == null here

src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:

> 251: 
> 252:         int i = 0;
> 253:         boolean enhanced = true;

`enhanced` doesn't seem to be used here. Is this some leftover?

src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 203:

> 201:                 throw new NullPointerException(
> 202:                     formatMsg("malformed context url%s : no !/",
> 203:                               filterJarName(url.toString()).prefixWith(": ")));

It's not clear whether `url` could be `null` here, so to sidestep the question maybe use `String::valueOf` rather than `Object::toString`.

src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java line 212:

> 210:                 throw new NullPointerException(
> 211:                     formatMsg("malformed context url%s",
> 212:                               filterJarName(url.toString()).prefixWith(": ")));

Same remark here

test/jdk/java/net/URI/Test.java line 29:

> 27:  *      7171415 6339649 6933879 8037396 8272072 8051627 8297687
> 28:  * @author Mark Reinhold
> 29:  * @run main/othervm -Djdk.includeInExceptions=hostInfo Test

This change does not look like it's needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042182598
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042187411
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042190019
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042199577
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042214144
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042215273
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2042244694

From isipka at openjdk.org  Mon Apr 14 14:43:14 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Mon, 14 Apr 2025 14:43:14 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
Message-ID: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>

review to facilitate visibility on changes prior to testing @bwhuang-us

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

Commit messages:
 - trailing whitespace fix
 - trailing whitespace fix
 - all OS architectures are treated equally

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

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

From naoto at openjdk.org  Mon Apr 14 16:12:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Apr 2025 16:12:47 GMT
Subject: RFR: 8343157: Examine large files for character encoding/decoding
In-Reply-To: <k9cqhVlXhsouupBsTJqjibR8LrQuH8LwB3LElvbFHn0=.51e125bf-8e7c-40d3-9fed-338b8e32e1d3@github.com>
References: <k9cqhVlXhsouupBsTJqjibR8LrQuH8LwB3LElvbFHn0=.51e125bf-8e7c-40d3-9fed-338b8e32e1d3@github.com>
Message-ID: <o_cJCL718L6xDFjNRyomSmKEOodUYwb7Xldv_rNg6Pc=.2b453617-efc4-4ca3-8a97-16a46d03a947@github.com>

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing old charset test cases that verify new charset implementations (as of JDK7). Removed tests/files are actual charset implementations used in pre-JDK7, which have been used for comparing the results. Since those "new" implementations have been used since then, I believe it is OK to retire those old test cases.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24597#issuecomment-2802205991

From naoto at openjdk.org  Mon Apr 14 16:12:47 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Apr 2025 16:12:47 GMT
Subject: Integrated: 8343157: Examine large files for character
 encoding/decoding
In-Reply-To: <k9cqhVlXhsouupBsTJqjibR8LrQuH8LwB3LElvbFHn0=.51e125bf-8e7c-40d3-9fed-338b8e32e1d3@github.com>
References: <k9cqhVlXhsouupBsTJqjibR8LrQuH8LwB3LElvbFHn0=.51e125bf-8e7c-40d3-9fed-338b8e32e1d3@github.com>
Message-ID: <drxQVLugU8IuhoNPf3WEH2momEjr0nmkauWj644DZeM=.6d223c34-5594-4bc3-90ae-57d9b20645f2@github.com>

On Fri, 11 Apr 2025 17:02:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing old charset test cases that verify new charset implementations (as of JDK7). Removed tests/files are actual charset implementations used in pre-JDK7, which have been used for comparing the results. Since those "new" implementations have been used since then, I believe it is OK to retire those old test cases.

This pull request has now been integrated.

Changeset: d748bb5c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d748bb5cbb983fb07ae28e3a1c194058b73ef652
Stats:     164679 lines in 55 files changed: 0 ins; 164677 del; 2 mod

8343157: Examine large files for character encoding/decoding

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Mon Apr 14 23:52:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Apr 2025 23:52:54 GMT
Subject: RFR: 8353923: (fs) Further improve performance of URI -> Path
 conversion (win)
Message-ID: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>

If the path portion of a `URI` permits, then simply replace all `'\'` with `'/'` instead of completely parsing the path.

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

Commit messages:
 - 8353923: (fs) Further improve performance of URI -> Path conversion (win)

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

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

From bpb at openjdk.org  Tue Apr 15 00:01:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Apr 2025 00:01:51 GMT
Subject: RFR: 8353923: (fs) Further improve performance of URI -> Path
 conversion (win)
In-Reply-To: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
References: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
Message-ID: <ArBAax86CCOBU5I7gTXfvfOflPGgD8KUqgifudG2qc8=.5d28814c-e0b3-4091-9df0-5666c4784930@github.com>

On Mon, 14 Apr 2025 23:48:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If the path portion of a `URI` permits, then simply replace all `'\'` with `'/'` instead of completely parsing the path.

Benchmark testing of URI-to-Path conversion on Windows gives these results:

| URI | Throughput Change (%) |
| ---- | --------------------- |
| file:/C:/Users/bpb/git/foo/bar/classes/gus/dir/  | +63.96 |
| file:/C:/Users/bpb/git/foo/bar/classes/gus/dir   | +61.19 |
| file:/C:/Users/bpb/git/foo/bar/classes//gus/dir/ |  -4.19 |
| file:/C:/Users/bpb/git/foo/bar/classes//gus/dir  |  -2.21 |

For URIs having a path to which the optimization applies, the throughput increase is nearly two-thirds. For URIs which are not so amenable, there is a small throughput decrease of less than 5%. URIs which have a UNC path component are not affected.

So the question is whether a substantial throughput increase for susceptible absolute drive paths is worth a small but non-zero throughput decrease for other path components.

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

PR Comment: https://git.openjdk.org/jdk/pull/24638#issuecomment-2803357971

From michaelm at openjdk.org  Tue Apr 15 11:10:49 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 11:10:49 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
 <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
Message-ID: <4T-aEuL5RC4ragkopv7afbUBA3NT9efLxcG6EZGCJ8o=.65b066df-bc22-4df5-a7b8-c09b8e7515f7@github.com>

On Mon, 14 Apr 2025 13:51:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to minimise code changes
>
> src/java.base/share/classes/java/net/Proxy.java line 102:
> 
>> 100:                 formatMsg("type " + type + " is not compatible with address %s",
>> 101:                           filterNetInfo(sa.toString())
>> 102:                                .replaceWith("type " + sa.getClass().toString())));
> 
> You will have to guard against sa == null here

The `replaceWith()` call is actually not needed at all. I will remove it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044273655

From mchhipa at openjdk.org  Tue Apr 15 11:13:58 2025
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 15 Apr 2025 11:13:58 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <o-h57EYN4plH-O8fxGBdDUcaR3wq4EZmC0fFPyFHXcE=.7d59d99a-caf3-41ab-bef1-60a7c9116d4a@github.com>

On Thu, 3 Apr 2025 14:48:41 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

Update the copy right year.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2804688979

From michaelm at openjdk.org  Tue Apr 15 11:24:47 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 11:24:47 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v5]
In-Reply-To: <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <evQFtSXigIxNlqyJ1A6Ccstq72rWq5Uet-kjLGsGcUY=.a552c896-9e19-48b9-a3e8-cbbfa0e1e482@github.com>
 <uCd68Vee5NOCPBEX9OtIf8mdx4-OZzgO3PDWRq1qnNI=.0188887e-bddd-4281-8114-894c0575d07e@github.com>
Message-ID: <5ovW0BNN592wq1AFeHxH0QsrKk-hDXqCtGHgwRJ6StU=.ab9fa83f-27a7-485f-b586-4b1572329694@github.com>

On Mon, 14 Apr 2025 14:20:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to minimise code changes
>
> test/jdk/java/net/URI/Test.java line 29:
> 
>> 27:  *      7171415 6339649 6933879 8037396 8272072 8051627 8297687
>> 28:  * @author Mark Reinhold
>> 29:  * @run main/othervm -Djdk.includeInExceptions=hostInfo Test
> 
> This change does not look like it's needed.

Thanks for the review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r2044297016

From adinn at openjdk.org  Tue Apr 15 13:12:46 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 15 Apr 2025 13:12:46 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <fRoXRTHJlqZFrQFqTbng5_JKhlauPgYS_rGuZq5n6Po=.ec878fca-ea31-4bc6-81d3-227056be952c@github.com>

On Thu, 3 Apr 2025 14:48:41 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

I'm not sure if this change is correct. The original directive was ignored and replaced with an x86_64-only directive because of automated testing concerns documented in [PR 12352](https://github.com/openjdk/jdk/pull/12352). If this change is happening because those automated test restrictions no longer apply for all three of amd64 (by  which I mean not intel x86_64) aarch64 and ppc then reverting to the ignored directive would be fine. If the only change is that automated testing on amd64 now works as well as x86_64 then I would recommend modifying the first directive and keeping the ignored directive as the latter helps to clarify to general users how non-automated testing can be performed on aarch64 and ppc.

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

PR Review: https://git.openjdk.org/jdk/pull/24416#pullrequestreview-2768213569

From alanb at openjdk.org  Tue Apr 15 14:25:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Apr 2025 14:25:46 GMT
Subject: RFR: 8353923: (fs) Further improve performance of URI -> Path
 conversion (win)
In-Reply-To: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
References: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
Message-ID: <EbOzLtzQxyuGwG_gPmfd1KzEO1DbDi93PrK2029ykZY=.38cbce31-87fc-43c5-be5e-b14b919a3bf6@github.com>

On Mon, 14 Apr 2025 23:48:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If the path portion of a `URI` permits, then simply replace all `'\'` with `'/'` instead of completely parsing the path.

Is it possible to add a JMH benchmark to the PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/24638#issuecomment-2805401251

From michaelm at openjdk.org  Tue Apr 15 14:35:28 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 15 Apr 2025 14:35:28 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>

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

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

 - review update
 - Merge branch 'master' into 8348986-exceptions
 - update to minimise code changes
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   from turbanoff review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - doc + copyright update
 - remove file added by mistake
 - whitespace
 - moved test
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c

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

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=05
  Stats: 948 lines in 42 files changed: 715 ins; 101 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

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

From dfuchs at openjdk.org  Tue Apr 15 15:08:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Apr 2025 15:08:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v6]
In-Reply-To: <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <_RtwTSEJW4kr0WOiLRIp3oc8CbpaMjIe2u5xjfYJIH0=.87e0cd7f-7e46-4b2c-9b30-60a7758f1ee2@github.com>
Message-ID: <Z3Ao6frnA2TZMU05fCAUC_tCOdGf9jtA3VO-8_6L8qY=.c314bc04-70fd-4986-8c6d-359c6e8a1764@github.com>

On Tue, 15 Apr 2025 14:35:28 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - review update
>  - Merge branch 'master' into 8348986-exceptions
>  - update to minimise code changes
>  - Merge branch 'master' into 8348986-exceptions
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    from turbanoff review
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - doc + copyright update
>  - remove file added by mistake
>  - whitespace
>  - moved test
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b7837843...da33863c

Marked as reviewed by dfuchs (Reviewer).

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

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

From bpb at openjdk.org  Tue Apr 15 15:25:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Apr 2025 15:25:40 GMT
Subject: RFR: 8353923: (fs) Further improve performance of URI -> Path
 conversion (win)
In-Reply-To: <EbOzLtzQxyuGwG_gPmfd1KzEO1DbDi93PrK2029ykZY=.38cbce31-87fc-43c5-be5e-b14b919a3bf6@github.com>
References: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
 <EbOzLtzQxyuGwG_gPmfd1KzEO1DbDi93PrK2029ykZY=.38cbce31-87fc-43c5-be5e-b14b919a3bf6@github.com>
Message-ID: <xs_5CfBUXLGeESadmkQ_aE7OHL7x7u3_UzNoZ7rdydw=.10b70869-3507-49d0-b525-9983320aec08@github.com>

On Tue, 15 Apr 2025 14:23:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is it possible to add a JMH benchmark to the PR?

Yes, I was intending to do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/24638#issuecomment-2806179488

From msheppar at openjdk.org  Tue Apr 15 16:24:43 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 15 Apr 2025 16:24:43 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <4ZBBW-YJlnEPdKPztUw-rVUcat5mcOMx_d_Y72RDmNU=.fdf74676-a172-46d0-be93-e49d93c741e3@github.com>

On Thu, 3 Apr 2025 14:48:41 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

I would prefer if we retained the current test structure and swap
 the x86_64 with amd64, as amd64 is the os.arch on which the test will be run

Change 

 80 /* @test
 81  * @summary Testing NVRAM mapped byte buffer support
 82  * @run main/manual PmemTest
 83  * @requires (os.family == "linux")
 84  * @requires (os.arch == "x86_64")
 85  */
 86 
 87 /* @test
 88  * @summary Testing NVRAM mapped byte buffer support
 89  * @run main/manual PmemTest
 90  * @requires (os.family == "linux")
 91  * @requires ((os.arch == "amd64")|(os.arch == "aarch64")|(os.arch == "ppc64le"))
 92  * @ignore The test described here is currently disabled on systems that are not
 93  * x64-based and lack an external NVRAM memory device. In order to re-enable the
 94  * test, you will need to mount the NVRAM device, which will typically appear as
 95  * /dev/pmem0, to the directory /mnt/pmem. Once that is done, you can follow the
 96  * instructions above to create a test directory and remove the ignore tag.
 97  */

To  the preferred change i.e. to swap the x86_64 and amd64 and to use

80 /* @test
 81  * @summary Testing NVRAM mapped byte buffer support
 82  * @run main/manual PmemTest
 83  * @requires (os.family == "linux")
 84  * @requires (os.arch == ?amd64?)
 85  */

 
 91  * @requires ((os.arch == ?x86_64?)|(os.arch == "aarch64")|(os.arch == "ppc64le"))
 92  * @ignore The test described here is currently disabled on systems that are not

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2806732665

From rriggs at openjdk.org  Tue Apr 15 20:49:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Apr 2025 20:49:51 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

src/java.base/share/classes/java/lang/CharSequence.java line 338:

> 336:      * Concurrent truncation of this character sequence can throw
> 337:      * {@code IndexOutOfBoundsException}. In this case, some characters, but not
> 338:      * all, may be already transferred.

Though its been absent for decades, it might be worthwhile to include a class level warning that the implementations of the interface are not known or required to be thread safe and if used concurrently by multiple threads the behavior is unpredictable.  I'd be more circumspect than trying to specify the only aberrant behavior is IndexOutOfBounds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2045454429

From bpb at openjdk.org  Wed Apr 16 00:41:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Apr 2025 00:41:11 GMT
Subject: RFR: 8353923: (fs) Further improve performance of URI -> Path
 conversion (win) [v2]
In-Reply-To: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
References: <MUnXY904Dt4rxSW4Wi9cuZofiFUqdZ2qjijBNuTULio=.770965c9-e1f9-4649-8cd0-51e3b8768e0f@github.com>
Message-ID: <uHsMFye_O_JtbwmHo10eUA6h2DSBFB636Ti_G8KJWCo=.da2dacda-7370-4fdb-a7ac-b5d9c51da26b@github.com>

> If the path portion of a `URI` permits, then simply replace all `'\'` with `'/'` instead of completely parsing the path.

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

  8353923: Add PathOfURI benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24638/files
  - new: https://git.openjdk.org/jdk/pull/24638/files/3bd3e2a9..325abb62

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

  Stats: 47 lines in 2 files changed: 45 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/24638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24638/head:pull/24638

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

From adinn at openjdk.org  Wed Apr 16 10:35:43 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 16 Apr 2025 10:35:43 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <4ZBBW-YJlnEPdKPztUw-rVUcat5mcOMx_d_Y72RDmNU=.fdf74676-a172-46d0-be93-e49d93c741e3@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <4ZBBW-YJlnEPdKPztUw-rVUcat5mcOMx_d_Y72RDmNU=.fdf74676-a172-46d0-be93-e49d93c741e3@github.com>
Message-ID: <knhpgjbqpbTt8_wCfBY7-PzqfOVd0iZlIF4AwdRJ4qI=.5507d497-a5de-43ce-9655-61847515222f@github.com>

On Tue, 15 Apr 2025 16:22:11 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> It would be preferable if we retained the current test structure and swap
the x86_64 with amd64, as amd64 is the os.arch on which the test will be run

When I wrote my previous comment I was under the impression that `@requires(os.arch == "x86_64")` selects Intel x86 64-bit only while `@requires(os.arch == "amd64")` selects either Intel x86 64-bit or AMD x86 64-bit. However, having looked through the code in files:

test/jdk/jdk/internal/util/ArchTest.java
src/java.base/share/classes/jdk/internal/util/Architecture.java
src/java.base/share/classes/jdk/internal/util/PlatformProps.java
/make/modules/java.base/gensrc/GensrcMisc.gmk

it appears to me that these two `@requires` clauses select the same thing i.e. either Intel x86 64-bit or AMD x86 64-bit. In which case the current config should mean that this test will run on AMD CPUs. Is that not the case?

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2809158221

From duke at openjdk.org  Wed Apr 16 10:37:51 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 10:37:51 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>
Message-ID: <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>

On Tue, 15 Apr 2025 20:46:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'
>
> src/java.base/share/classes/java/lang/CharSequence.java line 338:
> 
>> 336:      * Concurrent truncation of this character sequence can throw
>> 337:      * {@code IndexOutOfBoundsException}. In this case, some characters, but not
>> 338:      * all, may be already transferred.
> 
> Though its been absent for decades, it might be worthwhile to include a class level warning that the implementations of the interface are not known or required to be thread safe and if used concurrently by multiple threads the behavior is unpredictable.  I'd be more circumspect than trying to specify the only aberrant behavior is IndexOutOfBounds.

Any quick proposals how to rephrase JavaDocs and CSR? As the CSR is already reviewed I am a bit reluctant to hold the train for this, as IMHO *masses* of classes and interfaces would need such a disclaimer, if we kick-off that ball here...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2046642887

From msheppar at openjdk.org  Wed Apr 16 10:38:41 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Apr 2025 10:38:41 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <fRoXRTHJlqZFrQFqTbng5_JKhlauPgYS_rGuZq5n6Po=.ec878fca-ea31-4bc6-81d3-227056be952c@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <fRoXRTHJlqZFrQFqTbng5_JKhlauPgYS_rGuZq5n6Po=.ec878fca-ea31-4bc6-81d3-227056be952c@github.com>
Message-ID: <rWIyNjgNwSCmH0J-QZby-uO7aYgSHA_s-K40B9UDZFA=.ba0ae82e-ac47-42ac-ba0b-fdd07c524d62@github.com>

On Tue, 15 Apr 2025 13:09:50 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> I'm not sure if this change is correct. The original directive was ignored and replaced with an x86_64-only directive because of automated testing concerns documented in [PR 12352](https://github.com/openjdk/jdk/pull/12352). If this change is happening because those automated test restrictions no longer apply for all three of amd64 (by which I mean not intel x86_64) aarch64 and ppc then reverting to the ignored directive would be fine. If the only change is that automated testing on amd64 now works as well as x86_64 then I would recommend modifying the first directive and keeping the ignored directive as the latter helps to clarify to general users how non-automated testing can be performed on aarch64 and ppc.

just to clarify that both instances  of @test  are **manual** and that current test environments are os.arch == "amd64", which based on the default  os.arch == "x86_64" meant the test was not run. As such, the purpose of the ticket is to make the default case "amd64"

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2809164778

From alanb at openjdk.org  Wed Apr 16 10:44:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Apr 2025 10:44:50 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
Message-ID: <lSXXcakkANiBkkvAic1ltq7w3PoU561-DugjzOkotQE=.54bb826d-d8d2-4df2-9529-fc6d656868dd@github.com>

On Wed, 16 Apr 2025 10:35:10 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 338:
>> 
>>> 336:      * Concurrent truncation of this character sequence can throw
>>> 337:      * {@code IndexOutOfBoundsException}. In this case, some characters, but not
>>> 338:      * all, may be already transferred.
>> 
>> Though its been absent for decades, it might be worthwhile to include a class level warning that the implementations of the interface are not known or required to be thread safe and if used concurrently by multiple threads the behavior is unpredictable.  I'd be more circumspect than trying to specify the only aberrant behavior is IndexOutOfBounds.
>
> Any quick proposals how to rephrase JavaDocs and CSR? As the CSR is already reviewed I am a bit reluctant to hold the train for this, as IMHO *masses* of classes and interfaces would need such a disclaimer, if we kick-off that ball here...

I think Roger's suggestion is for a different JBS issue / PR / CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2046653580

From msheppar at openjdk.org  Wed Apr 16 11:12:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Apr 2025 11:12:52 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <knhpgjbqpbTt8_wCfBY7-PzqfOVd0iZlIF4AwdRJ4qI=.5507d497-a5de-43ce-9655-61847515222f@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <4ZBBW-YJlnEPdKPztUw-rVUcat5mcOMx_d_Y72RDmNU=.fdf74676-a172-46d0-be93-e49d93c741e3@github.com>
 <knhpgjbqpbTt8_wCfBY7-PzqfOVd0iZlIF4AwdRJ4qI=.5507d497-a5de-43ce-9655-61847515222f@github.com>
Message-ID: <Hk6fgneQyqnCnxtHa3fWEqhqGh5O00vmPRaXW8Y5wPw=.0e5c9ea9-ab64-43e3-8c58-5a8f4965fdc4@github.com>

On Wed, 16 Apr 2025 10:33:31 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> > It would be preferable if we retained the current test structure and swap
> > the x86_64 with amd64, as amd64 is the os.arch on which the test will be run
> 
> When I wrote my previous comment I was under the impression that `@requires(os.arch == "x86_64")` selects Intel x86 64-bit only while `@requires(os.arch == "amd64")` selects either Intel x86 64-bit or AMD x86 64-bit. However, having looked through the code in files:
> 
> ```
> test/jdk/jdk/internal/util/ArchTest.java
> src/java.base/share/classes/jdk/internal/util/Architecture.java
> src/java.base/share/classes/jdk/internal/util/PlatformProps.java
> /make/modules/java.base/gensrc/GensrcMisc.gmk
> ```
> 
> it appears to me that these two `@requires` clauses select the same thing i.e. either Intel x86 64-bit or AMD x86 64-bit. In which case the current config should mean that this test will run on AMD CPUs. Is that not the case?

Thanks for the details above. Currently the main linux execution platforms are returning "amd64" for the OS arch,  and that is not picked up by the current   @requires (os.arch == "x86_64")
so this is a pragmatic change to facilitate the manual execution of the most prevalent test environments.

It was observed that there might be a separate issue for jtreg on the @requires and
based on your feedback, and expectations there is a separate jtreg  issue to investigate the consistency of @requires on the os.arch attribute.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2809243922

From adinn at openjdk.org  Wed Apr 16 12:16:55 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 16 Apr 2025 12:16:55 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <Hk6fgneQyqnCnxtHa3fWEqhqGh5O00vmPRaXW8Y5wPw=.0e5c9ea9-ab64-43e3-8c58-5a8f4965fdc4@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <4ZBBW-YJlnEPdKPztUw-rVUcat5mcOMx_d_Y72RDmNU=.fdf74676-a172-46d0-be93-e49d93c741e3@github.com>
 <knhpgjbqpbTt8_wCfBY7-PzqfOVd0iZlIF4AwdRJ4qI=.5507d497-a5de-43ce-9655-61847515222f@github.com>
 <Hk6fgneQyqnCnxtHa3fWEqhqGh5O00vmPRaXW8Y5wPw=.0e5c9ea9-ab64-43e3-8c58-5a8f4965fdc4@github.com>
Message-ID: <PMdUqbow7dX78No4uSHIiZDZcDM6Ab5VYI5WUUjLJoY=.6c493ced-af3d-484e-ae80-88cf477a3fc2@github.com>

On Wed, 16 Apr 2025 11:10:22 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>>> It would be preferable if we retained the current test structure and swap
>> the x86_64 with amd64, as amd64 is the os.arch on which the test will be run
>> 
>> When I wrote my previous comment I was under the impression that `@requires(os.arch == "x86_64")` selects Intel x86 64-bit only while `@requires(os.arch == "amd64")` selects either Intel x86 64-bit or AMD x86 64-bit. However, having looked through the code in files:
>> 
>> test/jdk/jdk/internal/util/ArchTest.java
>> src/java.base/share/classes/jdk/internal/util/Architecture.java
>> src/java.base/share/classes/jdk/internal/util/PlatformProps.java
>> /make/modules/java.base/gensrc/GensrcMisc.gmk
>> 
>> it appears to me that these two `@requires` clauses select the same thing i.e. either Intel x86 64-bit or AMD x86 64-bit. In which case the current config should mean that this test will run on AMD CPUs. Is that not the case?
>
>> > It would be preferable if we retained the current test structure and swap
>> > the x86_64 with amd64, as amd64 is the os.arch on which the test will be run
>> 
>> When I wrote my previous comment I was under the impression that `@requires(os.arch == "x86_64")` selects Intel x86 64-bit only while `@requires(os.arch == "amd64")` selects either Intel x86 64-bit or AMD x86 64-bit. However, having looked through the code in files:
>> 
>> ```
>> test/jdk/jdk/internal/util/ArchTest.java
>> src/java.base/share/classes/jdk/internal/util/Architecture.java
>> src/java.base/share/classes/jdk/internal/util/PlatformProps.java
>> /make/modules/java.base/gensrc/GensrcMisc.gmk
>> ```
>> 
>> it appears to me that these two `@requires` clauses select the same thing i.e. either Intel x86 64-bit or AMD x86 64-bit. In which case the current config should mean that this test will run on AMD CPUs. Is that not the case?
> 
> Thanks for the details above. Currently the main linux execution platforms are returning "amd64" for the OS arch,  and that is not picked up by the current   @requires (os.arch == "x86_64")
> to run on amd64 necessitates the removal of the @ignores directive 
> so this is a pragmatic change to facilitate the manual execution of the most prevalent amd64 test environments.
> 
> It was observed that there might be a separate issue for jtreg on the @requires and
> based on your feedback, and expectations there is a separate jtreg  issue to investigate the consistency of @requires on the os.arch attribute.

@msheppar Thanks for clarifying what is at stake here. I am afraid don't know enough about the mechanics of the test infrastructure to explain why it is working the way you describe. However, given what you have observed I agree with your suggestion above that the right solution is to keep the two test declarations but switch "amd64" for "x86_64" and vice versa. That should make the tests work on amd64 CPUs while leaving it clear how anyone wanting to test on an alternative CPU would need to modify the test. I'll be happy to review the PR if it includes that change.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2809394333

From liach at openjdk.org  Wed Apr 16 14:45:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 14:45:46 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <lSXXcakkANiBkkvAic1ltq7w3PoU561-DugjzOkotQE=.54bb826d-d8d2-4df2-9529-fc6d656868dd@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
 <lSXXcakkANiBkkvAic1ltq7w3PoU561-DugjzOkotQE=.54bb826d-d8d2-4df2-9529-fc6d656868dd@github.com>
Message-ID: <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>

On Wed, 16 Apr 2025 10:41:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Any quick proposals how to rephrase JavaDocs and CSR? As the CSR is already reviewed I am a bit reluctant to hold the train for this, as IMHO *masses* of classes and interfaces would need such a disclaimer, if we kick-off that ball here...
>
> I think Roger's suggestion is for a different JBS issue / PR / CSR.

Yeah, we already added this API to allow implementations to be more consistent under race condition. So for changing char sequences, this method's default implementation can throw IOOBE, but it is already specified so it is well-behaved even under race (as you can argue a read observed the shorter state of the CS that causes the failure)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047095624

From rriggs at openjdk.org  Wed Apr 16 15:02:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Apr 2025 15:02:45 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
 <lSXXcakkANiBkkvAic1ltq7w3PoU561-DugjzOkotQE=.54bb826d-d8d2-4df2-9529-fc6d656868dd@github.com>
 <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>
Message-ID: <cOEW2s_rw5J-fQdRaTEMB5VGJwQeulMSMx34YrbGeKU=.7e130c51-5936-4c9e-9528-1d26898976f6@github.com>

On Wed, 16 Apr 2025 14:42:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I think Roger's suggestion is for a different JBS issue / PR / CSR.
>
> Yeah, we already added this API to allow implementations to be more consistent under race condition. So for changing char sequences, this method's default implementation can throw IOOBE, but it is already specified so it is well-behaved even under race (as you can argue a read observed the shorter state of the CS that causes the failure)

Omitting it is fine, it was just a reminder that an interface cannot make any definitive statements about its implementations and sometime should warn the unwary user. (We all expect them to adhere to the contract described in each method, but who knows.)
The statement in the implSpec is fine as it only applies to the default implementation, but can be mis-read and thought to apply to all implementations. YMMV.
And though I see consensus, I don't see any approvals yet, including the CSR.
Its good to see it settle down and make progress.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047135826

From liach at openjdk.org  Wed Apr 16 15:59:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 15:59:48 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <ZAaLzNUf-tJobqAH4YWU6hfvmBTuQl4FKEpgU9YM58M=.3cf04674-a6e2-4038-9d55-ebb179640419@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

The implementation looks good. Do you think we need some unit tests for this new API, especially against the default implementation?

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810022443

From duke at openjdk.org  Wed Apr 16 15:59:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 15:59:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <EluzwxDtISEzmqscGlb_cA-20wDNET_V2ns4H7htK1k=.0d07bff5-6226-4aa1-b2a3-ef29b112cffe@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

IMHO the existing `Reader.of()` tests do cover all implementations already.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810027377

From liach at openjdk.org  Wed Apr 16 16:06:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Apr 2025 16:06:59 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <DZjtiWFRPnrTBJx3WFkOmY5Xpkoz3_HtJv_zmkmli3c=.37079f6c-85c2-4b2d-a3ba-8b20b781c407@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

Relying on another user is not a good practice - it is possible that we switch `Reader.of` to another implementation. The tests can be as simple as copying the `Reader.of` tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810046366

From jpai at openjdk.org  Wed Apr 16 16:12:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 16:12:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <XRxJ-Q0hCZtOpz-CzWhIZsfiYxw4YhbD8YloGUiAHM8=.9434206d-bd3e-4357-9aad-c3e841203dd1@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

src/java.base/share/classes/java/lang/CharSequence.java line 342:

> 340:      * @since 25
> 341:      */
> 342:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {

Hello Markus, given these new methods on `CharSequence` and the `CharBuffer`, we should add a jtreg test to verify that the default implementation of these methods do work as specified. 

Edit: I now see Chen too had a similar comment about adding a regression test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047263593

From duke at openjdk.org  Wed Apr 16 16:12:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 16:12:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <XRxJ-Q0hCZtOpz-CzWhIZsfiYxw4YhbD8YloGUiAHM8=.9434206d-bd3e-4357-9aad-c3e841203dd1@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <XRxJ-Q0hCZtOpz-CzWhIZsfiYxw4YhbD8YloGUiAHM8=.9434206d-bd3e-4357-9aad-c3e841203dd1@github.com>
Message-ID: <TENNt_7bfOZ4JEfEv5mUZOGpz3d_KgJbk46qwTaPHhc=.9e0b32cd-1d7f-4ff4-8a02-cb4b2dd54eae@github.com>

On Wed, 16 Apr 2025 16:08:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'
>
> src/java.base/share/classes/java/lang/CharSequence.java line 342:
> 
>> 340:      * @since 25
>> 341:      */
>> 342:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
> 
> Hello Markus, given these new methods on `CharSequence` and the `CharBuffer`, we should add a jtreg test to verify that the default implementation of these methods do work as specified. 
> 
> Edit: I now see Chen too had a similar comment about adding a regression test.

This is already discussed in a separate thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2047265794

From duke at openjdk.org  Wed Apr 16 16:12:57 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 16:12:57 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <XkEEeIDqTw3JUadRO2XlSlTiJbYnuq3ZJXIYP4a9L8k=.f900bee1-f12a-4b85-b74d-26cc7265a2bd@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

Nevertheless, the tests are there, so no *new* ones are needed. We can duplicate them, if a majority thinks it is beneficial.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810057394

From jpai at openjdk.org  Wed Apr 16 16:31:59 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 16:31:59 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
Message-ID: <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>

On Sun, 30 Mar 2025 12:34:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen: 'We might need to specify the IOOBE behavior - when an IOOBE is thrown, some characters may be already transferred (this is important for concurrent char sequences)'

> Nevertheless, the tests are there, so no _new_ ones are needed. We can duplicate them, if a majority thinks it is beneficial.

As noted in the contribution guide (https://openjdk.org/guide/#testing-the-jdk), regression tests are expected for a majority of changes that are done in the JDK. There are situations where regressions tests cannot be added, but this isn't one. I believe a new method with a default specified implementation in a public exported interface deserves a regression test of its own.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810110015

From duke at openjdk.org  Wed Apr 16 16:36:02 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 16:36:02 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>
Message-ID: <J_bmOHLcwsg5b7566JHJYoP-EyCCu3ftKjZQ7yz09QA=.92cf1ed3-22c0-4bb4-9ad6-7eed47bc6fc0@github.com>

On Wed, 16 Apr 2025 16:29:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > Nevertheless, the tests are there, so no _new_ ones are needed. We can duplicate them, if a majority thinks it is beneficial.
> 
> As noted in the contribution guide (https://openjdk.org/guide/#testing-the-jdk), regression tests are expected for a majority of changes that are done in the JDK. There are situations where regressions tests cannot be added, but this isn't one. I believe a new method with a default specified implementation in a public exported interface deserves a regression test of its own.

The docs do not say that the regression test must be *separate*. Again: We *do have* testing covered. The question is *not* whether we need a test -we *do have one*-, but whether to *duplicate* it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810119199

From jpai at openjdk.org  Wed Apr 16 16:50:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 16:50:01 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <J_bmOHLcwsg5b7566JHJYoP-EyCCu3ftKjZQ7yz09QA=.92cf1ed3-22c0-4bb4-9ad6-7eed47bc6fc0@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>
 <J_bmOHLcwsg5b7566JHJYoP-EyCCu3ftKjZQ7yz09QA=.92cf1ed3-22c0-4bb4-9ad6-7eed47bc6fc0@github.com>
Message-ID: <TgO-qcQTq9gej6b26voBMG7PmeqeFO6I0gWKc6bDKgk=.b2260d40-08e8-4e8e-b00b-2f6f71e23cef@github.com>

On Wed, 16 Apr 2025 16:33:29 GMT, Markus KARG <duke at openjdk.org> wrote:

>  If duplication is wanted, I will do it. I am just waiting for a majority to clearly say that they want duplication.

By duplication, do you mean copy pasting the `testReadBII(Reader reader)`, `testReadBIILenZero(Reader reader)`, `testReadDirectCharBuffer(Reader reader)` and similar such test methods from the existing `test/jdk/java/io/Reader/Of.java` test class? Including all those references to the `Reader`?

Implementing a test that calls `Reader.of()` to verify the behaviour of an independent `CharSequence.getChars()` method isn't the kind of test I am proposing. It should be possible to just invoke `CharSequence.getChars()` on a `CharSequence` instance to verify that its default method does what it specifies. So these new tests won't be duplicating any existing test code.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810153917

From duke at openjdk.org  Wed Apr 16 17:01:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 16 Apr 2025 17:01:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <TgO-qcQTq9gej6b26voBMG7PmeqeFO6I0gWKc6bDKgk=.b2260d40-08e8-4e8e-b00b-2f6f71e23cef@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>
 <J_bmOHLcwsg5b7566JHJYoP-EyCCu3ftKjZQ7yz09QA=.92cf1ed3-22c0-4bb4-9ad6-7eed47bc6fc0@github.com>
 <TgO-qcQTq9gej6b26voBMG7PmeqeFO6I0gWKc6bDKgk=.b2260d40-08e8-4e8e-b00b-2f6f71e23cef@github.com>
Message-ID: <eGmrpOJQBktIHWQa55r2aKZcOYxUsBgxDQk8K1JuNGw=.17801fea-ada8-41be-a89e-78b7ac04f2c3@github.com>

On Wed, 16 Apr 2025 16:47:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>It should be possible to just invoke `CharSequence.getChars()` on a `CharSequence` instance to verify that its default method does what it specifies. So these new tests won't be duplicating any existing test code.

IIUC then you will be fine with a test that **solely** tests *the default implementation* of `CharSequence.getChars()`?

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810179689

From jpai at openjdk.org  Wed Apr 16 17:07:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Apr 2025 17:07:01 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <eGmrpOJQBktIHWQa55r2aKZcOYxUsBgxDQk8K1JuNGw=.17801fea-ada8-41be-a89e-78b7ac04f2c3@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>
 <J_bmOHLcwsg5b7566JHJYoP-EyCCu3ftKjZQ7yz09QA=.92cf1ed3-22c0-4bb4-9ad6-7eed47bc6fc0@github.com>
 <TgO-qcQTq9gej6b26voBMG7PmeqeFO6I0gWKc6bDKgk=.b2260d40-08e8-4e8e-b00b-2f6f71e23cef@github.com>
 <eGmrpOJQBktIHWQa55r2aKZcOYxUsBgxDQk8K1JuNGw=.17801fea-ada8-41be-a89e-78b7ac04f2c3@github.com>
Message-ID: <9BsFYz2RyshIdK1liYcrQdIiJMf5yuhajoVSZ8V5LUQ=.23bc0d84-4f72-41d2-b5d1-753bc12c4e22@github.com>

On Wed, 16 Apr 2025 16:58:50 GMT, Markus KARG <duke at openjdk.org> wrote:

> IIUC then you will be fine with a test that solely tests the default implementation of CharSequence.getChars()?

Correct. And a similar separate test for `CharBuffer.getChars()` since that one too is a new default implementation method. I apologize if that wasn't clear in the discussion so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2810190843

From isipka at openjdk.org  Thu Apr 17 11:53:44 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 17 Apr 2025 11:53:44 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <PMdUqbow7dX78No4uSHIiZDZcDM6Ab5VYI5WUUjLJoY=.6c493ced-af3d-484e-ae80-88cf477a3fc2@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <4ZBBW-YJlnEPdKPztUw-rVUcat5mcOMx_d_Y72RDmNU=.fdf74676-a172-46d0-be93-e49d93c741e3@github.com>
 <knhpgjbqpbTt8_wCfBY7-PzqfOVd0iZlIF4AwdRJ4qI=.5507d497-a5de-43ce-9655-61847515222f@github.com>
 <Hk6fgneQyqnCnxtHa3fWEqhqGh5O00vmPRaXW8Y5wPw=.0e5c9ea9-ab64-43e3-8c58-5a8f4965fdc4@github.com>
 <PMdUqbow7dX78No4uSHIiZDZcDM6Ab5VYI5WUUjLJoY=.6c493ced-af3d-484e-ae80-88cf477a3fc2@github.com>
Message-ID: <TFxvAjt9QL6c1MdvoR-40vLNIXCb-nDNHtAvQX3xBGc=.88ae3f5c-a66d-48c4-b9ea-b4a9a36616c1@github.com>

On Wed, 16 Apr 2025 12:13:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> > It would be preferable if we retained the current test structure and swap
>>> > the x86_64 with amd64, as amd64 is the os.arch on which the test will be run
>>> 
>>> When I wrote my previous comment I was under the impression that `@requires(os.arch == "x86_64")` selects Intel x86 64-bit only while `@requires(os.arch == "amd64")` selects either Intel x86 64-bit or AMD x86 64-bit. However, having looked through the code in files:
>>> 
>>> ```
>>> test/jdk/jdk/internal/util/ArchTest.java
>>> src/java.base/share/classes/jdk/internal/util/Architecture.java
>>> src/java.base/share/classes/jdk/internal/util/PlatformProps.java
>>> /make/modules/java.base/gensrc/GensrcMisc.gmk
>>> ```
>>> 
>>> it appears to me that these two `@requires` clauses select the same thing i.e. either Intel x86 64-bit or AMD x86 64-bit. In which case the current config should mean that this test will run on AMD CPUs. Is that not the case?
>> 
>> Thanks for the details above. Currently the main linux execution platforms are returning "amd64" for the OS arch,  and that is not picked up by the current   @requires (os.arch == "x86_64")
>> to run on amd64 necessitates the removal of the @ignores directive 
>> so this is a pragmatic change to facilitate the manual execution of the most prevalent amd64 test environments.
>> 
>> It was observed that there might be a separate issue for jtreg on the @requires and
>> based on your feedback, and expectations there is a separate jtreg  issue to investigate the consistency of @requires on the os.arch attribute.
>
> @msheppar Thanks for clarifying what is at stake here. I am afraid don't know enough about the mechanics of the test infrastructure to explain why it is working the way you describe. However, given what you have observed I agree with your suggestion above that the right solution is to keep the two test declarations but switch "amd64" for "x86_64" and vice versa. That should make the tests work on amd64 CPUs while leaving it clear how anyone wanting to test on an alternative CPU would need to modify the test. I'll be happy to review the PR if it includes that change.

@adinn thank you for pointing out the additional relevant tests, the `test/jdk/jdk/internal/util/ArchTest.java` one is pure gold!

@msheppar the issue on @requires directive consistency was suspected until the following observation was made on a machine with Intel Core i9 CPU (which is clearly x86_64 ISA) :
     
     $dpkg --print-architecture
     amd64
     $gcc -dumpmachine
     x86_64-linux-gnu
     $uname -m
     x86_64
     $arch
     x86_64
     
To the best of my understanding the jtreg @requires directive is based on platform-dependent `System.getProperty("os.arch")` which is, I am speculating, populated via flags set in build time and by querying system calls during JVM startup.

Furthermore, [Oracle JDK releases for Linux](https://www.oracle.com/java/technologies/downloads/) list only `aarch64` and `x64`  ISA's.

Based on these facts (the architecture test and the releases) it is reasonable to conclude that `x86_64` and `amd64` are equivalent  - as far as the JDK VM scope is concerned - researching the topic seems to point that there still are some exotic differences but namely regarding virtualization.

Hence, in the general case any test that depends on the architecture should list `x86_64` and `amd64` together as it is uncertain (platform implementation dependent) what the exact string will be, e.g.:
   
      @requires ((os.arch == "x86_64")|(os.arch == "amd64"))

If we are aiming specifically for mentioned test enviroment it can be `amd64` as we _know_ that is what is returned.

In the case we want to proceed with two test cases - I suggest to introduce human readable ids (jtreg @id tag) so that we dont see automatically assigned `#id0` and `#id1`.

Please advise.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2812620053

From msheppar at openjdk.org  Thu Apr 17 12:32:52 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 17 Apr 2025 12:32:52 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <f17sQTr1npZ3xaHE9FveL_S_KvffiO-eHa22BpsjsH0=.4d1d1dfe-7a5f-431f-8db1-4a8568379a20@github.com>

On Thu, 3 Apr 2025 14:48:41 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

changing the @requires in the main test to
 @requires ((os.arch == "x86_64")|(os.arch == "amd64"))

seems reasonable 

and adding an id to each of the test cases is a good idea

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2812719444

From isipka at openjdk.org  Thu Apr 17 14:40:56 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 17 Apr 2025 14:40:56 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v2]
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision:

 - removing accidentally added files, reverting to two test cases bu removing @ignores directive and adding test ids
 - copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24416/files
  - new: https://git.openjdk.org/jdk/pull/24416/files/f6822b82..eae29977

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

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

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

From isipka at openjdk.org  Thu Apr 17 14:46:42 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 17 Apr 2025 14:46:42 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v2]
In-Reply-To: <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>
Message-ID: <3LxqN8gv0EHI5bGJ6I7ZPiloS-_zKTNhZiu_Dj59KrU=.dba062e8-6525-4c13-ac85-201316415fee@github.com>

On Thu, 17 Apr 2025 14:40:56 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection
>
> Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removing accidentally added files, reverting to two test cases bu removing @ignores directive and adding test ids
>  - copyright update

changes:
 - removed @ignores tag

and split to two test cases:
  - `@requires ((os.arch == "x86_64")|(os.arch == "amd64"))` with id `default_architecture_test_case`
  - `@requires ((os.arch == "aarch64")|(os.arch == "ppc64le"))` with id `other_architectures_test_case`
  
  local test shows that requires directive resolves properly as well as the test id is applied
  
    jtreg -version
    jtreg 7.6+1-12
    Installed in /home/isipka/apps/jtreg/jtreg-7.6+1/lib/jtreg.jar
    Running on platform version 25-ea from /home/isipka/.sdkman/candidates/java/25.ea.9-open.
    Built with Java(TM) 2 SDK, Version 11.0.16+11-LTS-199 on February 06, 2025.
    Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved.
    Use is subject to license terms.
    JT Harness, version 6.0 ea b24 (September 27, 2022)
    Java Assembler Tools, version 7.0 ea b09 (June 04, 2020)
    TestNG: testng-7.3.0.jar, jcommander-1.82.jar, guice-5.1.0.jar
      JUnit: junit-platform-console-standalone-1.11.0.jar
      
      jtreg -verbose:esa java/nio/MappedByteBuffer/PmemTest.java
      failed to get value for jdk.static
      java.lang.UnsatisfiedLinkError: 'boolean jdk.test.whitebox.WhiteBox.isStatic()'
	      at jdk.test.whitebox.WhiteBox.isStatic(Native Method)
	      at requires.VMProps.isStatic(VMProps.java:830)
	      at requires.VMProps$SafeMap.put(VMProps.java:82)
	      at requires.VMProps.call(VMProps.java:145)
	      at requires.VMProps.call(VMProps.java:67)
	      at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:80)
	      at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)
      runner starting test: java/nio/MappedByteBuffer/PmemTest.java#default_architecture_test_case
      runner finished test: java/nio/MappedByteBuffer/PmemTest.java#default_architecture_test_case
      Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /mnt/pmem/test/pmemtest
      Test results: failed: 1; did not meet platform requirements: 1
      Report written to /home/isipka/workspace/jdk/open/test/jdk/JTreport/html/report.html
      Results written to /home/isipka/workspace/jdk/open/test/jdk/JTwork
      Error: Some tests failed or other problems occurred.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2813184298

From msheppar at openjdk.org  Thu Apr 17 14:57:43 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 17 Apr 2025 14:57:43 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v2]
In-Reply-To: <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>
Message-ID: <ktAH20IjmdL9inGXFm8uhVwnRGfxdAlmJPZICco_a9g=.3ed8a5a0-a77e-4685-8252-65578bc8bda8@github.com>

On Thu, 17 Apr 2025 14:40:56 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection
>
> Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removing accidentally added files, reverting to two test cases bu removing @ignores directive and adding test ids
>  - copyright update

test/jdk/java/nio/MappedByteBuffer/PmemTest.java line 87:

> 85:  */
> 86: 
> 87: /* @test id=other_architectures_test_case

we should to leave the @ignores for the 2nd test case 
the test will be run on amd64 environmenst , as such the addition of  | (os.arch == "amd64") to the first test case  is fine

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24416#discussion_r2049132553

From isipka at openjdk.org  Thu Apr 17 15:07:16 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 17 Apr 2025 15:07:16 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v2]
In-Reply-To: <ktAH20IjmdL9inGXFm8uhVwnRGfxdAlmJPZICco_a9g=.3ed8a5a0-a77e-4685-8252-65578bc8bda8@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>
 <ktAH20IjmdL9inGXFm8uhVwnRGfxdAlmJPZICco_a9g=.3ed8a5a0-a77e-4685-8252-65578bc8bda8@github.com>
Message-ID: <dt6Fq_JKeeUg2wDvGMDBgfhDuXeyZY9SlM7tMIh5yf0=.270799a3-a22a-4fe2-8cc3-bbb04102bf78@github.com>

On Thu, 17 Apr 2025 14:54:37 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Ivan ?ipka has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - removing accidentally added files, reverting to two test cases bu removing @ignores directive and adding test ids
>>  - copyright update
>
> test/jdk/java/nio/MappedByteBuffer/PmemTest.java line 87:
> 
>> 85:  */
>> 86: 
>> 87: /* @test id=other_architectures_test_case
> 
> we should to leave the @ignores for the 2nd test case 
> the test will be run on amd64 environmenst , as such the addition of  | (os.arch == "amd64") to the first test case  is fine

so just to confirm: we explitcitly want to ignore this test on `linux-aarch64` and `linux-ppc64le` regardless of is the required hardware present or not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24416#discussion_r2049152149

From msheppar at openjdk.org  Thu Apr 17 15:20:43 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 17 Apr 2025 15:20:43 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v2]
In-Reply-To: <dt6Fq_JKeeUg2wDvGMDBgfhDuXeyZY9SlM7tMIh5yf0=.270799a3-a22a-4fe2-8cc3-bbb04102bf78@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <qvzgsT-H5qTbafQFa2rNLuRnSxzL0cWouacHU2qnBqw=.bf2977a3-448e-49fc-a3d3-9749d039c759@github.com>
 <ktAH20IjmdL9inGXFm8uhVwnRGfxdAlmJPZICco_a9g=.3ed8a5a0-a77e-4685-8252-65578bc8bda8@github.com>
 <dt6Fq_JKeeUg2wDvGMDBgfhDuXeyZY9SlM7tMIh5yf0=.270799a3-a22a-4fe2-8cc3-bbb04102bf78@github.com>
Message-ID: <BbXseOMD1U0XvVzdn3SGJRxFaAtMv8st4RftYl8EBcs=.ffe60ffc-6aff-4ac0-a189-582dea5db9c2@github.com>

On Thu, 17 Apr 2025 15:04:05 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> test/jdk/java/nio/MappedByteBuffer/PmemTest.java line 87:
>> 
>>> 85:  */
>>> 86: 
>>> 87: /* @test id=other_architectures_test_case
>> 
>> we should to leave the @ignores for the 2nd test case 
>> the test will be run on amd64 environmenst , as such the addition of  | (os.arch == "amd64") to the first test case  is fine
>
> so just to confirm: we explitcitly want to ignore this test on `linux-aarch64` and `linux-ppc64le` regardless of is the required hardware present or not?

yes, retain the @ignore in the second test case.
The original aim of this issue is to change the default test case of os.arch == "x86_64" to os.arch == "amd64" as the test will by default be run in an amd64 environment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24416#discussion_r2049180807

From isipka at openjdk.org  Thu Apr 17 15:49:38 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 17 Apr 2025 15:49:38 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v3]
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

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

  retruning ignore directive to other_arch test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24416/files
  - new: https://git.openjdk.org/jdk/pull/24416/files/eae29977..59209dd4

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

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

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

From isipka at openjdk.org  Thu Apr 17 15:53:02 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Thu, 17 Apr 2025 15:53:02 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v3]
In-Reply-To: <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
Message-ID: <pOpFT2Obagr-Y8AiswSKMSRKYiBOwUAUg4esN-Sclgc=.3ee45ab6-6e8b-4929-bdf4-33b0798b9221@github.com>

On Thu, 17 Apr 2025 15:49:38 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection
>
> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retruning ignore directive to other_arch test case

jtreg -ignore:quiet -verbose:esa java/nio/MappedByteBuffer/PmemTest.java
      failed to get value for jdk.static
      java.lang.UnsatisfiedLinkError: 'boolean jdk.test.whitebox.WhiteBox.isStatic()'
	      at jdk.test.whitebox.WhiteBox.isStatic(Native Method)
	      at requires.VMProps.isStatic(VMProps.java:830)
	      at requires.VMProps$SafeMap.put(VMProps.java:82)
	      at requires.VMProps.call(VMProps.java:145)
	      at requires.VMProps.call(VMProps.java:67)
	      at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:80)
	      at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)
      runner starting test: java/nio/MappedByteBuffer/PmemTest.java#default_architecture_test_case
      runner finished test: java/nio/MappedByteBuffer/PmemTest.java#default_architecture_test_case
      Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /mnt/pmem/test/pmemtest
      Test results: failed: 1; did not match keywords: 1
      Report written to /home/isipka/workspace/jdk/open/test/jdk/JTreport/html/report.html
      Results written to /home/isipka/workspace/jdk/open/test/jdk/JTwork
      Error: Some tests failed or other problems occurred.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2813397799

From adinn at openjdk.org  Thu Apr 17 19:15:59 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 17 Apr 2025 19:15:59 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v3]
In-Reply-To: <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
Message-ID: <JIO2TjeqJ68w3EQFRV-2lRnYuF5B2jQvBjoDbT2bu8o=.20cb1bf3-630e-4c7c-be36-41a42031a3dd@github.com>

On Thu, 17 Apr 2025 15:49:38 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection
>
> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retruning ignore directive to other_arch test case

Ok,that looks like a good solution

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

Marked as reviewed by adinn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24416#pullrequestreview-2776688140

From adinn at openjdk.org  Thu Apr 17 19:18:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 17 Apr 2025 19:18:47 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v3]
In-Reply-To: <pOpFT2Obagr-Y8AiswSKMSRKYiBOwUAUg4esN-Sclgc=.3ee45ab6-6e8b-4929-bdf4-33b0798b9221@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
 <pOpFT2Obagr-Y8AiswSKMSRKYiBOwUAUg4esN-Sclgc=.3ee45ab6-6e8b-4929-bdf4-33b0798b9221@github.com>
Message-ID: <Gm8i59o3kQdgA4EjlfT4ZYNGNhDNQKvVaa5WFsZ1rjA=.00821111-e1df-4bfb-9bf1-39a26c905eec@github.com>

On Thu, 17 Apr 2025 15:50:21 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   retruning ignore directive to other_arch test case
>
> jtreg -ignore:quiet -verbose:esa java/nio/MappedByteBuffer/PmemTest.java
>       failed to get value for jdk.static
>       java.lang.UnsatisfiedLinkError: 'boolean jdk.test.whitebox.WhiteBox.isStatic()'
> 	      at jdk.test.whitebox.WhiteBox.isStatic(Native Method)
> 	      at requires.VMProps.isStatic(VMProps.java:830)
> 	      at requires.VMProps$SafeMap.put(VMProps.java:82)
> 	      at requires.VMProps.call(VMProps.java:145)
> 	      at requires.VMProps.call(VMProps.java:67)
> 	      at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:80)
> 	      at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)
>       runner starting test: java/nio/MappedByteBuffer/PmemTest.java#default_architecture_test_case
>       runner finished test: java/nio/MappedByteBuffer/PmemTest.java#default_architecture_test_case
>       Failed. Execution failed: `main' threw exception: java.nio.file.NoSuchFileException: /mnt/pmem/test/pmemtest
>       Test results: failed: 1; did not match keywords: 1
>       Report written to /home/isipka/workspace/jdk/open/test/jdk/JTreport/html/report.html
>       Results written to /home/isipka/workspace/jdk/open/test/jdk/JTwork
>       Error: Some tests failed or other problems occurred.

@frkator Try to integrate again and I will sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2813819379

From duke at openjdk.org  Thu Apr 17 21:29:21 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 17 Apr 2025 21:29:21 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <Irubu5FBD9hw-OMk2ZG-w9e6CjDN1U1mSs3PMzKZpjs=.2c53ee68-9cd0-4b95-87c1-97489815943c@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

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

  Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/d2ccf42c..884e7dc1

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

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

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

From duke at openjdk.org  Thu Apr 17 21:33:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Thu, 17 Apr 2025 21:33:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <9BsFYz2RyshIdK1liYcrQdIiJMf5yuhajoVSZ8V5LUQ=.23bc0d84-4f72-41d2-b5d1-753bc12c4e22@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <XejuTmY2jNXU9v2hl9I82XDoh6S98iQf9uF6YgX0vGo=.518bdda4-a3aa-48a8-9726-5233a55be3e2@github.com>
 <J_bmOHLcwsg5b7566JHJYoP-EyCCu3ftKjZQ7yz09QA=.92cf1ed3-22c0-4bb4-9ad6-7eed47bc6fc0@github.com>
 <TgO-qcQTq9gej6b26voBMG7PmeqeFO6I0gWKc6bDKgk=.b2260d40-08e8-4e8e-b00b-2f6f71e23cef@github.com>
 <eGmrpOJQBktIHWQa55r2aKZcOYxUsBgxDQk8K1JuNGw=.17801fea-ada8-41be-a89e-78b7ac04f2c3@github.com>
 <9BsFYz2RyshIdK1liYcrQdIiJMf5yuhajoVSZ8V5LUQ=.23bc0d84-4f72-41d2-b5d1-753bc12c4e22@github.com>
Message-ID: <ODVql4X_G5BZik2ZmItyS3JwU7Xbr0NEu2XbtSAYL_w=.a32ccc1f-e1ca-4d16-9bd0-20ce1bc347ff@github.com>

On Wed, 16 Apr 2025 17:04:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > IIUC then you will be fine with a test that solely tests the default implementation of CharSequence.getChars()?
> 
> Correct. And a similar separate test for `CharBuffer.getChars()` since that one too is a new default implementation method. I apologize if that wasn't clear in the discussion so far.

I now have covered `CharSequence.getChars()` and `CharBuffer.getChars()` with *separate* basic unit testing. Does this fit? ?

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2814062190

From liach at openjdk.org  Thu Apr 17 22:25:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 22:25:46 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: <Irubu5FBD9hw-OMk2ZG-w9e6CjDN1U1mSs3PMzKZpjs=.2c53ee68-9cd0-4b95-87c1-97489815943c@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <Irubu5FBD9hw-OMk2ZG-w9e6CjDN1U1mSs3PMzKZpjs=.2c53ee68-9cd0-4b95-87c1-97489815943c@github.com>
Message-ID: <DiSBARb7SeOlyr2vHMpGfL2kaUWpQi1MlH6cCTkTU00=.fde376f6-66bc-46ac-9af9-687c362359bb@github.com>

On Thu, 17 Apr 2025 21:29:21 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()

The unit tests look good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21730#pullrequestreview-2777052617

From alanb at openjdk.org  Fri Apr 18 06:06:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Apr 2025 06:06:52 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: <Irubu5FBD9hw-OMk2ZG-w9e6CjDN1U1mSs3PMzKZpjs=.2c53ee68-9cd0-4b95-87c1-97489815943c@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <Irubu5FBD9hw-OMk2ZG-w9e6CjDN1U1mSs3PMzKZpjs=.2c53ee68-9cd0-4b95-87c1-97489815943c@github.com>
Message-ID: <SGASnW4dlfrrjtpCILE968E5UE1kYPZV0aaGS1zGGhc=.03c8ff08-7eb1-4a15-8d6d-7a07f22c1bdb@github.com>

On Thu, 17 Apr 2025 21:29:21 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()

test/jdk/java/nio/CharBuffer/GetChars.java line 34:

> 32:  * @run testng GetChars
> 33:  */
> 34: public class GetChars {

The tests for buffers, including CharBuffer, are in test/jdk/java/nio/Buffer. Look at the existing Chars.java tests idea, and specifically the DataProvider "createCharBuffers" as it will show the different kinds of CharBuffers that can be tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2050100315

From duke at openjdk.org  Fri Apr 18 09:23:44 2025
From: duke at openjdk.org (duke)
Date: Fri, 18 Apr 2025 09:23:44 GMT
Subject: RFR: 8351851: Update PmemTest to run on AMD64 [v3]
In-Reply-To: <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
 <QXXuLuoSZWf2ayoiLmTmMm6H6UXtE1WNuhEgsm8wHvk=.7e088c76-1058-43a7-adbe-8560099b9170@github.com>
Message-ID: <ECLPnIskppijHRP9jwk3MfPXAWAJdtGToOgt-mjjb-8=.317eeb6a-30cc-49e8-9133-ae16aefe0a8d@github.com>

On Thu, 17 Apr 2025 15:49:38 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection
>
> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retruning ignore directive to other_arch test case

@frkator 
Your change (at version 59209dd4c58c6fa455b7ce621d468fefcf88942b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24416#issuecomment-2815048045

From isipka at openjdk.org  Fri Apr 18 10:47:46 2025
From: isipka at openjdk.org (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Fri, 18 Apr 2025 10:47:46 GMT
Subject: Integrated: 8351851: Update PmemTest to run on AMD64
In-Reply-To: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
References: <bPb2y-XZg_VY8EDYFYXZvCLTlYDCdCTIgA7m3xbFM9A=.5e237b5f-03e6-4cb4-8683-584fc08df270@github.com>
Message-ID: <my2urqycXEqt93gdurwgC3Da0YrCdSPFZ7-WlukUmcM=.b7a11ee0-4e15-44ed-bc9e-bd2d8b81af99@github.com>

On Thu, 3 Apr 2025 14:48:41 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Remove default OS platform linux x86_64, remove @ignores allowing amd64 as a viable OS platform selection

This pull request has now been integrated.

Changeset: 0feecb7c
Author:    Ivan ?ipka <isipka at openjdk.org>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0feecb7c6a982e5c65df0242711ecdb0691cef87
Stats:     7 lines in 1 file changed: 0 ins; 1 del; 6 mod

8351851: Update PmemTest to run on AMD64

Reviewed-by: adinn

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

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

From duke at openjdk.org  Fri Apr 18 12:34:42 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 18 Apr 2025 12:34:42 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v7]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <W9NHldmacTPJzAn7QyhgAuau__NMSkXgbycXQ39Z6c0=.28cae92e-0728-4990-841f-55b3272061f1@github.com>

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

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

  Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/884e7dc1..cb2a2efb

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

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

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

From duke at openjdk.org  Fri Apr 18 12:37:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 18 Apr 2025 12:37:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v6]
In-Reply-To: <SGASnW4dlfrrjtpCILE968E5UE1kYPZV0aaGS1zGGhc=.03c8ff08-7eb1-4a15-8d6d-7a07f22c1bdb@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <Irubu5FBD9hw-OMk2ZG-w9e6CjDN1U1mSs3PMzKZpjs=.2c53ee68-9cd0-4b95-87c1-97489815943c@github.com>
 <SGASnW4dlfrrjtpCILE968E5UE1kYPZV0aaGS1zGGhc=.03c8ff08-7eb1-4a15-8d6d-7a07f22c1bdb@github.com>
Message-ID: <vnu2XMJbHp8wiFJHxLm2C9JoGnlT2sM1xxCEV6kbKEs=.b4b72b23-ea88-48bd-b5f5-a5ada56aa567@github.com>

On Fri, 18 Apr 2025 06:03:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>
> test/jdk/java/nio/CharBuffer/GetChars.java line 34:
> 
>> 32:  * @run testng GetChars
>> 33:  */
>> 34: public class GetChars {
> 
> The tests for buffers, including CharBuffer, are in test/jdk/java/nio/Buffer. Look at the existing Chars.java tests idea, and specifically the DataProvider "createCharBuffers" as it will show the different kinds of CharBuffers that can be tested.

Thank you for this tip, Alan! I have move the unit test from `nio/CharBuffer` to `nio/Buffer`, and appended it with the randomized test found in `Buffer/Chars.java`. Hope it looks fine now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2050562477

From duke at openjdk.org  Fri Apr 18 12:37:48 2025
From: duke at openjdk.org (Markus KARG)
Date: Fri, 18 Apr 2025 12:37:48 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <cOEW2s_rw5J-fQdRaTEMB5VGJwQeulMSMx34YrbGeKU=.7e130c51-5936-4c9e-9528-1d26898976f6@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@github.com>
 <eqFcQvb4vOVSVYNI1S32h-kC2AwxnliAjYiPpG6xaxI=.f9044cef-d457-4d3d-bfaa-ec609c532066@github.com>
 <6dAYgfNcUgA3z3iid8wXPNo3qhdhZGDbCgOfbfA0skE=.8194c6ee-81df-4170-a983-0283c2234d0b@github.com>
 <lSXXcakkANiBkkvAic1ltq7w3PoU561-DugjzOkotQE=.54bb826d-d8d2-4df2-9529-fc6d656868dd@github.com>
 <5VoTSyeoyECVkqefMEk2IRs1y64sXHLvkjM_vRBVUKM=.c8a9d588-d203-4962-9cfd-be867d5d3807@github.com>
 <cOEW2s_rw5J-fQdRaTEMB5VGJwQeulMSMx34YrbGeKU=.7e130c51-5936-4c9e-9528-1d26898976f6@github.com>
Message-ID: <uNelUWkmEi2gngk4ICn4kSywEoqI50KJDS15aMod1HM=.6c756130-254d-4450-87e2-7d1f7314e999@github.com>

On Wed, 16 Apr 2025 15:00:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yeah, we already added this API to allow implementations to be more consistent under race condition. So for changing char sequences, this method's default implementation can throw IOOBE, but it is already specified so it is well-behaved even under race (as you can argue a read observed the shorter state of the CS that causes the failure)
>
> Omitting it is fine, it was just a reminder that an interface cannot make any definitive statements about its implementations and sometime should warn the unwary user. (We all expect them to adhere to the contract described in each method, but who knows.)
> The statement in the implSpec is fine as it only applies to the default implementation, but can be mis-read and thought to apply to all implementations. YMMV.
> And though I see consensus, I don't see any approvals yet, including the CSR.
> Its good to see it settle down and make progress.

Alan, I am a bit lost here. How to proceed: Change the JavaDocs, or keep them as found in the CSR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2050565025