{@code
> 313:      * dstbegin + (srcEnd-srcBegin) - 1

Shouldn't it be dstBegin?

* dstBegin + (srcEnd-srcBegin) - 1

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

> 327:      *             {@code this.length()}.
> 328:      *             {@code dstBegin+srcEnd-srcBegin} is greater than
> 329:      *             {@code dst.length}

I think we should have `.` at the end of each case. Now it's inconsistent

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

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

From bpb at openjdk.org  Fri May  9 22:32:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 22:32:50 GMT
Subject: RFR: 8356127: (fs) UnixFileSystemProvider.implDelete could save a
 syscall in some cases [v3]
In-Reply-To: 
References: <__DpX8NhzRrLcm-Ev8Z7HovPQqJolMCEcWerlNYvyUg=.9e95dad9-640b-4ebb-9dae-977c216dc3ce@github.com>

 <_tmc-y1SKXOJbqGypPX5JNi6dzDvhrgv41VwpzxK_7A=.8c2dd1c1-aeb7-4771-a357-f093b84341ee@github.com>

 <8mOBk56Zaqo1KTinUbQm0QrLq-xL21mUjaf4O5AuSiE=.ef062a83-cd68-4137-9a72-c309fcf6f1bf@github.com>

 <_grJggFbxOgB93F8aKoWKNXJw_qyfIo5iqZXs37kLMY=.425b9fd3-b2f9-4701-82ba-7fada1b86e74@github.com>

Message-ID: 

On Fri, 9 May 2025 17:01:09 GMT, Alan Bateman  wrote:

>>> It might be worth digging into how this works in NFS environments.
>> 
>> I will try to assess this.
>
> I have a vague memory that NFSv4 had changes in this area to allow the REMOVE RPC handle any file type. Getting an up to date summary on that would be helpful as it may be that the change here will only work on local file systems.

A safer approach would be to remove the capability check and not to rely on the value of `errno` at all.

        boolean isDirectory = false;
        try {
            try {
                // assume the common case that the file is a regular file
                unlink(file);
            } catch (UnixException e) {
                // check whether the file is a directory and, if so,
                // try rmdir, otherwise re-throw and let the exception
                // be handled below
                isDirectory = UnixFileAttributes.get(file, false).isDirectory();
                if (isDirectory) {
                    rmdir(file);
                } else {
                    throw e;
                }   
            }
            return true;
        } catch (UnixException x) {
            // .... handle the exception ...
        }

Of course this would be at the expense of a `stat` if the `unlink` fails, but that would at least be avoided for the common case of deleting a regular file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25107#discussion_r2082574592

From bpb at openjdk.org  Fri May  9 22:49:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 22:49:27 GMT
Subject: RFR: 8351415: (fs) Path::toAbsolutePath should specify if an absolute
 path has a root component
Message-ID: 

Add a sentence to the specification of `Path::toAbsolutePath` indicating that the root component of the absolute path derived from a `Path` associated with the default provider is non-`null`.

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

Commit messages:
 - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component

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

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

From bpb at openjdk.org  Fri May  9 22:53:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 May 2025 22:53:15 GMT
Subject: RFR: 8356606: PosixFileAttributes.permissions() implementations should
 return an EnumSet
Message-ID: 

Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

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

Commit messages:
 - 8356606: PosixFileAttributes.permissions() implementations should return an EnumSet

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

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

From liach at openjdk.org  Fri May  9 23:05:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 May 2025 23:05:49 GMT
Subject: RFR: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 May 2025 22:48:11 GMT, Brian Burkhalter  wrote:

> Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

Makes sense. This rejects usages of adding null or invalid objects, but this still abides to the specs, that the returned set can be modified and passed to create new attributes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25162#pullrequestreview-2829850578

From alanb at openjdk.org  Sat May 10 06:22:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 May 2025 06:22:54 GMT
Subject: RFR: 8356606: (fs) PosixFileAttributes.permissions()
 implementations should return an EnumSet
In-Reply-To: 
References: 
Message-ID: <7A00QvaDBh5e5xuvoysuQJCFPLgNW_7O7_55iOLREGU=.f99914f1-ff2f-4ce3-aa26-bec178fd9087@github.com>

On Fri, 9 May 2025 22:48:11 GMT, Brian Burkhalter  wrote:

> Drop-in replacement in `sun.nio.fs.UnixFileAttributes::permissions` of `HashSet` with `EnumSet` for hopefully improved efficiency. All tests containing `PosixFileAttributes` passed.

I assume reading POSIX file permissions is going to be dominated by stat/equivalent, it might be that the JBS issue was more of a suggestion from someone reading the code?

In any case, it looks fine and I assume you'll run the jdk_nio tests.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25162#pullrequestreview-2830393769

From alanb at openjdk.org  Sat May 10 08:07:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 May 2025 08:07:51 GMT
Subject: RFR: 8356127: (fs) UnixFileSystemProvider.implDelete could save a
 syscall in some cases [v5]
In-Reply-To: 
References: <__DpX8NhzRrLcm-Ev8Z7HovPQqJolMCEcWerlNYvyUg=.9e95dad9-640b-4ebb-9dae-977c216dc3ce@github.com>

Message-ID: 

On Fri, 9 May 2025 16:56:09 GMT, Brian Burkhalter  wrote:

>> Modify `UnixFileSystemProvider.implDelete` to attempt first to delete the file using `unlink` and, if that fails, fall back to using `rmdir` if the file is a directory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356127: Tweak previous commit

I think we have to cautious and spend more time understanding the behavior of unlink with non-empty directories. I'm pretty sure that back in SunOS and UFS days that a non-empty directory could be unlinked, think cleanup when doing the next fsck. I understand that the proposal is do this on Linux only and it will work for local file systems. However, it is not clear to me that this is reliable with remote file systems. NFSv4 did make changes to support exactly what it is doing proposed but I worry there are other remote file systems where we might not get the ENOTEMPTY. Doing a statvfs to check the file system type would work but probably more expensive that the stat that we do now to check if the file is a directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/25107#issuecomment-2868618444

From jpai at openjdk.org  Mon May 12 01:20:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 May 2025 01:20:07 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer [v12]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 May 2025 20:35:04 GMT, Andrey Turbanov  wrote:

>> Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - merge latest from master branch
>>  - Applied proposal by Daniel: If there's no change to this file the copyright year update could be reverted?
>>  - Applied workaround proposed by Joe: Using component @inheritDoc to enforce getChars section in JavaDocs
>>  - Applied changes proposed by Joe and Jaikiran: Using @inheritDoc to get JavaDocs without @since.
>>  - Applied changes proposed in response to Joe's CSR comments: 'understood for CharBuffer; I was thinking more of String, StringBuffer, and StringBuilder where there looks to be more textual similarities.'
>>  - Applied changes requestes by Alan: Aligning unit test for CharBuffer.getChars() with unit test for CharBuffer.chars()
>>  - Applied changes requested by Chen and Jaikiran: Unit tests for default implementation of CharSequence.getChars() and for CharBuffer.getChars()
>>  - 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)'
>>  - 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
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/b21b3a38...31537b7a
>
> src/java.base/share/classes/java/lang/CharSequence.java line 313:
> 
>> 311:      * at index {@code dstBegin} and ending at index:
>> 312:      * {@code
>> 313:      * dstbegin + (srcEnd-srcBegin) - 1
> 
> Shouldn't it be dstBegin?
> 
> * dstBegin + (srcEnd-srcBegin) - 1

Hello Andrey, what you note is right. This and the other change you have proposed to this text seems reasonable. Do you want to create a JBS issue and raise a PR proposing this change?

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

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

From alanb at openjdk.org  Mon May 12 07:35:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 May 2025 07:35:52 GMT
Subject: RFR: 8351415: (fs) Path::toAbsolutePath should specify if an
 absolute path has a root component
In-Reply-To: 
References: 
Message-ID: 

On Fri, 9 May 2025 22:44:04 GMT, Brian Burkhalter  wrote:

> Add a sentence to the specification of `Path::toAbsolutePath` indicating that the root component of the absolute path derived from a `Path` associated with the default provider is non-`null`.

I think it is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25161#pullrequestreview-2832128143