From bpb at openjdk.org  Mon Mar  3 21:28:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 21:28:09 GMT
Subject: Integrated: 8350654: (fs) Files.createTempDirectory should say
 something about the default file permissions when no file attributes specified
In-Reply-To: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
Message-ID: <3tceFeFW4aqSi8zRbtttXXH2H3YjB9Jw0f1iz9DRJNs=.08b231bb-f27d-436d-96ba-1ba5c02d0fb0@github.com>

On Wed, 26 Feb 2025 18:40:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.

This pull request has now been integrated.

Changeset: 99fb350b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99fb350bf65f9469c8097ddebcc6742255435a88
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8350654: (fs) Files.createTempDirectory should say something about the default file permissions when no file attributes specified

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Mon Mar  3 22:06:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 3 Mar 2025 22:06:37 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual
Message-ID: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>

Change `BlockDeviceSize` to be a manual test for the time being.

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

Commit messages:
 - 8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual

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

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

From brian.burkhalter at oracle.com  Tue Mar  4 01:45:24 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 4 Mar 2025 01:45:24 +0000
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
In-Reply-To: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
References: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
Message-ID: <DAC8166F-B455-4CE7-B327-20146DB78B77@oracle.com>

Hello,

Looking at this again, I just wanted to clarify the calling situation. You have a Path something like

Path p = Path.of(?/?, ?media?, ?nfsvolume?, ?dir?, ?subdir?, ?leafdir?);  // ?/media/nfsvolume/dir/subdir/leafdir?

to an existing read-only directory ?leafdir?, and you invoke createDirectories as

Path q = Files.createDirectories(p);

and either it works or it throws an AccessDeniedException?

Thanks,

Brian

> On Nov 26, 2024, at 8:44?AM, ole.sh at gmx.de wrote:
> 
> I came a across a behavior of Files.createDirectories on Linux (RHEL8, JDK 17) that is a litte "unexpected":
> The call of Files.createDirectories for an existing (and readable) directory on an NFS mount throws an AccessDeniedException. Technically this exception is correct because our process does not have the filesystem rights to create the directory, the process does have the rights to "read" the directory though.

From alanb at openjdk.org  Tue Mar  4 09:02:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Mar 2025 09:02:08 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual
In-Reply-To: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
Message-ID: <GB88jVFj6_YY0lxVrUTTaW88KHo9_UraXUTT-MqBBJs=.1c29d2f8-a12c-41e6-a6aa-1e048351495e@github.com>

On Mon, 3 Mar 2025 22:00:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BlockDeviceSize` to be a manual test for the time being.

@msheppar Do you know if manual tests require instructions beyond the summary line? This one doesn't need any setup, it just needs to be run with a user with privileges.

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

PR Comment: https://git.openjdk.org/jdk/pull/23877#issuecomment-2696701815

From msheppar at openjdk.org  Tue Mar  4 12:27:53 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 4 Mar 2025 12:27:53 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual
In-Reply-To: <GB88jVFj6_YY0lxVrUTTaW88KHo9_UraXUTT-MqBBJs=.1c29d2f8-a12c-41e6-a6aa-1e048351495e@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
 <GB88jVFj6_YY0lxVrUTTaW88KHo9_UraXUTT-MqBBJs=.1c29d2f8-a12c-41e6-a6aa-1e048351495e@github.com>
Message-ID: <MytI26rQfGFW6RQ45rYw3665Wod235i_Mz1nph-nVlA=.aa40fa65-0d64-478e-bb7d-65434d29a06d@github.com>

On Tue, 4 Mar 2025 08:58:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @msheppar Do you know if manual tests require instructions beyond the summary line? This one doesn't need any setup, it just needs to be run with a user with privileges.

If the test needs to be run as root or as sudo, then this will need to be clearly stated in a summary line

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

PR Comment: https://git.openjdk.org/jdk/pull/23877#issuecomment-2697394618

From bpb at openjdk.org  Tue Mar  4 17:05:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Mar 2025 17:05:38 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual [v2]
In-Reply-To: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
Message-ID: <0csMx-CZy5OIRAy5YN3LuSNbqYmhtu4Kc-jj2iCYf9c=.881cbce9-357d-4fc9-afc8-42099822fea0@github.com>

> Change `BlockDeviceSize` to be a manual test for the time being.

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

  8351086: Add a comment indicating that the test must be launched with sudo or equivalent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23877/files
  - new: https://git.openjdk.org/jdk/pull/23877/files/d11f1c6e..be439b3c

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

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

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

From bpb at openjdk.org  Tue Mar  4 17:05:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 4 Mar 2025 17:05:38 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual
In-Reply-To: <MytI26rQfGFW6RQ45rYw3665Wod235i_Mz1nph-nVlA=.aa40fa65-0d64-478e-bb7d-65434d29a06d@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
 <GB88jVFj6_YY0lxVrUTTaW88KHo9_UraXUTT-MqBBJs=.1c29d2f8-a12c-41e6-a6aa-1e048351495e@github.com>
 <MytI26rQfGFW6RQ45rYw3665Wod235i_Mz1nph-nVlA=.aa40fa65-0d64-478e-bb7d-65434d29a06d@github.com>
Message-ID: <EB-nM9OdTdBG8xDMRtQXCgUSQgiIXjhmgAdyePmxIMA=.1b63f18e-2572-4fe8-810f-f6be0a312835@github.com>

On Tue, 4 Mar 2025 12:25:20 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> @msheppar Do you know if manual tests require instructions beyond the summary line? This one doesn't need any setup, it just needs to be run with a user with privileges.
>
>> @msheppar Do you know if manual tests require instructions beyond the summary line? This one doesn't need any setup, it just needs to be run with a user with privileges.
> 
> If the test needs to be run as root or as sudo, then this will need to be clearly stated in a summary line

@msheppar Please let me know whether be439b3 is sufficient.

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

PR Comment: https://git.openjdk.org/jdk/pull/23877#issuecomment-2698346685

From bchristi at openjdk.org  Tue Mar  4 23:16:13 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 4 Mar 2025 23:16:13 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <LcZtUjCXWicin-NhFBQKKcXSiCj5SivVMRDDf96dFO0=.5b46ddbe-959a-44a6-b689-8325770f4cad@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
 <LcZtUjCXWicin-NhFBQKKcXSiCj5SivVMRDDf96dFO0=.5b46ddbe-959a-44a6-b689-8325770f4cad@github.com>
Message-ID: <SSWxMX2KExCJG3dJN5aLrWzKomloV6XhSiXp1-zKTFw=.997afff7-1d88-4d27-b4b7-9d876782c2b6@github.com>

On Sun, 23 Feb 2025 10:20:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I've made a prototype that adds Cleaner.waitForCleaning() and changes Bits.reserveMemory() to use it.
> 
> https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:wait-for-cleaning?expand=1

These caught my eye during my read-through:

- The main `CleanerImpl.run()` loop is changed to call `queue.poll()` in place of (blocking) `queue.remove(timeout)`. Could this make this a busier wait loop? 
- My impression is that it does more locking.

I wonder how these together could affect performance of less specialized Cleaner usage cases (where objects are not being enqueued very often).

I'm therefore inclined for changes along these lines to be limited to a DirectByteBuffer-specific mechanism, as you suggested in your point (2).

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2699207286

From msheppar at openjdk.org  Wed Mar  5 16:21:54 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 5 Mar 2025 16:21:54 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual [v2]
In-Reply-To: <0csMx-CZy5OIRAy5YN3LuSNbqYmhtu4Kc-jj2iCYf9c=.881cbce9-357d-4fc9-afc8-42099822fea0@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
 <0csMx-CZy5OIRAy5YN3LuSNbqYmhtu4Kc-jj2iCYf9c=.881cbce9-357d-4fc9-afc8-42099822fea0@github.com>
Message-ID: <hE9cRO0KGfdvkfqjA9C7SA0cz-ee8U6g2-_1qfl4KIU=.095e8852-47bd-401d-a1dd-95c2f91a18a7@github.com>

On Tue, 4 Mar 2025 17:05:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `BlockDeviceSize` to be a manual test for the time being.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8351086: Add a comment indicating that the test must be launched with sudo or equivalent

Marked as reviewed by msheppar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23877#pullrequestreview-2661678155

From msheppar at openjdk.org  Wed Mar  5 16:21:55 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 5 Mar 2025 16:21:55 GMT
Subject: RFR: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual
In-Reply-To: <MytI26rQfGFW6RQ45rYw3665Wod235i_Mz1nph-nVlA=.aa40fa65-0d64-478e-bb7d-65434d29a06d@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
 <GB88jVFj6_YY0lxVrUTTaW88KHo9_UraXUTT-MqBBJs=.1c29d2f8-a12c-41e6-a6aa-1e048351495e@github.com>
 <MytI26rQfGFW6RQ45rYw3665Wod235i_Mz1nph-nVlA=.aa40fa65-0d64-478e-bb7d-65434d29a06d@github.com>
Message-ID: <wXxQwkVI_dgoYzEntSBKgv_hslJEHC6KoLPAPuW-6f0=.57fc2e07-0bba-46a8-a6ef-3cd49b3e670e@github.com>

On Tue, 4 Mar 2025 12:25:20 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> @msheppar Do you know if manual tests require instructions beyond the summary line? This one doesn't need any setup, it just needs to be run with a user with privileges.
>
>> @msheppar Do you know if manual tests require instructions beyond the summary line? This one doesn't need any setup, it just needs to be run with a user with privileges.
> 
> If the test needs to be run as root or as sudo, then this will need to be clearly stated in a summary line

> @msheppar Please let me know whether [be439b3](https://github.com/openjdk/jdk/commit/be439b3caa3fbd90208bc86f639d4543b54d9d42) is sufficient.

yes, that looks fine ... thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/23877#issuecomment-2701427973

From bpb at openjdk.org  Wed Mar  5 17:57:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Mar 2025 17:57:38 GMT
Subject: RFR: 8351294: (fs) Minor verbiage correction for
 Files.createTemp{Directory,File}
Message-ID: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>

Modernize some verbiage from the Pliocene epoch: "to" becomes "than".

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

Commit messages:
 - 8351294: (fs) Minor verbiage correction for Files.createTemp{Directory,File}

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

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

From dfuchs at openjdk.org  Wed Mar  5 17:57:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Mar 2025 17:57:38 GMT
Subject: RFR: 8351294: (fs) Minor verbiage correction for
 Files.createTemp{Directory,File}
In-Reply-To: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
References: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
Message-ID: <Y4nFZCBUQJsaFHeOBk3kaKStFsjP1UNFjOc3Hp8DWfg=.aface9c9-f7ba-4c54-96ea-fd0c6cea62bb@github.com>

On Wed, 5 Mar 2025 17:50:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modernize some verbiage from the Pliocene epoch: "to" becomes "than".

Thanks Brian - it reads better to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/23919#issuecomment-2701670125

From bpb at openjdk.org  Wed Mar  5 18:06:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Mar 2025 18:06:57 GMT
Subject: RFR: 8351294: (fs) Minor verbiage correction for
 Files.createTemp{Directory,File}
In-Reply-To: <Y4nFZCBUQJsaFHeOBk3kaKStFsjP1UNFjOc3Hp8DWfg=.aface9c9-f7ba-4c54-96ea-fd0c6cea62bb@github.com>
References: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
 <Y4nFZCBUQJsaFHeOBk3kaKStFsjP1UNFjOc3Hp8DWfg=.aface9c9-f7ba-4c54-96ea-fd0c6cea62bb@github.com>
Message-ID: <Wou7Nfm2gT2X7iFC5FnPox1_pYrNsVZ6soibf_EzJhw=.412cb380-6b7d-4d08-a6da-bb51fe3b2ca0@github.com>

On Wed, 5 Mar 2025 17:54:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks Brian - it reads better to me.

Thanks for noticing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/23919#issuecomment-2701692972

From alanb at openjdk.org  Thu Mar  6 07:04:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 6 Mar 2025 07:04:02 GMT
Subject: RFR: 8351294: (fs) Minor verbiage correction for
 Files.createTemp{Directory,File}
In-Reply-To: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
References: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
Message-ID: <CNGIZzfXgQmJvgK7yF80nKEG25LEBYUNMHO0PI3L0fQ=.25e447dc-9548-44fa-86ed-aa12514e3cdd@github.com>

On Wed, 5 Mar 2025 17:50:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modernize some verbiage from the Pliocene epoch: "to" becomes "than".

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23919#pullrequestreview-2663512676

From michaelm at openjdk.org  Thu Mar  6 10:28:20 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 10:28:20 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
Message-ID: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@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

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

Commit messages:
 - remove file added by mistake
 - whitespace
 - moved test
 - Merge branch 'master' into 8348986-exceptions
 - update
 - update
 - Merge branch 'master' into 8348986-exceptions
 - update
 - Merge branch 'master' into 8348986-exceptions
 - Merge branch 'master' into 8348986-exceptions
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b1a21b56...c4419860

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348986
  Stats: 1002 lines in 42 files changed: 762 ins; 104 del; 136 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 Mar  6 10:46:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 10:46:11 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v2]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <ReTVIq4Jzm7ki_mb0YnWVS_arlFB7mbFPPZTNvMlSU8=.11efccac-16a5-4862-acca-07f280a487e2@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:

  doc + copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/c4419860..074da251

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

  Stats: 23 lines in 3 files changed: 10 ins; 5 del; 8 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 aturbanov at openjdk.org  Thu Mar  6 12:05:59 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 6 Mar 2025 12:05:59 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v2]
In-Reply-To: <ReTVIq4Jzm7ki_mb0YnWVS_arlFB7mbFPPZTNvMlSU8=.11efccac-16a5-4862-acca-07f280a487e2@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <ReTVIq4Jzm7ki_mb0YnWVS_arlFB7mbFPPZTNvMlSU8=.11efccac-16a5-4862-acca-07f280a487e2@github.com>
Message-ID: <MfyWdrSkY3fNayMvdrwI7jzBqk69E_yzNN02Am4Wcfo=.9f58de64-7f59-4633-af24-0a2d8f65a075@github.com>

On Thu, 6 Mar 2025 10:46:11 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:
> 
>   doc + copyright update

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

> 101:      * the output is the replacement string.
> 102:      */
> 103:     public static abstract class SensitiveInfo  {

Let's sort modifiers in blessed order
Suggestion:

    public abstract static class SensitiveInfo {

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

> 336:                                       | hostCompatFlag;
> 337:         enhancedUserExceptionText = SecurityProperties.includedInExceptions("userInfo");
> 338:         enhancedJarExceptionText =  SecurityProperties.INCLUDE_JAR_NAME_IN_EXCEPTIONS;

Suggestion:

        enhancedJarExceptionText = SecurityProperties.INCLUDE_JAR_NAME_IN_EXCEPTIONS;

test/jdk/sun/net/util/ExceptionsTest.java line 47:

> 45: 
> 46:     static boolean netEnabled() {
> 47:         System.out.printf("netEnabled = %b\n",  enhancedNetExceptions());

Suggestion:

        System.out.printf("netEnabled = %b\n", enhancedNetExceptions());

test/jdk/sun/net/util/ExceptionsTest.java line 52:

> 50: 
> 51:     static boolean dnsEnabled() {
> 52:         System.out.printf("dnsEnabled = %b\n",  enhancedLookupExceptions());

Suggestion:

        System.out.printf("dnsEnabled = %b\n", enhancedLookupExceptions());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983229570
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232405
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232786
PR Review Comment: https://git.openjdk.org/jdk/pull/23929#discussion_r1983232968

From michaelm at openjdk.org  Thu Mar  6 12:32:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Mar 2025 12:32:39 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages [v3]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <9L8DA7kJW6gXoCrbx4Gkn7hGk_3h8FmARRPHqzbHNs8=.6dc91725-b519-45c4-aa20-618df1155a91@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:

  Apply suggestions from code review
  
  from turbanoff review
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/074da251..41d1ef82

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

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 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 bpb at openjdk.org  Thu Mar  6 17:15:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Mar 2025 17:15:01 GMT
Subject: Integrated: 8351086: (fc) Make
 java/nio/channels/FileChannel/BlockDeviceSize.java test manual
In-Reply-To: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
References: <L_x-I2iHQbGLBsplNV_xsvHNdOzHyR4_rhT2kpo7VhA=.278c99a4-bc19-4e91-a2eb-78aa4e0ced6a@github.com>
Message-ID: <oSfuOr9by7o5Ra5TPf5_i4Y_aVBSPwSfW_LHJ7QsUuA=.d8bfd76e-11d1-40cc-a020-0d26361707e8@github.com>

On Mon, 3 Mar 2025 22:00:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `BlockDeviceSize` to be a manual test for the time being.

This pull request has now been integrated.

Changeset: 08929134
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08929134b3533362133139c4e964b1b28de6ebfb
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8351086: (fc) Make java/nio/channels/FileChannel/BlockDeviceSize.java test manual

Reviewed-by: msheppar

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

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

From bpb at openjdk.org  Thu Mar  6 17:14:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Mar 2025 17:14:58 GMT
Subject: Integrated: 8351294: (fs) Minor verbiage correction for
 Files.createTemp{Directory,File}
In-Reply-To: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
References: <ZGajcGewFjwqA15yGeD0PIk6VUovm_A6-fLHl4Tk7vI=.17e1b2cc-d84b-472f-9467-840a65c739eb@github.com>
Message-ID: <mgGG9JeU8todjc3n-5U7m4fM5HrJqmMajgxrVuRtVmc=.2a9378da-6c12-411b-92aa-8d2f0a1bdc5e@github.com>

On Wed, 5 Mar 2025 17:50:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modernize some verbiage from the Pliocene epoch: "to" becomes "than".

This pull request has now been integrated.

Changeset: 93f22607
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93f226078e1e1cee5f17b4866f4712326bffa5b2
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8351294: (fs) Minor verbiage correction for Files.createTemp{Directory,File}

Reviewed-by: alanb

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

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

From duke at openjdk.org  Fri Mar  7 21:49:02 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Mar 2025 21:49:02 GMT
Subject: Withdrawn: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in
 ZipFS
In-Reply-To: <rkg0vDKsEg85HRr_F7fSTdOkOYJa4RrTbzb62I_Dc0Q=.e021cc94-c84d-4e09-b94b-1493f39d0a25@github.com>
References: <rkg0vDKsEg85HRr_F7fSTdOkOYJa4RrTbzb62I_Dc0Q=.e021cc94-c84d-4e09-b94b-1493f39d0a25@github.com>
Message-ID: <-5rTLEbAKE-BCvluQCIJvk3JO_3Gi8P-tI3zQRPKLjA=.8f48bf5e-dc7e-4939-8282-bd2575687ce4@github.com>

On Wed, 25 Dec 2024 23:55:18 GMT, Bruno Ploumhans <duke at openjdk.org> wrote:

> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882.
> 
> Following discussion in nio-dev a while ago, I have opted to add a new `NOT_INTERRUPTIBLE` open option, superseding `FileChannelImpl#setUninterruptible`.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Mon Mar 10 14:47:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Mar 2025 14:47:28 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
Message-ID: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>

Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.

There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).

We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/23956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351458
  Stats: 163 lines in 12 files changed: 43 ins; 82 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/23956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23956/head:pull/23956

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

From bpb at openjdk.org  Mon Mar 10 16:48:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 16:48:02 GMT
Subject: RFR: 8351505: (fs) Typo in the documentation of
 java.nio.file.spi.FileSystem Provider.getFileSystem()
Message-ID: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>

Correct the indicated typo.

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

Commit messages:
 - 8351505: (fs) Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()

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

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

From alanb at openjdk.org  Mon Mar 10 17:31:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Mar 2025 17:31:53 GMT
Subject: RFR: 8351505: (fs) Typo in the documentation of
 java.nio.file.spi.FileSystem Provider.getFileSystem()
In-Reply-To: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>
References: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>
Message-ID: <PIZX9ufoP1H9I3M0dpddWKOkHeicbtnPTvZhQ8U4Ax8=.11742b9b-8c14-4eea-89d6-6736755f3eed@github.com>

On Mon, 10 Mar 2025 16:43:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Correct the indicated typo.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23968#pullrequestreview-2671734320

From lancea at openjdk.org  Mon Mar 10 17:36:53 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 10 Mar 2025 17:36:53 GMT
Subject: RFR: 8351505: (fs) Typo in the documentation of
 java.nio.file.spi.FileSystem Provider.getFileSystem()
In-Reply-To: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>
References: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>
Message-ID: <SQzqL8AMcJ_Sn18t71QrIarn1HVwp-VbHZZ5zrAWXpc=.a3f34ca7-7214-45d5-88a3-1026bd46aeb7@github.com>

On Mon, 10 Mar 2025 16:43:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Correct the indicated typo.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23968#pullrequestreview-2671744439

From bpb at openjdk.org  Mon Mar 10 18:13:05 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 18:13:05 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <Q8ZStyQqkY5Wggdg0zfyNRgCj8Ndp0zLaY967klQDyk=.bcdd25ac-ce77-423a-9402-886e01ed29f7@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

I don't see any problems. This looks like a nice cleanup.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23956#pullrequestreview-2671826649

From iris at openjdk.org  Mon Mar 10 19:24:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Mar 2025 19:24:52 GMT
Subject: RFR: 8351505: (fs) Typo in the documentation of
 java.nio.file.spi.FileSystem Provider.getFileSystem()
In-Reply-To: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>
References: <tNwQMzO4y9CdPe-Yxkg747fJ2lnVMuMnxNthH-R8jB4=.0e1e2f37-a462-4575-b6c6-fe1269eda059@github.com>
Message-ID: <YDNsDB_8aN4XmgTlR9dNRPLtClIenqtmE9uBkJVH8Ws=.e5bd3dba-249f-4501-a388-d1790a41bcaa@github.com>

On Mon, 10 Mar 2025 16:43:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Correct the indicated typo.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23968#pullrequestreview-2671984249

From bpb at openjdk.org  Mon Mar 10 22:23:04 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Mar 2025 22:23:04 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
Message-ID: <0gRIhH2kkir2ojZFQ_JwXoo5K6TQ_6jM1jS_9kkzgU8=.2cd33484-171a-4443-834b-76ddd45b6b72@github.com>

On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> 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 11 commits:
> 
>  - 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
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2711976367

From jpai at openjdk.org  Tue Mar 11 04:23:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 04:23:52 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <juWoCJhahbn3iIVWIcl0scKCZ6xMnTF3sXnYwya4Upk=.b60340ce-8892-488f-8be1-6c462b051643@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 83:

> 81:     final void preClose(FileDescriptor fd, long reader, long writer) throws IOException {
> 82:         if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) {
> 83:             int fdVal = JIOFDA.get(fd);

Hello Alan, previously, in the case of `DatagramChannelImpl`, the `fdVal` was a `final` that was determined when the channel was constructed. Now, that `fdVal` gets determined as and when needed and I see that `FileDescriptor` allows this underlying value to be changed/reset. Is there anything practical to consider here in context of a `fdVal` that has been reset in the `FileDescriptor`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988364111

From jpai at openjdk.org  Tue Mar 11 04:27:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 04:27:51 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <Naw3GHUSb8rjwptUY1emyvIFO8eqsHG3UMDXNAo0nLI=.b832e75b-24e5-4d5e-b28e-7a60981f75e1@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 82:

> 80:      */
> 81:     final void preClose(FileDescriptor fd, long reader, long writer) throws IOException {
> 82:         if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) {

There used to be a `if (reader != 0 || writer != 0) {...}` check before doing any of this pre-close work, in `DatagramChannelImpl`. Is that no longer needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988367022

From jpai at openjdk.org  Tue Mar 11 04:45:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 04:45:52 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <Naw3GHUSb8rjwptUY1emyvIFO8eqsHG3UMDXNAo0nLI=.b832e75b-24e5-4d5e-b28e-7a60981f75e1@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
 <Naw3GHUSb8rjwptUY1emyvIFO8eqsHG3UMDXNAo0nLI=.b832e75b-24e5-4d5e-b28e-7a60981f75e1@github.com>
Message-ID: <r8597-M0Gy6YdqtivU1nBHGdOa2-g4sXCmEeGH4S_XE=.d36ebc8f-0617-4af8-944b-72d663b821ea@github.com>

On Tue, 11 Mar 2025 04:25:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> There used to be a if (reader != 0 || writer != 0) {...} check before doing any of this pre-close work, in DatagramChannelImpl. Is that no longer needed?

Looking at the implementation of `NativeThread.isNativeThread()` and `NativeThread.isVirtualThread()`, it already implicitly takes into account the `!= 0` check, so I guess the previous explicit checks before calling those methods was redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988381093

From alanb at openjdk.org  Tue Mar 11 07:34:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 07:34:53 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <r8597-M0Gy6YdqtivU1nBHGdOa2-g4sXCmEeGH4S_XE=.d36ebc8f-0617-4af8-944b-72d663b821ea@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
 <Naw3GHUSb8rjwptUY1emyvIFO8eqsHG3UMDXNAo0nLI=.b832e75b-24e5-4d5e-b28e-7a60981f75e1@github.com>
 <r8597-M0Gy6YdqtivU1nBHGdOa2-g4sXCmEeGH4S_XE=.d36ebc8f-0617-4af8-944b-72d663b821ea@github.com>
Message-ID: <D6f5rCyWqKe0WOh3LfnajVZo_LDWA4bq5NVPvzkyIFs=.9a9371f5-2a6a-4e5b-80d2-9a3f4e110166@github.com>

On Tue, 11 Mar 2025 04:42:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 82:
>> 
>>> 80:      */
>>> 81:     final void preClose(FileDescriptor fd, long reader, long writer) throws IOException {
>>> 82:         if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) {
>> 
>> There used to be a `if (reader != 0 || writer != 0) {...}` check before doing any of this pre-close work, in `DatagramChannelImpl`. Is that no longer needed?
>
>> There used to be a if (reader != 0 || writer != 0) {...} check before doing any of this pre-close work, in DatagramChannelImpl. Is that no longer needed?
> 
> Looking at the implementation of `NativeThread.isNativeThread()` and `NativeThread.isVirtualThread()`, it already implicitly takes into account the `!= 0` check, so I guess the previous explicit checks before calling those methods was redundant.

Right, there are a several places where check for != 0 would be redundant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988576800

From alanb at openjdk.org  Tue Mar 11 07:34:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 07:34:55 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <juWoCJhahbn3iIVWIcl0scKCZ6xMnTF3sXnYwya4Upk=.b60340ce-8892-488f-8be1-6c462b051643@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
 <juWoCJhahbn3iIVWIcl0scKCZ6xMnTF3sXnYwya4Upk=.b60340ce-8892-488f-8be1-6c462b051643@github.com>
Message-ID: <_vJpTtmYSDZSJOcWgfK9DGabK89aL1XUPDuw46X96-M=.285dc34c-96fd-4977-8ba5-0366ec92748a@github.com>

On Tue, 11 Mar 2025 04:21:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
>> 
>> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
>> 
>> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.
>
> src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 83:
> 
>> 81:     final void preClose(FileDescriptor fd, long reader, long writer) throws IOException {
>> 82:         if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) {
>> 83:             int fdVal = JIOFDA.get(fd);
> 
> Hello Alan, previously, in the case of `DatagramChannelImpl`, the `fdVal` was a `final` that was determined when the channel was constructed. Now, that `fdVal` gets determined as and when needed and I see that `FileDescriptor` allows this underlying value to be changed/reset. Is there anything practical to consider here in context of a `fdVal` that has been reset in the `FileDescriptor`?

repairSocket doesn't change fd/fdVal, instead they will be connected to a new socket if the method succeeds (or the old socket if it fails).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988574631

From jpai at openjdk.org  Tue Mar 11 08:16:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 08:16:55 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <G730ISZoxrDO19fWKksE18PzTPJQZMcDrGoSnoeIStk=.9dc8151c-b922-4da0-b4e7-3cdb804a76ed@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

The changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23956#pullrequestreview-2673306157

From jpai at openjdk.org  Tue Mar 11 08:16:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 08:16:56 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <_vJpTtmYSDZSJOcWgfK9DGabK89aL1XUPDuw46X96-M=.285dc34c-96fd-4977-8ba5-0366ec92748a@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
 <juWoCJhahbn3iIVWIcl0scKCZ6xMnTF3sXnYwya4Upk=.b60340ce-8892-488f-8be1-6c462b051643@github.com>
 <_vJpTtmYSDZSJOcWgfK9DGabK89aL1XUPDuw46X96-M=.285dc34c-96fd-4977-8ba5-0366ec92748a@github.com>
Message-ID: <dqfPDiaszGrJutL7BoOOPOMSisSSIrV6lcbd60zTlyA=.b3e625c2-cbcf-45b5-ad22-07fa0efd24c2@github.com>

On Tue, 11 Mar 2025 07:31:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 83:
>> 
>>> 81:     final void preClose(FileDescriptor fd, long reader, long writer) throws IOException {
>>> 82:         if (NativeThread.isVirtualThread(reader) || NativeThread.isVirtualThread(writer)) {
>>> 83:             int fdVal = JIOFDA.get(fd);
>> 
>> Hello Alan, previously, in the case of `DatagramChannelImpl`, the `fdVal` was a `final` that was determined when the channel was constructed. Now, that `fdVal` gets determined as and when needed and I see that `FileDescriptor` allows this underlying value to be changed/reset. Is there anything practical to consider here in context of a `fdVal` that has been reset in the `FileDescriptor`?
>
> repairSocket doesn't change fd/fdVal, instead they will be connected to a new socket if the method succeeds (or the old socket if it fails).

It was the `FileDescriptor.set(int fd)` method which I had in mind. But I now looked at its references and I see that there aren't any in the code paths that this PR deals with. So I believe the proposed change looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23956#discussion_r1988653010

From michaelm at openjdk.org  Tue Mar 11 08:47:52 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 11 Mar 2025 08:47:52 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <0gZk8gspZx-V3Qj5Amc4pnAOloT2G0TnSQJxAeAHIU8=.5ad01e1b-2edd-4793-b6d7-8a3bdab63e2e@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

So, on Unix, the fd needs to be dup'ed and the native thread signalled. On Windows, the dup() operation does not happen, but the threads were being signalled previously, but not any more. Was that redundant previously?

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

PR Review: https://git.openjdk.org/jdk/pull/23956#pullrequestreview-2673423557

From alanb at openjdk.org  Tue Mar 11 08:52:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 08:52:53 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <0gZk8gspZx-V3Qj5Amc4pnAOloT2G0TnSQJxAeAHIU8=.5ad01e1b-2edd-4793-b6d7-8a3bdab63e2e@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
 <0gZk8gspZx-V3Qj5Amc4pnAOloT2G0TnSQJxAeAHIU8=.5ad01e1b-2edd-4793-b6d7-8a3bdab63e2e@github.com>
Message-ID: <_u8_UZa7ZuhP474N-YPyXl_9UK5Nh0dhVuNdpHpt3kk=.a6fda430-d9c8-4b02-9419-40af002bfa28@github.com>

On Tue, 11 Mar 2025 08:45:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> So, on Unix, the fd needs to be dup'ed and the native thread signalled. On Windows, the dup() operation does not happen, but the threads were being signalled previously, but not any more. Was that redundant previously?

There's never been any signalling of threads on Windows, NativeThread::isNativeThread always returns false. So no change on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/23956#issuecomment-2713194965

From alanb at openjdk.org  Tue Mar 11 11:29:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 11:29:13 GMT
Subject: RFR: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <a0q0YzwhkDKFukT-swHp2cs6MoYF8ElxE4uQq12WnwQ=.64a7cf98-812a-4dda-9d78-d0b7c9b25d32@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

Thanks for the reviews/comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/23956#issuecomment-2713784566

From alanb at openjdk.org  Tue Mar 11 11:29:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Mar 2025 11:29:13 GMT
Subject: Integrated: 8351458: (ch) Move preClose to UnixDispatcher
In-Reply-To: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
References: <nI6CaWgwdZeNl0w0UeIpeb-fQmIG2MhqOU1Oog0zENE=.40a47eae-19ac-4dfd-a891-1a841a710a00@github.com>
Message-ID: <QYnP3g6sNzGInjpGxiWFkr-PLGGzhZmK9P4gAkp5meg=.d4bc951a-859b-4412-903b-9d12fd51bc72@github.com>

On Sun, 9 Mar 2025 09:10:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Network channels in blocking mode, and the NIO based SocketImpl, have to deal with async close when there are threads blocked on the channel. Virtual threads blocked on the channel need to be unparked. On Unix systems, platform threads blocked on the channel require the file descriptor to be dup'ed to a special file descriptor and the threads signalled.
> 
> There is a bit of duplication in the implementation of the 5 channels, and in the SocketImpl. In addition, there is discussion on net-dev about an issue in AIX that will require allowing for signals to be queued (the current implementation does not require OS to support queuing of signals).
> 
> We refactor this code so that the "prepare for close" is in one place, UnixDispatcher.

This pull request has now been integrated.

Changeset: 0de2cddf
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0de2cddf3a7be23f67af93972875af1235f3107e
Stats:     163 lines in 12 files changed: 43 ins; 82 del; 38 mod

8351458: (ch) Move preClose to UnixDispatcher

Reviewed-by: bpb, jpai

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

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

From duke at openjdk.org  Sat Mar 15 13:58:29 2025
From: duke at openjdk.org (Arend von Reinersdorff)
Date: Sat, 15 Mar 2025 13:58:29 GMT
Subject: RFR: 8351505: Typo in the documentation of
 java.nio.file.spi.FileSystemProvider.getFileSystem()
Message-ID: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>

8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()

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

Commit messages:
 - Add missing words in FileSystemProvider.getFileSystem() Javadoc

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

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

From duke at openjdk.org  Sat Mar 15 13:58:29 2025
From: duke at openjdk.org (Arend von Reinersdorff)
Date: Sat, 15 Mar 2025 13:58:29 GMT
Subject: RFR: 8351505: Typo in the documentation of
 java.nio.file.spi.FileSystemProvider.getFileSystem()
In-Reply-To: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
References: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
Message-ID: <S6S2JDACs5UlLJDWz8py2VWL7Z6K_cx9HPU8FvvN3l0=.b5a49f64-eea9-42bc-aefd-4963f7cab206@github.com>

On Sat, 11 Jan 2025 22:48:12 GMT, Arend von Reinersdorff <duke at openjdk.org> wrote:

> 8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()

ping

ping

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

PR Comment: https://git.openjdk.org/jdk/pull/23052#issuecomment-2646153238
PR Comment: https://git.openjdk.org/jdk/pull/23052#issuecomment-2708918590

From jpai at openjdk.org  Sat Mar 15 13:58:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Mar 2025 13:58:30 GMT
Subject: RFR: 8351505: Typo in the documentation of
 java.nio.file.spi.FileSystemProvider.getFileSystem()
In-Reply-To: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
References: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
Message-ID: <aKi8VwTFU-BR0qyV0unx1za-va312NM2b990iafXXhk=.bd13f503-59c3-4d62-a965-5d6a5be25203@github.com>

On Sat, 11 Jan 2025 22:48:12 GMT, Arend von Reinersdorff <duke at openjdk.org> wrote:

> 8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()

Hello Arend, the JDK project relies on Skara bots to generate a RFR (request for review) email to the relevant mailing list. One requirement before generating the RFR is to have an issue created for the PR in the JDK issue tracker. For issues like these, the typical process is to first create a bug here https://bugs.java.com/bugdatabase/ and once the bug has been triaged and a bug id allocated, you can create a PR for it. More details about the contribution guidelines are available here https://openjdk.org/guide/#contributing-to-an-openjdk-project.

As for this specific change, this does look like a genuine typo in the documentation. I've created a bug for you here https://bugs.openjdk.org/browse/JDK-8351505. Please edit the title of this PR to `8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()` so that it gets picked up by the bots to trigger the review process.

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

PR Comment: https://git.openjdk.org/jdk/pull/23052#issuecomment-2710700754

From duke at openjdk.org  Sat Mar 15 14:01:54 2025
From: duke at openjdk.org (Arend von Reinersdorff)
Date: Sat, 15 Mar 2025 14:01:54 GMT
Subject: RFR: 8351505: Typo in the documentation of
 java.nio.file.spi.FileSystemProvider.getFileSystem()
In-Reply-To: <aKi8VwTFU-BR0qyV0unx1za-va312NM2b990iafXXhk=.bd13f503-59c3-4d62-a965-5d6a5be25203@github.com>
References: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
 <aKi8VwTFU-BR0qyV0unx1za-va312NM2b990iafXXhk=.bd13f503-59c3-4d62-a965-5d6a5be25203@github.com>
Message-ID: <R-B8TNWNndw9JcA65ZIA79De4Kv-BCl3SZ6UOSQQl0w=.3d7105b9-e144-442c-ac46-e4fd1a10cb45@github.com>

On Mon, 10 Mar 2025 13:58:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> 8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()
>
> Hello Arend, the JDK project relies on Skara bots to generate a RFR (request for review) email to the relevant mailing list. One requirement before generating the RFR is to have an issue created for the PR in the JDK issue tracker. For issues like these, the typical process is to first create a bug here https://bugs.java.com/bugdatabase/ and once the bug has been triaged and a bug id allocated, you can create a PR for it. More details about the contribution guidelines are available here https://openjdk.org/guide/#contributing-to-an-openjdk-project.
> 
> As for this specific change, this does look like a genuine typo in the documentation. I've created a bug for you here https://bugs.openjdk.org/browse/JDK-8351505. Please edit the title of this PR to `8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()` so that it gets picked up by the bots to trigger the review process.

@jaikiran thank you for creating the issue :-) Has in the meantime been fixed by https://github.com/openjdk/jdk/pull/23968

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

PR Comment: https://git.openjdk.org/jdk/pull/23052#issuecomment-2726574098

From duke at openjdk.org  Sat Mar 15 14:01:55 2025
From: duke at openjdk.org (Arend von Reinersdorff)
Date: Sat, 15 Mar 2025 14:01:55 GMT
Subject: Withdrawn: 8351505: Typo in the documentation of
 java.nio.file.spi.FileSystemProvider.getFileSystem()
In-Reply-To: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
References: <P0SA3xcEF_bbml4CL8l0StcTE9NW5jMbSQsfkmg3Vk4=.1304a291-2b8d-495f-99ac-f8f6b8bb2113@github.com>
Message-ID: <3RLvsjU-neMlrnwNNrhxEPPB2P3KT6-ZRLv8kC_BLwE=.72b207a8-6f72-4007-920f-84f13e286b92@github.com>

On Sat, 11 Jan 2025 22:48:12 GMT, Arend von Reinersdorff <duke at openjdk.org> wrote:

> 8351505: Typo in the documentation of java.nio.file.spi.FileSystemProvider.getFileSystem()

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sat Mar 15 23:32:58 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 15 Mar 2025 23:32:58 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <h_Z8koBIigcLaNZcf0S4Jd70amEA4Bd-EMlaf1QSi8s=.41b8a6e2-fca1-44dd-8aa3-5091c8003e24@github.com>

On Sat, 26 Oct 2024 15:48:11 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.

> Regarding your actual question, I do understand your idea and while originally I had the same in mind (it really _is_ appealing!), I came up with a draft using the original `String.getChars()` signature instead, due to the following drawbacks:
>
> * There might exist (possibly lotsof) `CharSequence.getChars(int, int, char[], int)` implementations already, as this problem (and the idea how to solve it) is anything but new. At least such implementations are `String`, `StringBuilder` and `StringBuffer`. If we come up with a different signature, then **none** of these already existing performance boosters will get used by `Reader.of(CharSequence)` automatically - at least until they come up with alias methods. Effectively this leads to (possibly lots) of alias methods. At least it leads to alias methods in `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`. In contrast, when keeping the signature copied from `String.getChars`, chances are good that (possibly lots of) implementations will _instantly_ be supported by `Reader.of(CharSequence)` without alias methods. At least, `String`, `StringBuilder` and `StringBuffer` will be.
>
> * Since decades people are now very used to `StringBuilder.getChars(int, int, char[], int)`, so (possibly a lot of) people might simply _expect_ us to come up with that lengthy signature. These people might be rather confused (if not to say frustrated) when we now force them to write an intermediate `subSequence(int, int)` for something that was "such simple" before.
>
> * Custom implementations of `CharSequence.subSequence` could come up with the (performance-wise "bad") idea of creating **copies** instead of views. At least it seems like `AbstractStringBuilder` is doing that, so chances are "good" that custom libs will do that, too. For example, because they need it for safety. Or possibly, because they have a technical reason that _enforces_ a copy. That would (possibly massively, depending on the actual class) spoil the idea of performance-boosting this PR is actually all about.

Kindly asking for more comments! Something I am missing? Some good reason to *not* adopt my proposal?

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

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

From liach at openjdk.org  Mon Mar 17 02:23:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 02:23:53 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <h_Z8koBIigcLaNZcf0S4Jd70amEA4Bd-EMlaf1QSi8s=.41b8a6e2-fca1-44dd-8aa3-5091c8003e24@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <h_Z8koBIigcLaNZcf0S4Jd70amEA4Bd-EMlaf1QSi8s=.41b8a6e2-fca1-44dd-8aa3-5091c8003e24@github.com>
Message-ID: <ehVos8ZgyoObZ9oGLwf-J4qb8CbiE7RAg12tTCO5DmY=.8021f5d3-ca82-4ead-91c6-77732ab6593b@github.com>

On Sat, 15 Mar 2025 23:30:21 GMT, Markus KARG <duke at openjdk.org> wrote:

> Some good reason to *not* adopt my proposal?

I am still afraid of such a pattern in the future like:

CharSequence cs = ...
if (cs.getClass().getModule() == Object.class.getModule()) {
    // or cs.getClass().getClassLoader() == null
    cs.getChars(...);
} else {
    // damn, can't trust an arbitrary char sequence!
    char[] intermediate = ...
    cs.getChars(...);
    // copy from intermediate etc.
}

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

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

From ecki at zusammenkunft.net  Mon Mar 17 04:19:57 2025
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 17 Mar 2025 05:19:57 +0100
Subject: RFR: 8343110: Add getChars(int, int, char[], int) to
 CharSequence and CharBuffer
In-Reply-To: <ehVos8ZgyoObZ9oGLwf-J4qb8CbiE7RAg12tTCO5DmY=.8021f5d3-ca82-4ead-91c6-77732ab6593b@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <h_Z8koBIigcLaNZcf0S4Jd70amEA4Bd-EMlaf1QSi8s=.41b8a6e2-fca1-44dd-8aa3-5091c8003e24@github.com>,
 <ehVos8ZgyoObZ9oGLwf-J4qb8CbiE7RAg12tTCO5DmY=.8021f5d3-ca82-4ead-91c6-77732ab6593b@github.com>
Message-ID: <B02FCB31-7D2D-1B4B-A20C-2FEED3058325@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250317/11f3c704/attachment.htm>

From duke at openjdk.org  Sat Mar 22 17:51:08 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 22 Mar 2025 17:51:08 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <8iJ24isAEwUY9kICOH6Ea1hXarBPAMenBSR1lP_R7T4=.f316c483-d986-44e6-9ece-fa204372de49@github.com>

On Sat, 26 Oct 2024 15:48:11 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.

Chen,

I do see your point and like to ask everybody to chime in and comment about the alternatives we have. In the end, we need to hear more people than just the two of us to decide *which* of both alternatives to finally implement:


* Alternative A: `CharSequence::getChars(int, int, char[], int)` - Fast, but as risky as `Reader::read(char[], int, int len)`

This alternative provides best possible performance, but rogue implementations of `CharSequence::getChars(int, int, char[], int)` might access the passed array *beyond* the requested limits. This allows poisoning and spying.

There already are APIs in the JRE which pose that exact risk *since very long time*: `Reader::read(char[], int, int len)`, just as one example, exists since Java 1.x, so there could exist lots of rogue custom `Reader` implementations already. As a consequence, IMHO we can expect Java developers to be very familiar with this kind of risk (and to have set up strategies to deal with it) *for decades*. As those rogue `Reader`s *already could* exist, developers *unaware* of this kind of risk actually are in very big trouble *already*. Hence IMHO de-facto we gain *nothing* if we prevent a well-known risk at point B that exists since 30 years at point A. *Iff* we really want to get rid of that kind of risk, we need to talk about adding array-views/sub-arrays to the Java language (which is illusory *in the next years*) or about removing existing core APIs (which is illusory *absolutely*).

Developers will tackle this risk at `CharSequence::getChars` just in the very same way as they did it for 30 years at `Reader::read`: Either they bear the risk, or they go with the code you proposed (intermediate array-copy in untrusted cases). The JRE itself even does that internally, see https://github.com/openjdk/jdk/commit/b0d145097cdc61e4bab19393a125e63aa3bc29b9 for example.


* Alternative B: `CharSequence::subsequence(int, int).getChars(char[], int)` - Risk-free but possibly very slow

This implementation prevents the risk implied by Alternative A, but for the price of an additional (possibly expensive) copy performed *always* (*not just* in the untrusted case). While JIT eventually *might* optimize away this costs for *some* implementations, it might *not* for interpreted code, non-HotSpot JVMs, or I/O-bound implementations. `CharSequence` implementations *are not forced to* hold its data in-memory. In the I/O-bound case, imposing `subsequence` *might* possibly impose *even worse* performance than a loop over `getChar(int)` (assumption in this example: I/O duplication forces I/O writes/flushes, but I/O loop-over-read-char will fill a buffer once and read from that). As this new API proposal *solely* is about improving performance, this actually would be counter-productive.


My personal conclusion is: As the risk exists since 30 years, it will not be a problem for developers. Let's pave the way for performance.

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

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

From duke at openjdk.org  Sat Mar 22 18:26:11 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 22 Mar 2025 18:26:11 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <jD6G_XcaP_RU1CfY6dgqKX1iMHLEuFP96-U7wOGSmB0=.19cc63ba-286f-43dd-89cc-f1a8f3117d40@github.com>

On Sat, 26 Oct 2024 15:48:11 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.

Alternative C: `sealed interface TrustedCharSource permits String, AbstractStringBuilder, CharBuffer { void getChars(int, int, char[], int) }`

As a mix of Alternative A and Alternative B we could provide a sealed interface, allowing the fast-path implementation *solely* for the JRE-internal `CharSequence` implementations, while all custom implementations go with `.subsequence(int, int).getChar(char[], int)`.

This solution would allow to have best possible performance for the JRE-internal classes, while custom classes can be accessed safely but (possibly very) slowly only.

Personally still voting for Alternative A, but if I am the only one, I'd rather go with C than B.

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

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

From liach at openjdk.org  Sun Mar 23 06:46:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Mar 2025 06:46:16 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <e_sDIALtDdgcOyjd83ag2hxm8PU3oyGagW8y1fgwLXc=.8edc4535-604f-4154-a6aa-e3a0034d468d@github.com>

On Sat, 26 Oct 2024 15:48:11 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.

Indeed, we can go with Alternative A. I wondered if it's fine to leak the backing array of a `CharBuffer` to an untrusted `CharSequence` but `Reader` already does so, so I think we should be fine there.

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

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

From duke at openjdk.org  Sun Mar 23 08:03:07 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 23 Mar 2025 08:03:07 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <e_sDIALtDdgcOyjd83ag2hxm8PU3oyGagW8y1fgwLXc=.8edc4535-604f-4154-a6aa-e3a0034d468d@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <e_sDIALtDdgcOyjd83ag2hxm8PU3oyGagW8y1fgwLXc=.8edc4535-604f-4154-a6aa-e3a0034d468d@github.com>
Message-ID: <7sy3jcziZ7SMLQ2mVlWGzbHnnmJpy-eVbLcwVMuVV4U=.efcc128e-59f5-4f77-8092-f9b62e88ff3a@github.com>

On Sun, 23 Mar 2025 06:43:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> Indeed, we can go with Alternative A.

Great to see that we finally found an agreement and nobody vetoed in the past months. ? 

As Alternative A actually is the current status already found in https://github.com/openjdk/jdk/pull/21730, and as PR 21730 started as a spin-off/follow-up from https://github.com/openjdk/jdk/pull/21371, kindly asking you and @jaikiran to officially review https://github.com/openjdk/jdk/pull/21730. ?

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

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

From liach at openjdk.org  Sun Mar 23 08:45:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 23 Mar 2025 08:45:15 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>

On Sat, 26 Oct 2024 15:48:11 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.

Oops sorry, did a round of review but forgot to finish it :(

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

> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
> 339:         Objects.checkFromToIndex(srcBegin, srcEnd, length());
> 340:         Objects.checkFromIndexSize(dstBegin, srcEnd - srcBegin, dst.length);

We can just do a `checkIndex(dstBegin, dst.length - (srcEnd - srcBegin) + 1)` as we know `srcEnd - srcBegin` is valid.

Also we should specify an NPE is thrown if `dst` is `null`. (Unforunately `compare` forgot this specification when it was added)

src/java.base/share/classes/java/nio/X-Buffer.java.template line 2356:

> 2354: #end[streamableType]
> 2355: 
> 2356: #if[char]

Can we merge this with `// -- Other char stuff --` on line 1895?

On a side note, we can optimize a lot of Appendable operations that transfer from CharSequence on CharBuffer; don't know if you wish to have it in this RFE or another.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2746093864
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2009009532
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2009009662

From duke at openjdk.org  Sun Mar 23 10:37:47 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 23 Mar 2025 10:37:47 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v2]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <PmbteuXZLXbE98uFYPg_z5-ndIo9NHyQVCujzDOuYkw=.539b7993-32d7-4a45-b6d7-4fe35fc88cff@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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/60a891b9..a3c2add9

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

  Stats: 46 lines in 2 files changed: 22 ins; 23 del; 1 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  Sun Mar 23 10:37:47 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 23 Mar 2025 10:37:47 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>
Message-ID: <rn1N9KI8_G8I28u6on9qzPkaLZAeRFTdufzX3277AWQ=.922a264b-138f-4ed6-bb79-23f9c943c4a3@github.com>

On Sun, 23 Mar 2025 08:42:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> Oops sorry, did a round of review but forgot to finish it :(

No problem. I had the same problem several times before. ?

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

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

From duke at openjdk.org  Sun Mar 23 10:37:49 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 23 Mar 2025 10:37:49 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v2]
In-Reply-To: <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>
Message-ID: <xwbb5ca_YJYDiR_PHUQAKEsLizTU1DEOl_o783zJsAs=.9831c39c-2205-4980-a7d5-57b10ec88710@github.com>

On Sun, 23 Mar 2025 04:34:29 GMT, Chen Liang <liach 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
>
> src/java.base/share/classes/java/lang/CharSequence.java line 340:
> 
>> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
>> 339:         Objects.checkFromToIndex(srcBegin, srcEnd, length());
>> 340:         Objects.checkFromIndexSize(dstBegin, srcEnd - srcBegin, dst.length);
> 
> We can just do a `checkIndex(dstBegin, dst.length - (srcEnd - srcBegin) + 1)` as we know `srcEnd - srcBegin` is valid.
> 
> Also we should specify an NPE is thrown if `dst` is `null`. (Unforunately `compare` forgot this specification when it was added)

Fixed in a3c2add9c16e4c7331c5a7c2848f27b6c0330a17

> src/java.base/share/classes/java/nio/X-Buffer.java.template line 2356:
> 
>> 2354: #end[streamableType]
>> 2355: 
>> 2356: #if[char]
> 
> Can we merge this with `// -- Other char stuff --` on line 1895?
> 
> On a side note, we can optimize a lot of Appendable operations that transfer from CharSequence on CharBuffer; don't know if you wish to have it in this RFE or another.

Fixed in a3c2add9c16e4c7331c5a7c2848f27b6c0330a17.

Let's finish this PR first. After that I would be happy to author another PR with all the optimizations you tell me. ?

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

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

From liach at openjdk.org  Mon Mar 24 02:53:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 02:53:12 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v2]
In-Reply-To: <PmbteuXZLXbE98uFYPg_z5-ndIo9NHyQVCujzDOuYkw=.539b7993-32d7-4a45-b6d7-4fe35fc88cff@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <PmbteuXZLXbE98uFYPg_z5-ndIo9NHyQVCujzDOuYkw=.539b7993-32d7-4a45-b6d7-4fe35fc88cff@github.com>
Message-ID: <iyognApik2U76cEXAP_z-wZ6xPuD1uFOZ6s0aeMAZFc=.e4c0cdac-d3c1-48b1-83fd-b3b7189db862@github.com>

On Sun, 23 Mar 2025 10:37:47 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

src/java.base/share/classes/java/nio/X-Buffer.java.template line 1911:

> 1909:      * @implNote This method allows for superior performance over the default
> 1910:      * implementation in {@code CharSequence}. It performs a direct
> 1911:      * buffer-to-array copy of the complete specified region.

I think the API and implementation notes are redundant.

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

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

From duke at openjdk.org  Mon Mar 24 11:41:16 2025
From: duke at openjdk.org (Markus KARG)
Date: Mon, 24 Mar 2025 11:41:16 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v2]
In-Reply-To: <iyognApik2U76cEXAP_z-wZ6xPuD1uFOZ6s0aeMAZFc=.e4c0cdac-d3c1-48b1-83fd-b3b7189db862@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <PmbteuXZLXbE98uFYPg_z5-ndIo9NHyQVCujzDOuYkw=.539b7993-32d7-4a45-b6d7-4fe35fc88cff@github.com>
 <iyognApik2U76cEXAP_z-wZ6xPuD1uFOZ6s0aeMAZFc=.e4c0cdac-d3c1-48b1-83fd-b3b7189db862@github.com>
Message-ID: <9FfCGWZkYdGtJ_0VupZMR4qQTgEm2B9Ii_zFdbi8Y0U=.36fae6bd-7fe4-4347-91af-db6b7fa24ddc@github.com>

On Mon, 24 Mar 2025 02:50:04 GMT, Chen Liang <liach 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
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1911:
> 
>> 1909:      * @implNote This method allows for superior performance over the default
>> 1910:      * implementation in {@code CharSequence}. It performs a direct
>> 1911:      * buffer-to-array copy of the complete specified region.
> 
> I think the API and implementation notes are redundant.

Do you think? The `implNote` here explains that it *actually* provides superior performance, while that API notes do say nothing about *actual* implementation. Anyways, I have no strong feelings. Shall I remomve it? ?

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

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

From duke at openjdk.org  Mon Mar 24 11:55:27 2025
From: duke at openjdk.org (Markus KARG)
Date: Mon, 24 Mar 2025 11:55:27 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v3]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <cp-V6xOhI9Zbi71rxRTf89zq20fzwkJYeTcGQoy0ioQ=.8942f9c8-8831-4252-ae27-a4eedb4a084b@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:

  Removed apiNote and implNote from CharBuffer, as suggested by Chen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/a3c2add9..d27d1bd8

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

  Stats: 8 lines in 1 file changed: 0 ins; 8 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  Mon Mar 24 11:55:28 2025
From: duke at openjdk.org (Markus KARG)
Date: Mon, 24 Mar 2025 11:55:28 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v2]
In-Reply-To: <9FfCGWZkYdGtJ_0VupZMR4qQTgEm2B9Ii_zFdbi8Y0U=.36fae6bd-7fe4-4347-91af-db6b7fa24ddc@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <PmbteuXZLXbE98uFYPg_z5-ndIo9NHyQVCujzDOuYkw=.539b7993-32d7-4a45-b6d7-4fe35fc88cff@github.com>
 <iyognApik2U76cEXAP_z-wZ6xPuD1uFOZ6s0aeMAZFc=.e4c0cdac-d3c1-48b1-83fd-b3b7189db862@github.com>
 <9FfCGWZkYdGtJ_0VupZMR4qQTgEm2B9Ii_zFdbi8Y0U=.36fae6bd-7fe4-4347-91af-db6b7fa24ddc@github.com>
Message-ID: <cgjkYnhgqFqu-lor8ttoJGFjtBomVTp2jyh6MJhN_-I=.fae9c18c-c7e6-4666-a985-6a955da9e9e4@github.com>

On Mon, 24 Mar 2025 11:38:58 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1911:
>> 
>>> 1909:      * @implNote This method allows for superior performance over the default
>>> 1910:      * implementation in {@code CharSequence}. It performs a direct
>>> 1911:      * buffer-to-array copy of the complete specified region.
>> 
>> I think the API and implementation notes are redundant.
>
> Do you think? The `implNote` here explains that it *actually* provides superior performance, while that API notes do say nothing about *actual* implementation. Anyways, I have no strong feelings. Shall I remomve it? ?

Fixed in https://github.com/openjdk/jdk/pull/21730/commits/d27d1bd85458f02e859a9653805d96ff79473124

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

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

From duke at openjdk.org  Tue Mar 25 12:09:21 2025
From: duke at openjdk.org (Markus KARG)
Date: Tue, 25 Mar 2025 12:09:21 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <E2FbCSNwAZXYB_bmu_Gu5hvtKqivVUuYw5_qSTKM3e0=.0368f50d-340f-49a4-9fbe-5c4cf869817a@github.com>
Message-ID: <Q9GKDFGqe4uLUIHPeZHaCipS0RCHeSK-uFI79bNqkMY=.fbc46d64-1241-4cba-95d7-9405471880f3@github.com>

On Sun, 23 Mar 2025 08:42:55 GMT, Chen Liang <liach 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.
>
> Oops sorry, did a round of review but forgot to finish it :(

@liach I fixed all your requested changes. Would you please be so kind and mark this PR as reviewed? I will then go on with the CSR.

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

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

From alanb at openjdk.org  Tue Mar 25 13:37:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 25 Mar 2025 13:37:18 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v3]
In-Reply-To: <cp-V6xOhI9Zbi71rxRTf89zq20fzwkJYeTcGQoy0ioQ=.8942f9c8-8831-4252-ae27-a4eedb4a084b@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <cp-V6xOhI9Zbi71rxRTf89zq20fzwkJYeTcGQoy0ioQ=.8942f9c8-8831-4252-ae27-a4eedb4a084b@github.com>
Message-ID: <-kmmMFIYxB1MuVisVzYwZfVa2EVTs5cYjSZitihD-Ek=.5dd5d4ab-f141-4279-ae5f-2fd9c78735ea@github.com>

On Mon, 24 Mar 2025 11:55:27 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:
> 
>   Removed apiNote and implNote from CharBuffer, as suggested by Chen

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

> 305:     /**
> 306:      * Characters are copied from this sequence into the
> 307:      * destination character array {@code dst}. The first character to

I think the "Characters are copied ..." sentence goes back to StringBuffer in JDK 1.0. CS doesn't need to copy this exactly and I think better to say that it copies chars from this sequence into the given destination array.

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

> 333:      *
> 334:      * @implSpec
> 335:      * The default implementation iterates over {@link #charAt(int)}.

This sentence doesn't make sense, did something get deleted?

src/java.base/share/classes/java/nio/X-Buffer.java.template line 1900:

> 1898: 
> 1899:     /**
> 1900:      * {@inheritDoc}

The method description here will need to start with  "Absolute bulk get method". This is important because CB defines both "absolute bulk get" and "relative bulk get methods", it has to be very clear in the API docs.

If the proposal goes again then I think the method description won't be inherited into CB, instead it will say that it transfers chars from this buffer into the given destination array.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2012114639
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2012116378
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2012054339

From duke at openjdk.org  Wed Mar 26 11:37:22 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 26 Mar 2025 11:37:22 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v3]
In-Reply-To: <-kmmMFIYxB1MuVisVzYwZfVa2EVTs5cYjSZitihD-Ek=.5dd5d4ab-f141-4279-ae5f-2fd9c78735ea@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <cp-V6xOhI9Zbi71rxRTf89zq20fzwkJYeTcGQoy0ioQ=.8942f9c8-8831-4252-ae27-a4eedb4a084b@github.com>
 <-kmmMFIYxB1MuVisVzYwZfVa2EVTs5cYjSZitihD-Ek=.5dd5d4ab-f141-4279-ae5f-2fd9c78735ea@github.com>
Message-ID: <3w3Y1U64Cp1b4bODfK5LEIkbj7HworPb84xKwOQSeYc=.afcc5e27-e142-4132-b4e5-ae79d14cdd59@github.com>

On Tue, 25 Mar 2025 13:33:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed apiNote and implNote from CharBuffer, as suggested by Chen
>
> src/java.base/share/classes/java/lang/CharSequence.java line 307:
> 
>> 305:     /**
>> 306:      * Characters are copied from this sequence into the
>> 307:      * destination character array {@code dst}. The first character to
> 
> I think the "Characters are copied ..." sentence goes back to StringBuffer in JDK 1.0. CS doesn't need to copy this exactly and I think better to say that it copies chars from this sequence into the given destination array.

Do you like this more: `Copies chars from this sequence into the given destination array.` ?

> src/java.base/share/classes/java/lang/CharSequence.java line 335:
> 
>> 333:      *
>> 334:      * @implSpec
>> 335:      * The default implementation iterates over {@link #charAt(int)}.
> 
> This sentence doesn't make sense, did something get deleted?

Do you like this more: `The default implementation invokes {@link #charAt(int)} in a loop.`?

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

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

From duke at openjdk.org  Wed Mar 26 11:40:16 2025
From: duke at openjdk.org (Markus KARG)
Date: Wed, 26 Mar 2025 11:40:16 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v3]
In-Reply-To: <-kmmMFIYxB1MuVisVzYwZfVa2EVTs5cYjSZitihD-Ek=.5dd5d4ab-f141-4279-ae5f-2fd9c78735ea@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <cp-V6xOhI9Zbi71rxRTf89zq20fzwkJYeTcGQoy0ioQ=.8942f9c8-8831-4252-ae27-a4eedb4a084b@github.com>
 <-kmmMFIYxB1MuVisVzYwZfVa2EVTs5cYjSZitihD-Ek=.5dd5d4ab-f141-4279-ae5f-2fd9c78735ea@github.com>
Message-ID: <_Vz4XZ6zJOWBunhdQ4wldLu2QqxUi1xPaFRs57tab44=.e3e7161b-ffd3-42ae-a673-664336c78b22@github.com>

On Tue, 25 Mar 2025 13:06:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed apiNote and implNote from CharBuffer, as suggested by Chen
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1900:
> 
>> 1898: 
>> 1899:     /**
>> 1900:      * {@inheritDoc}
> 
> The method description here will need to start with  "Absolute bulk get method". This is important because CB defines both "absolute bulk get" and "relative bulk get methods", it has to be very clear in the API docs.
> 
> If the proposal goes again then I think the method description won't be inherited into CB, instead it will say that it transfers chars from this buffer into the given destination array.

IIUC then you want me to replace `{@inheritedDoc}` by `This absolute bulk get method transfers chars from this buffer into the given destination array.`?

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

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

From varadam at openjdk.org  Thu Mar 27 12:44:40 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 12:44:40 GMT
Subject: RFR: 8353053: UserDefinedFileAttributeView not supported on AIX
Message-ID: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@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)

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

Commit messages:
 - UserDefinedFileAttributeView not supported on AIX
 - UserDefinedFileAttributeView not supported on AIX
 - UserDefinedFileAttributeView not supported on AIX
 - UserDefinedFileAttributeView for AIX

Changes: https://git.openjdk.org/jdk/pull/24276/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24276&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353053
  Stats: 118 lines in 6 files changed: 104 ins; 6 del; 8 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  Thu Mar 27 13:02:18 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 13:02:18 GMT
Subject: RFR: 8353053: UserDefinedFileAttributeView not supported 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: <4vwDv7WgmBMDFJoPfd-6x1tLac9Am8AwdD3eaoVKmBU=.067af3d9-f4ba-4352-825f-09f7816c3184@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)

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

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

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

From varadam at openjdk.org  Thu Mar 27 13:19:07 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 13:19:07 GMT
Subject: RFR: 8353053: (fs) Add support for UserDefinedFileAttributeView on
 AIX [v2]
In-Reply-To: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
References: <tFH0_6EQmohWhTYSqHGQs2bfDJ6Wpwisn8uiYdHU044=.7d2ed4b6-692d-49f9-a761-74b8fd71a5de@github.com>
Message-ID: <925da2UeOLLmSZoxeEzzs1or83qbFMVSALQ086cLu0o=.90d49c15-8de4-4587-aae8-b764c66f692e@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 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

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

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

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

  Stats: 56663 lines in 1700 files changed: 14104 ins; 35720 del; 6839 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  Thu Mar 27 16:54:40 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 16:54:40 GMT
Subject: Withdrawn: 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: <0Qrb_YB7pCfvAqXY8NNpeXM_ZU_ktvRBqHqpLXhux8I=.ae5f1900-8b81-4d6e-85d8-7f411ad06a64@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 been closed without being integrated.

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

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

From duke at openjdk.org  Sat Mar 29 10:09:25 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 29 Mar 2025 10:09:25 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v4]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <Kh7hB1QjrN-oaqQHu4SCkt0HY_3C4EmDKAkypBG8C2s=.755f8adb-b4f9-4cf1-8ea3-9ac3b7f75943@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 three additional commits since the last revision:

 - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
 - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
 - Replaced JavaDocs of CharBuffer, as suggested by Alan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/d27d1bd8..a5d26c5b

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

  Stats: 33 lines in 2 files changed: 26 ins; 1 del; 6 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  Sat Mar 29 10:09:26 2025
From: duke at openjdk.org (Markus KARG)
Date: Sat, 29 Mar 2025 10:09:26 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v3]
In-Reply-To: <3w3Y1U64Cp1b4bODfK5LEIkbj7HworPb84xKwOQSeYc=.afcc5e27-e142-4132-b4e5-ae79d14cdd59@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <cp-V6xOhI9Zbi71rxRTf89zq20fzwkJYeTcGQoy0ioQ=.8942f9c8-8831-4252-ae27-a4eedb4a084b@github.com>
 <-kmmMFIYxB1MuVisVzYwZfVa2EVTs5cYjSZitihD-Ek=.5dd5d4ab-f141-4279-ae5f-2fd9c78735ea@github.com>
 <3w3Y1U64Cp1b4bODfK5LEIkbj7HworPb84xKwOQSeYc=.afcc5e27-e142-4132-b4e5-ae79d14cdd59@github.com>
Message-ID: <N7cxjyeu30uRQioRZUs8eUnzgtidvUfuIELp9XpUQqI=.a2815994-baae-43ee-8b34-d9a78fb62877@github.com>

On Wed, 26 Mar 2025 11:34:34 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 307:
>> 
>>> 305:     /**
>>> 306:      * Characters are copied from this sequence into the
>>> 307:      * destination character array {@code dst}. The first character to
>> 
>> I think the "Characters are copied ..." sentence goes back to StringBuffer in JDK 1.0. CS doesn't need to copy this exactly and I think better to say that it copies chars from this sequence into the given destination array.
>
> Do you like this more: `Copies chars from this sequence into the given destination array.` ?

Thank you, Alan. Fixed in https://github.com/openjdk/jdk/pull/21730/commits/a7f56f4ecba4be1a28e551e8a247998db7d7cb79.

>> src/java.base/share/classes/java/lang/CharSequence.java line 335:
>> 
>>> 333:      *
>>> 334:      * @implSpec
>>> 335:      * The default implementation iterates over {@link #charAt(int)}.
>> 
>> This sentence doesn't make sense, did something get deleted?
>
> Do you like this more: `The default implementation invokes {@link #charAt(int)} in a loop.`?

Thank you, Alan. Fixed in https://github.com/openjdk/jdk/pull/21730/commits/a5d26c5bc143e37520e5f42bcb0299d4e12784b0.

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1900:
>> 
>>> 1898: 
>>> 1899:     /**
>>> 1900:      * {@inheritDoc}
>> 
>> The method description here will need to start with  "Absolute bulk get method". This is important because CB defines both "absolute bulk get" and "relative bulk get methods", it has to be very clear in the API docs.
>> 
>> If the proposal goes again then I think the method description won't be inherited into CB, instead it will say that it transfers chars from this buffer into the given destination array.
>
> IIUC then you want me to replace `{@inheritedDoc}` by `This absolute bulk get method transfers chars from this buffer into the given destination array.`?

Thank you, Alan. Fixed in https://github.com/openjdk/jdk/pull/21730/commits/29e1521fa25ba88dbbe4af077888044666f790f6.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2019766905
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2019766966
PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r2019766823

From liach at openjdk.org  Sat Mar 29 23:57:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 29 Mar 2025 23:57:11 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v4]
In-Reply-To: <Kh7hB1QjrN-oaqQHu4SCkt0HY_3C4EmDKAkypBG8C2s=.755f8adb-b4f9-4cf1-8ea3-9ac3b7f75943@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <Kh7hB1QjrN-oaqQHu4SCkt0HY_3C4EmDKAkypBG8C2s=.755f8adb-b4f9-4cf1-8ea3-9ac3b7f75943@github.com>
Message-ID: <78qX302fm10go5629tdt3A0JY_JucbJzDiKK20JByNU=.e07d30c3-bf6f-4e6e-8fbd-d58b5de59b19@github.com>

On Sat, 29 Mar 2025 10:09:25 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 three additional commits since the last revision:
> 
>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>  - Replaced JavaDocs of CharBuffer, as suggested by Alan

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

> 333:      * @implSpec
> 334:      * The default implementation invokes {@link #charAt(int index)} in a loop
> 335:      * iterating {@code index} from {@code srcBegin} to {@code srcEnd-1}

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)

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

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

From duke at openjdk.org  Sun Mar 30 12:34:06 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 30 Mar 2025 12:34:06 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v5]
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <o1H1Gp_ShhCxTpw_9NcNCTG6ECkhafGvd2AkoTaKz58=.1ee78c1e-2f94-4fb2-a7e8-61f3d5213179@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: '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)'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21730/files
  - new: https://git.openjdk.org/jdk/pull/21730/files/a5d26c5b..d2ccf42c

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

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 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  Sun Mar 30 12:34:07 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 30 Mar 2025 12:34:07 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v4]
In-Reply-To: <78qX302fm10go5629tdt3A0JY_JucbJzDiKK20JByNU=.e07d30c3-bf6f-4e6e-8fbd-d58b5de59b19@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <Kh7hB1QjrN-oaqQHu4SCkt0HY_3C4EmDKAkypBG8C2s=.755f8adb-b4f9-4cf1-8ea3-9ac3b7f75943@github.com>
 <78qX302fm10go5629tdt3A0JY_JucbJzDiKK20JByNU=.e07d30c3-bf6f-4e6e-8fbd-d58b5de59b19@github.com>
Message-ID: <YEHDD4jQgNlWU2fPyAZC2FxXYS4WecgwG2JF53fCZg0=.d4d1f2cb-98f4-49f0-a46e-d6fccac737cc@github.com>

On Sat, 29 Mar 2025 23:53:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Applied changes requested by Alan: This sentence doesn't make sense, did something get deleted?
>>  - Applied changes requested by Alan: Copies chars from this sequence into the given destination array
>>  - Replaced JavaDocs of CharBuffer, as suggested by Alan
>
> src/java.base/share/classes/java/lang/CharSequence.java line 335:
> 
>> 333:      * @implSpec
>> 334:      * The default implementation invokes {@link #charAt(int index)} in a loop
>> 335:      * iterating {@code index} from {@code srcBegin} to {@code srcEnd-1}
> 
> 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)

Good idea. Added clarification in https://github.com/openjdk/jdk/pull/21730/commits/d2ccf42cec148a86b17753d160df211925f75858.

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

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