From swen at openjdk.org  Tue Jul  1 00:01:21 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 00:01:21 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
Message-ID: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>

> BufferedWriter -> OutputStreamWriter -> StreamEncoder
> 
> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
> 
> LATIN1 -> UTF16 -> UTF8
> 
> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.

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

  Revert "BufferedWriter buffer use StringBuilder"
  
  This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26022/files
  - new: https://git.openjdk.org/jdk/pull/26022/files/da902ca0..fccd9678

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

  Stats: 81 lines in 6 files changed: 31 ins; 32 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/26022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26022/head:pull/26022

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

From duke at openjdk.org  Tue Jul  1 00:01:21 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 1 Jul 2025 00:01:21 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
Message-ID: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>

On Mon, 30 Jun 2025 23:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BufferedWriter buffer use StringBuilder

What about a benchmark which exercises the actual benefits of buffering?
So many very small writes to a backing OutputStream which is (artificially) slow.
Perhaps have an OutputStream which sleeps 1ms on every call.
The write out more than 8k of data in chunks of less than 8 chars at a time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021204155

From swen at openjdk.org  Tue Jul  1 00:12:40 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 00:12:40 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
Message-ID: <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>

On Mon, 30 Jun 2025 23:57:45 GMT, Brett Okken <duke at openjdk.org> wrote:

> What about a benchmark which exercises the actual benefits of buffering? So many very small writes to a backing OutputStream which is (artificially) slow. Perhaps have an OutputStream which sleeps 1ms on every call. The write out more than 8k of data in chunks of less than 8 chars at a time.

In fact, StreamEncoder has a ByteBuffer that acts as a buffer, so when BufferedBuffer::out is an OutputStreamWirter encoded as UTF8, there is no need for two layers of buffer.


class BufferedWriter {
    Writer out
}

class OutputStreamWriter {
    StreamEncoder se;
}

class StreamEncoder {
    ByteBuffer bb;
}


We often use it like this:

new BufferedWriter(new OutputStreamWriter(out, UTF_8)))

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021227716

From sherman at openjdk.org  Tue Jul  1 00:45:47 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 1 Jul 2025 00:45:47 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

While I understand the motivation behind the PR, it's a bit challenging (as a reviewer) to agree a change that is essentially to 'break' the abstraction layer by surfacing a lower-level implementation to the top API solely for performance gains. 

It might be better to separate the 'backdoor UTF-8 path' optimization and the 'skip BufferedWriter' change as a first step to start the discussion?

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021289241

From duke at openjdk.org  Tue Jul  1 02:09:43 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 1 Jul 2025 02:09:43 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
 <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
Message-ID: <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>

On Tue, 1 Jul 2025 00:10:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> StreamEncoder has a ByteBuffer that acts as a buffer,

At a fixed sized of 512 bytes which cannot be affected by size passed into the BufferedWriter?

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021453158

From swen at openjdk.org  Tue Jul  1 02:16:39 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 02:16:39 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
 <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
 <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>
Message-ID: <ISQ8YWHEW37dp_fdCDLS89W2f4oGNp-sWQP7mBlgpgI=.11b8656f-16a1-4528-bb2c-7b6bb6f2846b@github.com>

On Tue, 1 Jul 2025 02:07:07 GMT, Brett Okken <duke at openjdk.org> wrote:

> > StreamEncoder has a ByteBuffer that acts as a buffer,
> 
> At a fixed sized of 512 bytes which cannot be affected by size passed into the BufferedWriter?

So I added this method StreamEncoder::growByteBufferIfEmptyNeeded and called it in the BufferedWriter constructor


    private BufferedWriter(Writer out, int initialSize, int maxSize) {
        // ...
        if (out instanceof OutputStreamWriter w && w.se.getCharset() == UTF_8.INSTANCE) {
            w.se.growByteBufferIfEmptyNeeded(initialSize);
            this.impl = new OutputStreamWriterImpl(w);
        }
        // ...
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021479496

From liach at openjdk.org  Tue Jul  1 02:35:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Jul 2025 02:35:41 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

I think we can split this into two parts:
1. Update buffering strategy for BufferedWriter when backing writer is an OutputStreamWriter
2. Use an alternative StreamDecoder impl if the CharsetDecoder is an ArrayDecoder

This should make the whole thing more clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021520629

From swen at openjdk.org  Tue Jul  1 02:41:37 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 02:41:37 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
Message-ID: <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>

On Tue, 1 Jul 2025 00:41:03 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> While I understand the motivation behind the PR, it's a bit challenging, as a reviewer :-) to review a change that is essentially to 'break' the abstraction layer by surfacing a lower-level implementation to the top API solely for performance gains. Maybe it's easier to add an impl note to suggest "it's no longer always a good idea to put a buffered writer on top of an osw", for example.
> 
> It might be better to separate the 'backdoor UTF-8 path' optimization and the 'skip BufferedWriter' change as a first step to start the discussion?

After the introduction of JEP 254 Compact Strings, many java.io-related codes need to be optimized for Compact Strings. If we plan to remove the option COMPACT_STRING = off, we should do these optimizations before that.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021532618

From sherman at openjdk.org  Tue Jul  1 04:00:39 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 1 Jul 2025 04:00:39 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
 <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>
Message-ID: <4sIiDHzczQCMWcgdUU-6uSmPgWm-5Xb66JYx-p0TfW0=.e56c5fcd-b182-402e-81b2-8c5094af331b@github.com>

On Tue, 1 Jul 2025 02:38:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> After the introduction of JEP 254 Compact Strings, many java.io-related codes need to be optimized for Compact Strings. If we plan to remove the option COMPACT_STRING = off, we should do these optimizations before that.

now you make me feel guilty :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021665074

From mdoerr at openjdk.org  Tue Jul  1 06:12:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 06:12:43 GMT
Subject: Integrated: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
Message-ID: <PRSQ74X9VapPKjj34wW_6j_iZiqVNQVrqPKnJ3Qab2M=.813509e8-38cb-4989-a368-4590bc6e6236@github.com>

On Fri, 27 Jun 2025 16:13:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
> 
> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924

This pull request has now been integrated.

Changeset: 0572b6ec
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0572b6ece7a77d13d23ac0c6d72d4fe5d5f0d944
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

8360887: (fs) Files.getFileAttributeView returns unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)

Co-authored-by: Joachim Kern <jkern at openjdk.org>
Reviewed-by: bpb, mbaesken

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

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

From alanb at openjdk.org  Tue Jul  1 06:28:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 06:28:47 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <_QMm6eFYxC0A2tcA-_kZPLj9KsBRVTX2rhPF1UvO-Mk=.25eb8a8c-0f0f-4b45-ad22-9429cb44cfe1@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 55:

> 53:     }
> 54: 
> 55:     static boolean supportsUserDefinedFileAttributeView(Path obj) {

I assume this can be private.

test/jdk/java/nio/file/FileStore/Basic.java line 113:

> 111:         if (!store1.supportsFileAttributeView(UserDefinedFileAttributeView.class) &&
> 112:             Files.getFileAttributeView(dir, UserDefinedFileAttributeView.class) != null) {
> 113:             throw new RuntimeException("UserDefinedFileAttributeView not supported, getFileAttributeView should return null");

I think it's okay to extend FileStore/Basic.java but to test Files.getFileAttributeView works consistent will require changes to test each of supported views. We shouldn't be testing UserDefinedFileAttributeView in isolation here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176531171
PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176527220

From alanb at openjdk.org  Tue Jul  1 06:32:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 06:32:45 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <SBWT8u9b1gTVxbxRqk-oXoxS4q--RF2QGWnXlBlgTxo=.35bbbee5-f4f1-496c-8971-fda7c161bd2f@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 57:

> 55:     static boolean supportsUserDefinedFileAttributeView(Path obj) {
> 56:         try {
> 57:             FileStore store = Files.getFileStore(obj);

This needs to be `new AixFileStore(obj)` rather than `Files.getFileStore` to avoid cycles. It might be that no one on AIX replaces the default provider but always have to avoid making use of the API in the API implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176536674

From mdoerr at openjdk.org  Tue Jul  1 06:36:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 06:36:55 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
Message-ID: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>

Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

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

Commit messages:
 - Backport 0572b6ece7a77d13d23ac0c6d72d4fe5d5f0d944

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

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

From alanb at openjdk.org  Tue Jul  1 06:46:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 06:46:45 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <EiGfvTcZ1RQN96bnyBfiP2YtT0BdDd23_EmY1C2HU_4=.4c871b97-d453-4187-b259-f732726ef3b0@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 72:

> 70:         if (type == UserDefinedFileAttributeView.class) {
> 71:             return !supportsUserDefinedFileAttributeView(obj) ? null :
> 72:                 (V) new AixUserDefinedFileAttributeView(UnixPath.toUnixPath(obj), Util.followLinks(options));

I think should this be inverted, meaning use supportsUserDefinedFileAttributeView instead of ! supportsUserDefinedFileAttributeView and it will be clear to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176561100

From mbaesken at openjdk.org  Tue Jul  1 07:25:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 07:25:39 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <Gq2v2qUPcXRK1_sg4KcXRYw8UoUKA-EP0YyskvSaCGY=.d8af36a8-4623-467c-9289-6d623a85c7f4@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26058#pullrequestreview-2973883897

From swen at openjdk.org  Tue Jul  1 09:20:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 09:20:43 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>
Message-ID: <qDMgvXPFu6XFFsV0CHd3rphymURjIZDLDZ3mNI-Rulo=.54657941-8784-4125-94ec-6642562ce1cb@github.com>

On Tue, 1 Jul 2025 02:33:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think we can split this into two parts:
> 
> 1. Update buffering strategy for BufferedWriter when backing writer is an OutputStreamWriter
> 2. Use an alternative StreamDecoder impl if the CharsetDecoder is an ArrayDecoder
> 
> This should make the whole thing more clear.

You are right. The current PR is the fast path optimization of UTF_8 OutputStreamWriter. For UTF_16/UTF_16LE/UTF_16BE, I submitted a draft pr 26034.

And for the buffer of BufferedWriter, if char[] is used, the encodeArrayLoop technique can be used in CharsetEncoder for optimization. If the buffer uses StringBuilder wrap as StringCharBuffer, StringCharBuffer cannot use encodeArrayLoop for optimization, which is the key point affecting performance.

| buffer type | CharBuffer type   | support arrayLoop |
| -- | -- | -- | 
| char[] | HeapCharBuffer | true |
| StringBuilder | StringCharBuffer | false |

Therefore, I recommend continuing to use char[] as buffer in BufferedWriter non-UTF_8 OutputStreamWriter scenarios.


If you are interested, you can take a look at the optimization of these two encodeArrayLoop:

* In UTF_8$Encoder

public final class UTF_8 extends Unicode {
    private static final class Encoder extends CharsetEncoder {
        protected final CoderResult encodeLoop(CharBuffer src,
                                               ByteBuffer dst)
        {
            if (src.hasArray() && dst.hasArray())
                return encodeArrayLoop(src, dst);
            else
                return encodeBufferLoop(src, dst);
        }
        // ...
	}
}


* UnicodeEncoder in PR #26034

public abstract class UnicodeEncoder extends CharsetEncoder {
  protected CoderResult encodeLoop(CharBuffer src, ByteBuffer dst) {
        if (src.hasArray() && dst.hasArray()) {
            return encodeArrayLoop(src, dst);
        }
        return encodeBufferLoop(src, dst);
    }

    private CoderResult encodeArrayLoop(CharBuffer src, ByteBuffer dst) {
        char[] sa = src.array();
        int soff = src.arrayOffset();
        int sp = soff + src.position();
        int sl = soff + src.limit();

        byte[] da = dst.array();
        int doff = dst.arrayOffset();
        int dp = doff + dst.position();
        int dl = doff + dst.limit();

        ....
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3022903336

From mdoerr at openjdk.org  Tue Jul  1 10:21:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 10:21:43 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <NF9OxLM9xE35UNho6MM-0IvDaS34syNIKvb-rDNmGlA=.a3acc029-7f41-4534-9721-b88c7379cadc@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3023206935

From alanb at openjdk.org  Tue Jul  1 10:25:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 10:25:39 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <xUtikxYCmGfwiOzQOQiz0Hjm0ihfIysCL_TknlJqwP8=.8714eaa0-d5a4-4fc9-963d-e3ae4afc78b5@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

The change in main line will need follow-up changes so I think hold off on any JDK 25 back ports for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3023226128

From mdoerr at openjdk.org  Tue Jul  1 10:26:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 10:26:45 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <ThOdbzZeIHhUuOdl57hekjlwQshqxyK8016pJYAwqoQ=.602773c1-865d-4ebf-bb3a-29f81cd25d2a@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

Sorry, I was a bit too fast. We need the fix in jdk25. I'll do a follow-up.

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

PR Comment: https://git.openjdk.org/jdk/pull/26021#issuecomment-3023235613

From mdoerr at openjdk.org  Tue Jul  1 10:30:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 10:30:43 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <FICTAd-FjCcYZ7PJEOaw7rb7ZwfZb_sTHdCcnQFaCJM=.f60dcd3a-d796-4674-9017-d677553907ab@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

I'll wait until the follow-up is ready. Thanks, Alan!

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3023257990

From mdoerr at openjdk.org  Tue Jul  1 12:08:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:08:46 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <SBWT8u9b1gTVxbxRqk-oXoxS4q--RF2QGWnXlBlgTxo=.35bbbee5-f4f1-496c-8971-fda7c161bd2f@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
 <SBWT8u9b1gTVxbxRqk-oXoxS4q--RF2QGWnXlBlgTxo=.35bbbee5-f4f1-496c-8971-fda7c161bd2f@github.com>
Message-ID: <xQo_Mf01RrRTkUIGOL-fDClYcKCqNipw_n33v1c6eWU=.bb7faddb-9d93-47fa-aa36-ddb3a5aa7890@github.com>

On Tue, 1 Jul 2025 06:30:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in comment.
>
> src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 57:
> 
>> 55:     static boolean supportsUserDefinedFileAttributeView(Path obj) {
>> 56:         try {
>> 57:             FileStore store = Files.getFileStore(obj);
> 
> This needs to be `new AixFileStore(obj)` rather than `Files.getFileStore` to avoid cycles. It might be that no one on AIX replaces the default provider but always have to avoid making use of the API in the API implementation.

Makes sense, but requires a cast to `UnixPath`.

> test/jdk/java/nio/file/FileStore/Basic.java line 113:
> 
>> 111:         if (!store1.supportsFileAttributeView(UserDefinedFileAttributeView.class) &&
>> 112:             Files.getFileAttributeView(dir, UserDefinedFileAttributeView.class) != null) {
>> 113:             throw new RuntimeException("UserDefinedFileAttributeView not supported, getFileAttributeView should return null");
> 
> I think it's okay to extend FileStore/Basic.java but to test Files.getFileAttributeView works consistently will require changes to test each of supported views. We shouldn't be testing UserDefinedFileAttributeView in isolation here. Can you try this instead:
> 
> 
>     static <V extends FileAttributeView> void testFileAttributes(Path file,
>                                                                  Class<V> viewClass,
>                                                                  String viewName) throws IOException {
>         FileStore store = Files.getFileStore(file);
>         boolean supported = store.supportsFileAttributeView(viewClass);
>         assertTrue(store.supportsFileAttributeView(viewName) == supported);
>         boolean haveView = Files.getFileAttributeView(file, viewClass) != null;
>         assertTrue(haveView == supported);
>     }
> 
> 
> 
>         /**
>          * Test: File and FileStore attributes
>          */
>         assertTrue(store1.supportsFileAttributeView("basic"));
>         testFileAttributes(dir, BasicFileAttributeView.class, "basic");
>         testFileAttributes(dir, PosixFileAttributeView.class, "posix");
>         testFileAttributes(dir, DosFileAttributeView.class, "dos");
>         testFileAttributes(dir, AclFileAttributeView.class, "acl");
>         testFileAttributes(dir, UserDefinedFileAttributeView.class, "user");

Nice! Thanks a lot!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2177427353
PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2177426145

From mdoerr at openjdk.org  Tue Jul  1 12:13:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:13:13 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better tests
 (aix)
Message-ID: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>

Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

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

Commit messages:
 - 8361183: JDK-8360887 needs fixes to avoid cycles and better tests (aix)

Changes: https://git.openjdk.org/jdk/pull/26066/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361183
  Stats: 34 lines in 2 files changed: 13 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26066/head:pull/26066

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

From mdoerr at openjdk.org  Tue Jul  1 12:13:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:13:13 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <yhHn_RVhqnNu9V9GBh_PVEiYpFHSnqCkO0ieWOcSHnY=.31577625-0820-48b1-829b-a8672eee9c58@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 56:

> 54: 
> 55:     private static boolean supportsUserDefinedFileAttributeView(Path obj) {
> 56:         if (obj == null || !(obj instanceof UnixPath)) return false;

I think we should have these checks before casting to `UnixPath`. Does this make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26066#discussion_r2177433884

From mdoerr at openjdk.org  Tue Jul  1 12:15:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:15:38 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <mDetN318x8MM2YB8eKZxDsV2a4qSrzm7MEK1eYaq9Cw=.c2cd30e2-5439-46e0-8395-f4a5378e5bce@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

@AlanBateman: Thanks for your thorough review of the original change! And sorry that I was too quick. There are currently too many issues...
I have followed your suggestions and added you as contributor.

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

PR Comment: https://git.openjdk.org/jdk/pull/26066#issuecomment-3023742559

From alanb at openjdk.org  Tue Jul  1 14:23:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 14:23:41 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <LnIGmxKc-3HsqHg2ydv_YpiXJzQacnAQzWcVt3b7vDM=.d59019ee-700e-42a1-906e-4caf457bee70@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 74:

> 72:             return supportsUserDefinedFileAttributeView(obj) ?
> 73:                 (V) new AixUserDefinedFileAttributeView(UnixPath.toUnixPath(obj), Util.followLinks(options))
> 74:                 : null;

Can you try this:

if (type == UserDefinedFileAttributeView.class) { 
    UnixPath file = UnixPath.toUnixPath(obj);
    return supportsUserDefinedFileAttributeView(file) ? ..


That will remove the cast/check from supportsUserDefinedFileAttributeView and also ensure that ProviderMismatchException is thrown if called with a Path from a different provider.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26066#discussion_r2177737962

From duke at openjdk.org  Tue Jul  1 14:36:39 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 1 Jul 2025 14:36:39 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

My initial impression was that the point of this PR was that the BufferedWriter was forcing the conversion to utf-16 and bypassing that would avoid a conversion. However, it seems that it is actually the StreamEncoder/CharsetEncoder that is really forcing that - and the conversion to utf-16 is required for optimal encoder performance.

The result (of this PR), then, seems to be that for OutputStreamWriter as a target (and maybe for specific character encodings) BufferedWriter no long buffers, but delegates that responsibility to the OutputStreamWriter (and its StreamEncoder).

Are there any scenarios where wrapping an OutputStreamWriter with a BufferedWriter makes sense? Is it only to control the buffer size? If so, should OutputStreamWriter itself just allow consumers to control the buffer size? (And then just change the doc of OutputStreamWriter to discourage the use of BufferedWriter - and change PrintWriter to not [create this combo](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/PrintWriter.java#L167).)

Should the various encoders be optimized to work with a StringCharBuffer? Perhaps only if backed by a String or AbstractStringBuilder? It seems that there could be more target character encodings beyond utf-8 and utf-16 (i.e ascii, iso-8859-1, cp1252, etc.) which could benefit from the source already known whether it is latin 1. 
It feels strange to place the optimizations for specific character encodings directly in StreamEncoder.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3024309269

From sherman at openjdk.org  Tue Jul  1 19:20:40 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 1 Jul 2025 19:20:40 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>
Message-ID: <iS-XNMV-eUeQo6U19Jp3H6pWXpNty2yeTe0Q7Uh7Iao=.0fa2d70e-7f6f-4bd3-a8d4-71c0f39dd36c@github.com>

On Tue, 1 Jul 2025 14:33:34 GMT, Brett Okken <duke at openjdk.org> wrote:

>  StreamEncoder/CharsetEncoder that is really forcing that - and the conversion to utf-16 is required for optimal encoder performance.

It might be worth exploring the idea of using string-buffer as the buffer to carry the byte[] + coder (delaying the byte[] ? char[] conversion) to the StreamEncoder, and then wrapping it as a StringCharBuffer all the way down to the charset/encoder layer. This could enable potential optimizations at individual charset encoder level.

It's unclear how significant the cost would be for the additional asb + scb wrapping and the access.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3025232418

From rriggs at openjdk.org  Tue Jul  1 19:57:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Jul 2025 19:57:42 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <PYF-6W91JTgpJoUeXxsx54LT2Kk2Rfx_3ygvR4jUDXA=.0b2f430c-7f6a-494e-90eb-0e4e392e9878@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

Looks fine

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2976779477

From mdoerr at openjdk.org  Tue Jul  1 20:08:21 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 20:08:21 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

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

  Use UnixPath.toUnixPath().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26066/files
  - new: https://git.openjdk.org/jdk/pull/26066/files/222cea0b..f1659ca3

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

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

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

From mdoerr at openjdk.org  Tue Jul  1 20:08:21 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 20:08:21 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <LnIGmxKc-3HsqHg2ydv_YpiXJzQacnAQzWcVt3b7vDM=.d59019ee-700e-42a1-906e-4caf457bee70@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <LnIGmxKc-3HsqHg2ydv_YpiXJzQacnAQzWcVt3b7vDM=.d59019ee-700e-42a1-906e-4caf457bee70@github.com>
Message-ID: <T5bEblZ2Vg7obDj5Zg6ZQ9T-JsVrJHWdomXETWw_fsE=.d0e7ab2d-3823-40e7-9ce3-389a7adb5d66@github.com>

On Tue, 1 Jul 2025 14:20:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UnixPath.toUnixPath().
>
> src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 74:
> 
>> 72:             return supportsUserDefinedFileAttributeView(obj) ?
>> 73:                 (V) new AixUserDefinedFileAttributeView(UnixPath.toUnixPath(obj), Util.followLinks(options))
>> 74:                 : null;
> 
> Can you try this:
> 
> if (type == UserDefinedFileAttributeView.class) { 
>     UnixPath file = UnixPath.toUnixPath(obj);
>     return supportsUserDefinedFileAttributeView(file) ? ..
> 
> 
> That will remove the cast/check from supportsUserDefinedFileAttributeView and also ensure that ProviderMismatchException is thrown if called with a Path from a different provider.

I like this version much better. Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26066#discussion_r2178430857

From bpb at openjdk.org  Tue Jul  1 22:42:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 22:42:16 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
Message-ID: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>

Ignore empty name elements in `WindowsPath.normalize()`.

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

Commit messages:
 - 8360028: (fs) Path.relativize throws StringIndexOutOfBoundsException (win)

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

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

From bpb at openjdk.org  Tue Jul  1 22:46:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 22:46:37 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>

On Tue, 1 Jul 2025 22:36:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore empty name elements in `WindowsPath.normalize()`.

Other, alternative changes which also fix this problem include:
- modifying `WindowsPath.initOffsets` not to include empty names;
- modifying `WindowsPath.initOffsets` to ignore consecutive backward slashes (``);
- modifying `WindowsFileSystemProvider.readSymbolicLink` to normalize the path string obtained from the link before creating the `WindowsPath`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3025775020

From bpb at openjdk.org  Tue Jul  1 23:26:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 23:26:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v15]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <ufWpflFhdrPm4cpC-J2_5GYBXqeZoNnOd7NWZMLCc5U=.e2abe1f8-1f0c-4e54-8fbc-9c493cd99887@github.com>

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

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

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/9d518b32...ffa3c469

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

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

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

From alanb at openjdk.org  Wed Jul  2 07:33:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Jul 2025 07:33:40 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <8wqwJJexBMPSLAn5kadyuLyfxbH0s7TqYe_e5d6peYk=.c4f2b2ee-2575-4e54-a5b1-d24f49a0c369@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26066#pullrequestreview-2978060252

From alanb at openjdk.org  Wed Jul  2 08:33:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Jul 2025 08:33:43 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>
Message-ID: <VUQQQ8I-3ajzHwxia4QbVqHxDikKdCHHzWn2dg_kzkg=.18ae9808-b367-4f11-bc97-80fd7fb2a18b@github.com>

On Tue, 1 Jul 2025 22:44:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> modifying WindowsFileSystemProvider.readSymbolicLink to normalize the path string obtained from the link before creating the WindowsPath.

If the link target can contain redundant slashes then it will need to be normalized so I think we may have do this anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3026951198

From swen at openjdk.org  Wed Jul  2 08:52:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Jul 2025 08:52:43 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <iAqmPO_vPpWwODDCQ52zwJ_1Y-ICEBFrjLcgxi2t3wI=.1bb06320-dbbb-425d-adc3-4ee5a4ea8f39@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

According to the suggestions of liach and xx, I added the improvement research of BufferedWriter using StringBuilder as buffer + ArrayEncoder to the current PR, which can have a good performance improvement in non-UTF8 scenarios.

The code is this branch: https://github.com/wenshao/jdk/tree/utf8_writer_202506_x4

There are a lot of code changes, which should be another PR.


git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

## Baseline
# https://github.com/wenshao/jdk/tree/utf8_writer_202506_test
git checkout 2758d6ad7767832db004d28f10cc764f33fa438e
make test TEST="micro:java.io.BufferedWriterBench" MICRO="OPTIONS=-p charset=ISO_8859_1,ASCII,UTF8,UTF16,GB18030

# Current (PR 26022 & BufferedWriter use StringBuilder as buffer)
# https://github.com/wenshao/jdk/tree/utf8_writer_202506_x4
git checkout 77c5996b6a7b7ea74d03b64c4c8e827a7d76f05a
make test TEST="micro:java.io.BufferedWriterBench" MICRO="OPTIONS=-p charset=ISO_8859_1,ASCII,UTF8,UTF16,GB18030


## Benchmark Numbers on Aliyun ECS c9i (Intel x64 CPU)

Benchmark         (charType)   (charset)  Units Base_Score Current_Score Improvement(%)
writeCharArray         ascii  ISO_8859_1  us/op      3.128         3.027 +3.23%
writeCharArray         ascii       ASCII  us/op      3.126         3.351 -6.88%
writeCharArray         ascii        UTF8  us/op      3.125         3.716 -18.91%
writeCharArray         ascii       UTF16  us/op     32.469        11.404 +64.87%
writeCharArray         ascii     GB18030  us/op      9.642         7.296 +24.34%
writeCharArray  utf8_2_bytes  ISO_8859_1  us/op      3.137         3.016 +3.86%
writeCharArray  utf8_2_bytes       ASCII  us/op     96.779         8.725 +90.99%
writeCharArray  utf8_2_bytes        UTF8  us/op     17.346        12.966 +25.25%
writeCharArray  utf8_2_bytes       UTF16  us/op     32.407        11.267 +65.19%
writeCharArray  utf8_2_bytes     GB18030  us/op     82.994        12.401 +85.14%
writeCharArray  utf8_3_bytes  ISO_8859_1  us/op    100.063         7.486 +92.51%
writeCharArray  utf8_3_bytes       ASCII  us/op     96.061         9.236 +90.40%
writeCharArray  utf8_3_bytes        UTF8  us/op     28.340        13.358 +52.86%
writeCharArray  utf8_3_bytes       UTF16  us/op     32.468        11.785 +63.70%
writeCharArray  utf8_3_bytes     GB18030  us/op     40.864        37.012 +9.66%
writeCharArray         emoji  ISO_8859_1  us/op    190.547        10.149 +94.67%
writeCharArray         emoji       ASCII  us/op    187.803        12.774 +93.17%
writeCharArray         emoji        UTF8  us/op     41.493        23.473 +43.49%
writeCharArray         emoji       UTF16  us/op     48.248        16.227 +66.36%
writeCharArray         emoji     GB18030  us/op    147.360        63.437 +57.01%
writeString            ascii  ISO_8859_1  us/op      3.340         2.770 +17.09%
writeString            ascii       ASCII  us/op      3.340         3.069 +8.11%
writeString            ascii        UTF8  us/op      3.324         2.944 +11.43%
writeString            ascii       UTF16  us/op     32.503        11.214 +65.49%
writeString            ascii     GB18030  us/op      9.023         6.999 +22.43%
writeString     utf8_2_bytes  ISO_8859_1  us/op      3.338         2.827 +15.31%
writeString     utf8_2_bytes       ASCII  us/op     95.964         8.542 +91.10%
writeString     utf8_2_bytes        UTF8  us/op     17.660        10.155 +42.44%
writeString     utf8_2_bytes       UTF16  us/op     32.516        11.173 +65.63%
writeString     utf8_2_bytes     GB18030  us/op     82.369        12.231 +85.14%
writeString     utf8_3_bytes  ISO_8859_1  us/op    100.280         7.363 +92.66%
writeString     utf8_3_bytes       ASCII  us/op     95.279         9.060 +90.48%
writeString     utf8_3_bytes        UTF8  us/op     28.344        18.366 +35.19%
writeString     utf8_3_bytes       UTF16  us/op     32.672        11.284 +65.43%
writeString     utf8_3_bytes     GB18030  us/op     43.798        37.145 +15.16%
writeString            emoji  ISO_8859_1  us/op    189.574         9.904 +94.75%
writeString            emoji       ASCII  us/op    187.021        12.427 +93.35%
writeString            emoji        UTF8  us/op     41.775        25.875 +37.98%
writeString            emoji       UTF16  us/op     48.240        15.696 +67.10%
writeString            emoji     GB18030  us/op    147.097        63.587 +56.78%


## Benchmark Numbers on MacBook M1 Pro (aarch64)

Benchmark                             (charType)   (charset)  Units Base_Score Current_Score Improvement(%)
BufferedWriterBench.writeCharArray         ascii  ISO_8859_1  us/op      2.815         2.133 +24.20%
BufferedWriterBench.writeCharArray         ascii       ASCII  us/op      2.742         2.352 +14.22%
BufferedWriterBench.writeCharArray         ascii        UTF8  us/op      2.704         2.616 +3.25%
BufferedWriterBench.writeCharArray         ascii       UTF16  us/op     31.294         8.489 +72.87%
BufferedWriterBench.writeCharArray         ascii     GB18030  us/op      8.932         3.820 +57.20%
BufferedWriterBench.writeCharArray  utf8_2_bytes  ISO_8859_1  us/op      2.828         2.210 +21.85%
BufferedWriterBench.writeCharArray  utf8_2_bytes       ASCII  us/op    109.255         5.669 +94.80%
BufferedWriterBench.writeCharArray  utf8_2_bytes        UTF8  us/op     22.353        14.039 +37.15%
BufferedWriterBench.writeCharArray  utf8_2_bytes       UTF16  us/op     31.268         8.349 +73.28%
BufferedWriterBench.writeCharArray  utf8_2_bytes     GB18030  us/op     90.835         6.816 +92.50%
BufferedWriterBench.writeCharArray  utf8_3_bytes  ISO_8859_1  us/op    109.734         7.834 +92.88%
BufferedWriterBench.writeCharArray  utf8_3_bytes       ASCII  us/op    106.981         7.906 +92.60%
BufferedWriterBench.writeCharArray  utf8_3_bytes        UTF8  us/op     21.453        16.076 +25.07%
BufferedWriterBench.writeCharArray  utf8_3_bytes       UTF16  us/op     31.294         6.945 +77.75%
BufferedWriterBench.writeCharArray  utf8_3_bytes     GB18030  us/op     49.007        27.891 +43.02%
BufferedWriterBench.writeCharArray         emoji  ISO_8859_1  us/op    223.538        11.189 +94.54%
BufferedWriterBench.writeCharArray         emoji       ASCII  us/op    264.875        11.384 +95.69%
BufferedWriterBench.writeCharArray         emoji        UTF8  us/op     35.704        21.672 +39.29%
BufferedWriterBench.writeCharArray         emoji       UTF16  us/op     45.979        11.255 +75.51%
BufferedWriterBench.writeCharArray         emoji     GB18030  us/op    148.829        57.625 +61.33%
BufferedWriterBench.writeString            ascii  ISO_8859_1  us/op      2.898         2.159 +25.49%
BufferedWriterBench.writeString            ascii       ASCII  us/op      2.876         2.591 +9.91%
BufferedWriterBench.writeString            ascii        UTF8  us/op      2.894         2.466 +14.79%
BufferedWriterBench.writeString            ascii       UTF16  us/op     31.236         8.759 +71.82%
BufferedWriterBench.writeString            ascii     GB18030  us/op      9.010         3.899 +56.70%
BufferedWriterBench.writeString     utf8_2_bytes  ISO_8859_1  us/op      2.894         2.178 +24.71%
BufferedWriterBench.writeString     utf8_2_bytes       ASCII  us/op    108.426         5.611 +94.82%
BufferedWriterBench.writeString     utf8_2_bytes        UTF8  us/op     22.206        12.225 +44.93%
BufferedWriterBench.writeString     utf8_2_bytes       UTF16  us/op     31.305         8.773 +71.98%
BufferedWriterBench.writeString     utf8_2_bytes     GB18030  us/op     90.820         6.907 +92.40%
BufferedWriterBench.writeString     utf8_3_bytes  ISO_8859_1  us/op    108.983         7.931 +92.66%
BufferedWriterBench.writeString     utf8_3_bytes       ASCII  us/op    107.064         7.836 +92.66%
BufferedWriterBench.writeString     utf8_3_bytes        UTF8  us/op     21.664        13.102 +39.47%
BufferedWriterBench.writeString     utf8_3_bytes       UTF16  us/op     31.546         6.930 +78.00%
BufferedWriterBench.writeString     utf8_3_bytes     GB18030  us/op     52.688        27.698 +47.17%
BufferedWriterBench.writeString            emoji  ISO_8859_1  us/op    221.930        11.160 +94.95%
BufferedWriterBench.writeString            emoji       ASCII  us/op    236.791        11.116 +95.30%
BufferedWriterBench.writeString            emoji        UTF8  us/op     35.025        23.210 +33.73%
BufferedWriterBench.writeString            emoji       UTF16  us/op     45.988        11.334 +75.32%
BufferedWriterBench.writeString            emoji     GB18030  us/op    148.202        57.472 +61.23%

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3027011273

From mdoerr at openjdk.org  Wed Jul  2 09:05:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 09:05:44 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <9su5B0CoLULPzH96nt4qCVf0KjzUxyzKnjgp7b_iD2I=.b0e220b3-447d-4daa-8947-97e49802dcae@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

Thanks for the review and your guidance!

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

PR Comment: https://git.openjdk.org/jdk/pull/26066#issuecomment-3027052356

From jkern at openjdk.org  Wed Jul  2 09:23:39 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 2 Jul 2025 09:23:39 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <s290yyYkoGqC-HWhhIj8S14w6C38RtdejBTJrH7axFA=.4e715e5a-ace2-47f2-b9a1-9e68381a9b8f@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

LGTM

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26066#pullrequestreview-2978409095

From liach at openjdk.org  Wed Jul  2 14:32:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 14:32:41 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <8eih4k_a1QllWM_vcg81TX0F6_bp8wYJmEP77VoCqT0=.acaceaa8-9203-423b-b6ea-67dbcc61a6a7@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

This latest prototype looks great! It means that we can get rid of the old `BufferedImpl` by using `WriterImpl` as the new code, and remove `StreamEncoder.UTF8Impl`.

I think this prototype can be split this way:
1. Update ArrayEncoder to pass `dp`, open up StringBuilder in JLA, and make BufferedWriter + StreamEncoder use ArrayEncoder. We can use a benchmark writing encodings like CESU for a first step proof of concept.
2. Make UTF8/ISO88591 array encoders. This will open up a few String UTF8 encoding methods in JLA.
3. More array encoders. For example, GB18030 gets a new array encoder in your patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028104142

From rriggs at openjdk.org  Wed Jul  2 14:54:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 14:54:42 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <JuEjPqVLztex6JfoWlroOsG5-rqO1Q1kb0NEORsFanQ=.d7e62b4b-ad51-4537-afa3-d4a7d1156a40@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

No more of StringBuilder should be exposed via JLA, it creates new maintenance overhead and risks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028178422

From liach at openjdk.org  Wed Jul  2 15:03:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 15:03:41 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <iiYPhhUbTroTfy-WVFFn0cA_Bi4mSgz6NRxZ0X11IEM=.b597e2be-dfd8-4c53-86f9-7b7828c79338@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

It is not about exposing the implementation details of StringBuilder: it is just exporting a method for StringBuilder to encode itself with an ArrayEncoder (which has LATIN1/UTF16 entrypoints) to general JDK audiences.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028212631

From bpb at openjdk.org  Wed Jul  2 15:10:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 15:10:39 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <VUQQQ8I-3ajzHwxia4QbVqHxDikKdCHHzWn2dg_kzkg=.18ae9808-b367-4f11-bc97-80fd7fb2a18b@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>
 <VUQQQ8I-3ajzHwxia4QbVqHxDikKdCHHzWn2dg_kzkg=.18ae9808-b367-4f11-bc97-80fd7fb2a18b@github.com>
Message-ID: <ChbejE0YBGNnk7y584YTJ-YxTAXTj2OOjN12BhtMDhA=.93f63e87-b45c-4094-b982-2f2c7674ff64@github.com>

On Wed, 2 Jul 2025 08:30:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > modifying WindowsFileSystemProvider.readSymbolicLink to normalize the path string obtained from the link before creating the WindowsPath.
> 
> If the link target can contain redundant slashes then it will need to be normalized so I think we may have do this anyway.

The link target can contain redundant slashes on both Unix and Windows, but the problem does not manifest on Unix. In both cases, it looks like `readSymbolicLink` just uses whatever is in the link target, unfiltered.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3028235362

From mdoerr at openjdk.org  Wed Jul  2 15:34:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:34:51 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <dpeNOSt341Rhh16guZiATVbx2xNA4prIG83XxQ1t0Hk=.0d7f007b-5376-4e96-b478-7c3832bf580d@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

Thanks! I've verified that the test still catches the bug when I remove the fix. It's a bit more cumbersome to read, but ok:

java.lang.RuntimeException: Assertion failed
        at Basic.assertTrue(Basic.java:57)
        at Basic.testFileAttributes(Basic.java:77)
        at Basic.doTests(Basic.java:114)
        at Basic.main(Basic.java:49)

The fix still works and tier1-4 have passed. Let's ship it!

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

PR Comment: https://git.openjdk.org/jdk/pull/26066#issuecomment-3028312727

From mdoerr at openjdk.org  Wed Jul  2 15:34:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:34:51 GMT
Subject: Integrated: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <hiUerUj5F7u0liohLbQwgeBTcSLMd23Ayo3J-bLJjok=.a557ef6b-364b-4aba-98de-cff678720ace@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

This pull request has now been integrated.

Changeset: c460f842
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c460f842bf768995b271cd6362940877a4a79665
Stats:     35 lines in 2 files changed: 14 ins; 10 del; 11 mod

8361183: JDK-8360887 needs fixes to avoid cycles and better tests (aix)

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, jkern

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

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

From mdoerr at openjdk.org  Wed Jul  2 15:36:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:36:47 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <jxDsxAlAGbRpbRUYVoERlQweKQQODosP5G4_RtESMws=.0a40229a-9685-49f0-9a6d-ab399eacf488@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

Follow-up is integrated. I'll do the backport and test it on top of this after

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3028322429

From mdoerr at openjdk.org  Wed Jul  2 15:36:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:36:47 GMT
Subject: [jdk25] Integrated: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView
 unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <u2A1I_rE8kxZWj62ngR8LQr9_H8qYyMQkC84CLjbDTA=.60015640-6bc4-49f2-8454-76683fd6e4fa@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

This pull request has now been integrated.

Changeset: a98a5e54
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a98a5e54fcb7916ce922a6997c452d2264bc4479
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

8360887: (fs) Files.getFileAttributeView returns unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)

Reviewed-by: mbaesken
Backport-of: 0572b6ece7a77d13d23ac0c6d72d4fe5d5f0d944

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

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

From mdoerr at openjdk.org  Wed Jul  2 15:43:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:43:16 GMT
Subject: [jdk25] RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
Message-ID: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>

Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

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

Commit messages:
 - Backport c460f842bf768995b271cd6362940877a4a79665

Changes: https://git.openjdk.org/jdk/pull/26097/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26097&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361183
  Stats: 35 lines in 2 files changed: 14 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26097/head:pull/26097

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

From brian.burkhalter at oracle.com  Wed Jul  2 16:26:02 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 16:26:02 +0000
Subject: StringCharBuffer and bulk get
In-Reply-To: <SJ2PR10MB7669E8BCB6179EFFB11DC0C6A240A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <SJ2PR10MB7669E8BCB6179EFFB11DC0C6A240A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <4CE894FB-AAA1-41D3-8388-04CDB68A9D94@oracle.com>

An issue will need to be filed.

On Jul 2, 2025, at 8:48?AM, Chen Liang <chen.l.liang at oracle.com> wrote:

I think Brett is right. The spec of CharBuffer says:

The methods defined by {@code CharSequence} operate relative to the current
position of the buffer when they are invoked.

Yet getChars is an absolute bulk get method.

Since JDK25 is still in RDP, we still have a chance to fix this up.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250702/87975d15/attachment-0001.htm>

From brian.burkhalter at oracle.com  Wed Jul  2 18:55:48 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 18:55:48 +0000
Subject: StringCharBuffer and bulk get
In-Reply-To: <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
Message-ID: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>


On Jul 2, 2025, at 11:19?AM, Alan Bateman <alan.bateman at oracle.com> wrote:

On 02/07/2025 16:58, Brett Okken wrote:

:

This makes it very difficult to pass a CharBuffer (where the position
is not 0) to an api taking a CharSequence - because if that api makes
a switch to start using getChars (rather than charAt), it will break.



Thanks for bringing this up. It does need attention. I just chatted with Brian Burkhalter so he's going to look through the spec + implementation changes to address this. If there is any risk or uncertainty then it mean pulling this out.

It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it:

https://bugs.openjdk.org/browse/JDK-8361299

The fix is straightforward but will break a test and require a CSR.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250702/837d3c8b/attachment.htm>

From brett.okken.os at gmail.com  Wed Jul  2 20:05:43 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Wed, 2 Jul 2025 15:05:43 -0500
Subject: StringCharBuffer and bulk get
In-Reply-To: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
 <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
Message-ID: <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>

> It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it:
>
> https://bugs.openjdk.org/browse/JDK-8361299
>
> The fix is straightforward but will break a test and require a CSR.


Looks like the testNG GetChars has

cb.getChars(cb.position(), cb.limit(), dst, 0);

but that should have been

cb.getChars(0, cb.remaining(), dst, 0);

or

cb.getChars(0, cb.length(), dst, 0);

- Brett

From brian.burkhalter at oracle.com  Wed Jul  2 20:09:36 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 20:09:36 +0000
Subject: StringCharBuffer and bulk get
In-Reply-To: <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
 <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
 <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>
Message-ID: <07D9B721-4BEB-4070-BA6D-B8A154D15B8F@oracle.com>



> On Jul 2, 2025, at 1:05?PM, Brett Okken <brett.okken.os at gmail.com> wrote:
> 
>> It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361299 
>> 
>> The fix is straightforward but will break a test and require a CSR.
> 
> 
> Looks like the testNG GetChars has
> 
> cb.getChars(cb.position(), cb.limit(), dst, 0);
> 
> but that should have been
> 
> cb.getChars(0, cb.remaining(), dst, 0);

It?s this one ^.

Thanks,

Brian

> or
> 
> cb.getChars(0, cb.length(), dst, 0);
> 
> - Brett


From msheppar at openjdk.org  Wed Jul  2 20:17:38 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 2 Jul 2025 20:17:38 GMT
Subject: RFR: 8291652: (ch) java/nio/channels/SocketChannel/VectorIO.java
 failed with "Exception: Server 15: Timed out"
In-Reply-To: <IXJVibtn50UwnCNNfv10Y3fq7EJ_Ax9cEtx_aIrRbbw=.05ab344a-aded-4ca3-bbbd-ab3b6924fee3@github.com>
References: <IXJVibtn50UwnCNNfv10Y3fq7EJ_Ax9cEtx_aIrRbbw=.05ab344a-aded-4ca3-bbbd-ab3b6924fee3@github.com>
Message-ID: <oiFTGcK3n9tjOqkwbTcFx_a9FSC-5W7_G0sjbpQNkCg=.70436937-a2ce-4e8c-b288-ebbbd73178a6@github.com>

On Mon, 30 Jun 2025 15:58:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent test failure in `java/nio/channels/SocketChannel/VectorIO.java`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8291652, this test has been failing intermittently in our CI. Some years back the test was improved to include additional debug logs to identify the root cause https://bugs.openjdk.org/browse/JDK-8180085. In a recent failure, these test logs indicate that the `Server` thread hadn't yet `accept()`ed a Socket connection, when the client side of the test threw an exception because it had waited for 8 seconds for the server side of the test to complete.
> 
> The change in this PR updates the test to wait for the `Server` thread to reach a point where it is ready to `accept()` a Socket connection. Only after it reaches this state, the client side of the testing will be initiated. Furthermore, the artificial 8 second wait has been removed from this test and it now waits as long as it takes for the testing to complete. If the test waits far too long then the jtreg infrastructure will timeout the test and at the same time capture the necessary artifacts to help debug unexpected time outs.
> 
> While at it, the test has also been updated to use `InetAddress.getLoopbackAddress()` instead of localhost. This should prevent any unexpected address mappings for localhost from playing a role in this test.
> 
> With these changes, I've run the test more than 1000 times in our CI and it hasn't failed.

A couple of observations to consider.

The setLength is a static member variable of the test effectively a global variable, but it has non synchronised access from multiple threads.
Something to consider for amendment ? volatile or synchronized methods for access.

The use of the CountDownLatch is as about the best we can do. It should mitigate against the possibilities of observed race conditions, but won?t absolutely guarantee this.


Consider the following, slightly convoluted scenario:

The Server starts and executes as far as the countDown on the connAcceptLatch, at which point the server thread gets bumped by the OS and is placed in RTR queue waiting its next scheduled time slice.
The main thread execute as far at the sv.awaitFinish (executing bufferTest method), BUT it has closed the connection before the Server has executed accept or read the data from the socket.
This provides a possibility that data will disappear from the socket ? so there is the possibility that a bit of a race condition will still exist.

Thus, it might be more prudent to close the socket on the client or initiator side (i.e. in the main test thread),  after the Server has finished. As such after the sv.awaitFinish call.

In this case the Server will have closed its end of the socket connection also, at that point in time.

To accommodate this logic, pass the Server reference to the bufferTest method  to invoke the sv.awaitFinish,
or arrange for the  bufferTest method to return the  SocketChannel reference
and invoke the close of the SocketChannel after sv.awaitFinish call in the main method.

Another alternative for this is a refactor extract method at line 92

SocketChannel openConnection(in port)  throws  Exception {
        // Get a connection to the server
         InetAddress loopback = InetAddress.getLoopbackAddress();
         InetSocketAddress isa = new InetSocketAddress(loopback, port);
         SocketChannel sc = SocketChannel.open();
         sc.connect(isa);
         sc.configureBlocking(generator.nextBoolean());
         return sc
}
 Call openConnection before bufferTest and pass the SocketChannel reference to bufferTest with sc.close() call removed

Then after awaitFinish call a sc.close in the main

In any case, back to the main point, that is to close the client SocketChannel after the sv.awaitFinish call.

The method waitToStartTest is on the Server class, maybe refactor rename waitServerStart. The waitToStartTest is a private method on Server but is really part of the public interface to the Server (the fact Server is a static inner class gives access to the private waitServerStart)

Line 174 the invocation connAcceptLatch.countDown which sets the test in motion

could, for the sake of symmetry, be encapsulated in a method

void signalServerStarted() {
    connAcceptLatch.countDown
}

Another aspect of the test that caught the eye is the fact that the ServerSocketChannel bind is invoked with just the SocketAddress and doesn?t specify any backlog. IIRC correctly this results in a backlog of 0 being used.

Since back in the day, It has been best practice not to specify a backlog of 0, especially for portability, as it is backlog 0 semantics are ill defined (or in most cases not defined at all) on most OS platforms.
So, maybe add a backlog of 5 in homage to the original in BSD 4.2

A slight digression from this PR, and a general comment on the ServerSocketChannel::bind(SocketAddress local)

 I think it would be better if the ServerSocketChannel  implementation used  a NON zero default backlog value out of the box, e.g. 5 rather than the backlog of 0. This could, also, be overridden with a  System Property java.nio.DefaultSocketBacklog for use when the single arg ServerSocketChannel::bind method call is used. This would then give common uniform semantics across all OS platforms. Rather then the nebulous semantics for backlog value of zero.

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

PR Comment: https://git.openjdk.org/jdk/pull/26049#issuecomment-3029196920

From bpb at openjdk.org  Wed Jul  2 20:30:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 20:30:03 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int) violates
 pre-existing specification
Message-ID: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>

Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

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

Commit messages:
 - 8361299: (bf) CharBuffer.getChars(int,int,char[],int) violates pre-existing specification

Changes: https://git.openjdk.org/jdk/pull/26104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361299
  Stats: 24 lines in 2 files changed: 9 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26104/head:pull/26104

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

From bpb at openjdk.org  Wed Jul  2 21:12:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 21:12:25 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
Message-ID: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>

> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

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

  8361299: Fix a type; add a sentence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26104/files
  - new: https://git.openjdk.org/jdk/pull/26104/files/5bbc34d4..e9abd20f

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

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

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

From duke at openjdk.org  Wed Jul  2 21:49:42 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 2 Jul 2025 21:49:42 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
Message-ID: <nXCi71a8R5VoRdv9DSQ-H9pdKsdofa69jXeRl98nhT4=.5adb3194-b868-4d14-87df-4153b19a585b@github.com>

On Wed, 2 Jul 2025 21:12:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Fix a type; add a sentence

Marked as reviewed by bokken at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/26104#pullrequestreview-2980730140

From bpb at openjdk.org  Wed Jul  2 22:36:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 22:36:38 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
Message-ID: <nr3D7AJPZnBy8G6lyp7STIzO0QzvpAnljjCVQXg4g5w=.14cb384c-39f9-45de-a0d3-27887e0d2e2b@github.com>

On Wed, 2 Jul 2025 21:12:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Fix a type; add a sentence

`jdk_core` tests passed on Linux in the CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/26104#issuecomment-3029517213

From brian.burkhalter at oracle.com  Wed Jul  2 22:53:00 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 22:53:00 +0000
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <nXCi71a8R5VoRdv9DSQ-H9pdKsdofa69jXeRl98nhT4=.5adb3194-b868-4d14-87df-4153b19a585b@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
 <nXCi71a8R5VoRdv9DSQ-H9pdKsdofa69jXeRl98nhT4=.5adb3194-b868-4d14-87df-4153b19a585b@github.com>
Message-ID: <9A313091-2619-441E-81E4-E7ECF07CBC16@oracle.com>



On Jul 2, 2025, at 2:49?PM, Brett Okken <duke at openjdk.org> wrote:

Marked as reviewed by bokken at github.com<mailto:bokken at github.com> (no known OpenJDK username).

Thanks for the review.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250702/fb756742/attachment-0001.htm>

From liach at openjdk.org  Wed Jul  2 23:03:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:03:40 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
Message-ID: <vw_aTubPJDuU0akEAjbMhpmLME-alo2NiMQgqOlcMDM=.5048fc8d-f7ac-4436-85e3-4ae99d6069bc@github.com>

On Wed, 2 Jul 2025 21:12:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Fix a type; add a sentence

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26104#pullrequestreview-2980868707

From bpb at openjdk.org  Wed Jul  2 23:39:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 23:39:17 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>

> Ignore empty name elements in `WindowsPath.normalize()`.

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

  8360028: Returned normalized string from WindowsLinkSupport.readLinkImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26080/files
  - new: https://git.openjdk.org/jdk/pull/26080/files/ea30eaf6..86912f3e

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

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

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

From bpb at openjdk.org  Wed Jul  2 23:42:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 23:42:38 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
Message-ID: <6wfiMN8L6H9yzXzuG0__KLgZjoGqaqRjXFFz0UIvx4c=.0dfbe9a2-9a32-454d-84d9-af869f461b89@github.com>

On Wed, 2 Jul 2025 23:39:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Returned normalized string from WindowsLinkSupport.readLinkImpl

Commit 86912f3 normalizes the link target path string before returning from `WindowsLinkSupport.readLinkImpl`. This change alone without the prior commit ea30eaf would resolve the issue at hand.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3029677297

From bpb at openjdk.org  Thu Jul  3 00:33:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 00:33:58 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
Message-ID: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>

> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

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

  8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26104/files
  - new: https://git.openjdk.org/jdk/pull/26104/files/e9abd20f..a98e8dd4

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

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

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

From duke at openjdk.org  Thu Jul  3 03:20:47 2025
From: duke at openjdk.org (duke)
Date: Thu, 3 Jul 2025 03:20:47 GMT
Subject: Withdrawn: 8353795: Add Writer.of(StringBuilder)
In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
Message-ID: <oy3WZBhOMCmlmi4lOK5S1u5cNcc5XVzZ4JGzXj6Hopw=.5cf6ac0f-5779-4805-bb48-466c948b1ce5@github.com>

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

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

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Thu Jul  3 07:14:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Jul 2025 07:14:42 GMT
Subject: [jdk25] RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
In-Reply-To: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
References: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
Message-ID: <Cy9_oVFaF3Wxk1SEy3qmk98S0Mp8XWJ_oWYiaqQqAvQ=.aa8580be-5d89-490d-a2f7-7a00d2331464@github.com>

On Wed, 2 Jul 2025 15:36:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26097#pullrequestreview-2982005536

From jpai at openjdk.org  Thu Jul  3 07:17:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Jul 2025 07:17:44 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <6o5VBnWWZEpIwPsRrXFWwRO6S7hwnfPQVMhrnD97FkM=.f9e3d344-2757-48fd-957c-d92e5e83e8e8@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

I agree with Roger - introducing new methods on JavaLangAccess to access the methods on String/StringBuilder and related core APIs is not the way to engineer the implementation of these APIs.

I believe the whole exercise in this PR is premature, and it's not the first time either. The contributor opened a mail in the core-libs-dev mailing list, did not wait to hear from the people knowledegable in this area, went ahead and created a JBS issue, then created a PR and linked the PR to that issue which generated an official RFR inviting official reviews, when the entire idea is half baked. In all of this, the PR has zero regression tests added/referenced with the changes. In the mailing list discussion, the contributor was asked if they had looked into the tests to ensure whether there is enough coverage for these changes and what kind of testing might have been done https://mail.openjdk.org/pipermail/core-libs-dev/2025-June/148231.html. The response from the contributor is this https://mail.openjdk.org/pipermail/core-libs-dev/2025-June/148236.html which says that a new micro benchmark shows some percentage. I haven't seen any indication in the reply, stating what kind of tes
 ting has been done or what tests have been analyzed and why no new tests have been added. This isn't the first PR of such nature either, so I am not leaning towards giving the benefit of doubt that maybe the contributor misunderstood the question, I believe it's way past that point now.

Changes like these require additional tests or a detailed analysis and explanation about which tests cover these changes and why new tests cannot be introduced. I believe pointing to new manually run microbenchmarks and claiming these are performance driven changes isn't appropriate.

Some reviewers try and stay away from PRs like these for valid reasons. Some reviewers do allow some benefit of doubt to the contributors who are new (the current contributor isn't) and help/guide them in such PRs, and that's a good thing. But when PRs are linked against JBS issue and have generated a RFR, it becomes extremely hard to stay away from reviewing those when the proposed changes are going in a direction that isn't maintainable. Dragging in the JBS infrastructure and the official review process in these experimental changes wastes a lot of time, energy and patience.

My suggestion is to put this PR into draft mode, edit the subject of the PR to remove the reference to the JBS issue so that it hopefully doesn't generate additional RFR mails and then go back to the original email discussion in core-libs-dev and seek inputs on how or whether these changes should be done. It's OK if that process takes a (very) long time, that's intentional for changes like these. It's also OK if the contributor doesn't have the time or doesn't wish to follow the slow nature of these discussions and then implementing those changes in a way which keeps it maintainable and adds and exercises the relevant tests. They can ask people familiar with this area whether the proposed idea merits creating a JBS issue and only then create one so that anyone else who is willing to follow these processes can pursue it further.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3031150436

From alanb at openjdk.org  Thu Jul  3 07:33:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 07:33:47 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
Message-ID: <_dw3E1LolcfxwSq6LC_ggmGJUcaZ5q3S4fEezwK665g=.8a2064f6-6462-48bc-95a7-9f5e5ecef5ae@github.com>

On Wed, 2 Jul 2025 23:39:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Returned normalized string from WindowsLinkSupport.readLinkImpl

src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 361:

> 359: 
> 360:             // return normalized path string
> 361:             return WindowsPathParser.parse(target).path();

This looks right, I'm just wondering if we now have cases where this will be parsed again. If then they I think this is good and we can drop the change to WindowsPath.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26080#discussion_r2182070199

From mdoerr at openjdk.org  Thu Jul  3 08:49:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 3 Jul 2025 08:49:44 GMT
Subject: [jdk25] RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
In-Reply-To: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
References: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
Message-ID: <_gqWV0_CgMLwHI2RBTAdQG_G64JZUH_OgYlAgST1KOE=.50033872-f635-4eb9-b701-91d79285370b@github.com>

On Wed, 2 Jul 2025 15:36:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

Thanks! I'm glad to have this fixed in jdk25. Our tests are green.

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

PR Comment: https://git.openjdk.org/jdk/pull/26097#issuecomment-3031414702

From mdoerr at openjdk.org  Thu Jul  3 08:49:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 3 Jul 2025 08:49:45 GMT
Subject: [jdk25] Integrated: 8361183: JDK-8360887 needs fixes to avoid cycles
 and better tests (aix)
In-Reply-To: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
References: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
Message-ID: <rK9MHChRy52ef1-pXSFiJb2o_XZPa3CKPYQ3lr7km8Y=.a392d970-513f-49f1-9592-da30e66e98fb@github.com>

On Wed, 2 Jul 2025 15:36:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

This pull request has now been integrated.

Changeset: 8a98738f
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a98738f448ac91f517bcc5a67d01522b7ba2025
Stats:     35 lines in 2 files changed: 14 ins; 10 del; 11 mod

8361183: JDK-8360887 needs fixes to avoid cycles and better tests (aix)

Reviewed-by: mbaesken
Backport-of: c460f842bf768995b271cd6362940877a4a79665

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

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

From alanb at openjdk.org  Thu Jul  3 09:42:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:42:40 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

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

> 1905:      * {@code dstBegin} in the array. The position of this buffer is unchanged.
> 1906:      *
> 1907:      * <p> An invocation of this method behaves exactly the same was as the

I think we can use an implSpec for this and keep "This method is equivalent to".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2182337987

From alanb at openjdk.org  Thu Jul  3 09:46:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:46:40 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <KLE7F4NU-4BfHUaK9JTkdWgWHMqavbR-oalGT0q6s2w=.bb8eab48-cdb5-4ac0-adaf-782b85cf7f26@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

test/jdk/java/nio/Buffer/GetChars.java line 75:

> 73: 
> 74:     @Test
> 75:     public void testSrcBeginIsNegationOfPosition() {

I skimmed through GetChars and I see it only tests a CB created with CharBuffer.wrap. I think we change each of these tests to changed to paramterrized tests that test all implementations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2182346032

From alanb at openjdk.org  Thu Jul  3 09:53:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:53:42 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <ieaRiYk_22rX5rEqWY-ZO1qn90qeQvVViGIhlRQYFHo=.c6732280-0ff1-43bc-9a46-2318cb5a8008@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

test/jdk/java/nio/Buffer/GetChars.java line 75:

> 73: 
> 74:     @Test
> 75:     public void testSrcBeginIsNegationOfPosition() {

I skimmed through GetChars and I see it only tests a CB created with CharBuffer.wrap, only testGetChars tests all char buffers. All the test methods should be tested all char buffer implementations. So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2182361518

From bpb at openjdk.org  Thu Jul  3 15:33:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 15:33:41 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
Message-ID: <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>

On Thu, 3 Jul 2025 09:40:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we can use an implSpec for this and keep "This method is equivalent to".

I was following the existing convention elsewhere in the file.

> So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).

Agreed. I also noticed it is TestNG now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183097880
PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183100891

From alanb at openjdk.org  Thu Jul  3 15:52:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 15:52:46 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
Message-ID: <WCxB90vWJIpXa8AscIEd7VW9CcYP5cDPKOC9AARJvyE=.92f53256-f853-421b-bceb-28bb6b6110da@github.com>

On Thu, 3 Jul 2025 15:29:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1907:
>> 
>>> 1905:      * {@code dstBegin} in the array. The position of this buffer is unchanged.
>>> 1906:      *
>>> 1907:      * <p> An invocation of this method behaves exactly the same was as the
>> 
>> I think we can use an implSpec for this and keep "This method is equivalent to".
>
>> I think we can use an implSpec for this and keep "This method is equivalent to".
> 
> I was following the existing convention elsewhere in the file.

I don't know why JDK-8343110 put the implSpec after the param/return/throws tags so happy it has been fixed. Maybe at some point we can use implSpec to these methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183140295

From bpb at openjdk.org  Thu Jul  3 15:58:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 15:58:55 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v3]
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>

> Ignore empty name elements in `WindowsPath.normalize()`.

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

  8360028: Revert change to WindowsPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26080/files
  - new: https://git.openjdk.org/jdk/pull/26080/files/86912f3e..3e994d2e

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

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

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

From bpb at openjdk.org  Thu Jul  3 16:02:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 16:02:44 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <_dw3E1LolcfxwSq6LC_ggmGJUcaZ5q3S4fEezwK665g=.8a2064f6-6462-48bc-95a7-9f5e5ecef5ae@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
 <_dw3E1LolcfxwSq6LC_ggmGJUcaZ5q3S4fEezwK665g=.8a2064f6-6462-48bc-95a7-9f5e5ecef5ae@github.com>
Message-ID: <Q9pk9Sq7yG3TVD_UOxVCUWuO0NYmk430i7i5u3x0uuM=.e09c1c57-da34-41d3-8de3-19dd11734a98@github.com>

On Thu, 3 Jul 2025 07:30:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] we can drop the change to WindowsPath.

`WindowsPath` change reverted in 3e994d2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26080#discussion_r2183159076

From alanb at openjdk.org  Thu Jul  3 16:19:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 16:19:38 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v3]
In-Reply-To: <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>
Message-ID: <ftAw_-UGhuyC16rd-gbgbUzVqA6cJvcZU7BKN6SesSY=.9a7130ac-6c1d-471b-9c7d-42c582b32169@github.com>

On Thu, 3 Jul 2025 15:58:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Revert change to WindowsPath

Good, I assume you'll drop the left over copyright update from WindowsPath.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26080#pullrequestreview-2983801679

From bpb at openjdk.org  Thu Jul  3 17:56:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 17:56:56 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v4]
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <Ag3CFyo_s2134LYO7Ut9cBmj2TvxOYNHGFJFYJSEHtE=.f88973b8-b8f1-4768-a697-4c5ba732610b@github.com>

> Ignore empty name elements in `WindowsPath.normalize()`.

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

  8360028: Revert copyright year in WindowsPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26080/files
  - new: https://git.openjdk.org/jdk/pull/26080/files/3e994d2e..74fc8ec9

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

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

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

From bpb at openjdk.org  Thu Jul  3 17:56:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 17:56:56 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v3]
In-Reply-To: <ftAw_-UGhuyC16rd-gbgbUzVqA6cJvcZU7BKN6SesSY=.9a7130ac-6c1d-471b-9c7d-42c582b32169@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>
 <ftAw_-UGhuyC16rd-gbgbUzVqA6cJvcZU7BKN6SesSY=.9a7130ac-6c1d-471b-9c7d-42c582b32169@github.com>
Message-ID: <Kkw2SVQL-kjaPBHd8vBwYcb0vkMqCx4aP_swZwyWnRg=.0903c075-7cb8-4f78-a449-70981ce2fab6@github.com>

On Thu, 3 Jul 2025 16:16:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Good, I assume you'll drop the left over copyright update from WindowsPath.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3033088843

From alanb at openjdk.org  Thu Jul  3 18:00:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 18:00:38 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v4]
In-Reply-To: <Ag3CFyo_s2134LYO7Ut9cBmj2TvxOYNHGFJFYJSEHtE=.f88973b8-b8f1-4768-a697-4c5ba732610b@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <Ag3CFyo_s2134LYO7Ut9cBmj2TvxOYNHGFJFYJSEHtE=.f88973b8-b8f1-4768-a697-4c5ba732610b@github.com>
Message-ID: <bbi3DJWDRX8n39TFPLf9AV67gBAP5cPj_p7Tu1m5b8E=.bf393f24-837b-4744-a495-602ed4414220@github.com>

On Thu, 3 Jul 2025 17:56:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Revert copyright year in WindowsPath

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26080#pullrequestreview-2984141312

From alanb at openjdk.org  Thu Jul  3 18:04:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 18:04:39 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
Message-ID: <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>

On Thu, 3 Jul 2025 15:30:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/Buffer/GetChars.java line 75:
>> 
>>> 73: 
>>> 74:     @Test
>>> 75:     public void testSrcBeginIsNegationOfPosition() {
>> 
>> I skimmed through GetChars and I see it only tests a CB created with CharBuffer.wrap, only testGetChars tests all char buffers. All the test methods should be tested all char buffer implementations. So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).
>
>> So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).
> 
> Agreed. I also noticed it is TestNG now.

Okay, let's create a follow-up issue for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183428833

From alanb at openjdk.org  Thu Jul  3 18:07:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 18:07:41 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <ySuL9kO_UyzQq6ulEFYIOEV7deBYKmOUjMEjjOZ4zVw=.55bbc36b-27e1-406c-83b5-e6e46d85e8a3@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26104#pullrequestreview-2984170581

From bchristi at openjdk.org  Thu Jul  3 18:14:40 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 3 Jul 2025 18:14:40 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <9rki3teH2JS04QJZA4zEmory8F8vnRhRnh9bBOIEey0=.3ac76f66-e9e0-45dd-bc5e-0c8bec56632c@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2984204948

From bpb at openjdk.org  Thu Jul  3 18:56:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 18:56:44 GMT
Subject: Integrated: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <4e3c8RvH9gEIHXAGjg1DYLu46ufAbgNoAK_mrym5Bkk=.e8805bd3-8845-448d-ba6f-16b9f0b3d7d9@github.com>

On Tue, 1 Jul 2025 22:36:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore empty name elements in `WindowsPath.normalize()`.

This pull request has now been integrated.

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

8360028: (fs) Path.relativize throws StringIndexOutOfBoundsException (win)

Reviewed-by: alanb

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

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

From rriggs at openjdk.org  Fri Jul  4 03:04:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Jul 2025 03:04:40 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2985267261

From kbarrett at openjdk.org  Fri Jul  4 04:11:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Jul 2025 04:11:53 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
 <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>
Message-ID: <9T0IH7MPf51_gVvSapU43ys6JbPVpWU3gEuAaJyjJ_k=.692c5970-60cc-4392-b80c-9b89c5b8e3bd@github.com>

On Fri, 4 Jul 2025 03:02:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add @Override for clean() method
>>  - more commentary for reserveMemory
>
> Marked as reviewed by rriggs (Reviewer).

Thanks for reviews, @RogerRiggs and @bchristi-git

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

PR Comment: https://git.openjdk.org/jdk/pull/25289#issuecomment-3034379255

From kbarrett at openjdk.org  Fri Jul  4 04:11:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Jul 2025 04:11:55 GMT
Subject: Integrated: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <e2Cn6EXWN9GlXf3sVF3FPLHKZ4FlmiuWn-smzoGrxeE=.935becee-1978-48d0-ba11-02a3180eb89b@github.com>

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

This pull request has now been integrated.

Changeset: 21f2e9a7
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21f2e9a71c31320a8b1248e3970a82b871c63c2b
Stats:     524 lines in 9 files changed: 480 ins; 24 del; 20 mod

8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner

Reviewed-by: rriggs, bchristi

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

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

From duke at openjdk.org  Mon Jul  7 13:17:43 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 7 Jul 2025 13:17:43 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
 <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>
Message-ID: <yiULwOAeWizw3ZahXxx4vYdEYWfU6JRfNTeO1At6gLA=.05992cbe-e609-4c7a-80d3-db77f78d9c11@github.com>

On Thu, 3 Jul 2025 18:02:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).
>> 
>> Agreed. I also noticed it is TestNG now.
>
> Okay, let's create a follow-up issue for that.

Could there also be value in a more generic `CharBufferAsCharSequenceTest` test which covers the entirety of the `CharSequence` interface on the various `CharBuffer` implementations in various "states" (position, offset, limit, etc.)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2190061803

From duke at openjdk.org  Mon Jul  7 22:03:51 2025
From: duke at openjdk.org (duke)
Date: Mon, 7 Jul 2025 22:03:51 GMT
Subject: Withdrawn: 8355938: Addressed rare lost unpark bug 8074773 by
 pre-loading LockSupport.class
In-Reply-To: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
References: <tcZkZgScJXJYpRK68NSRUTl7gcOhePhABSQz0DOzArI=.137600e0-7656-4c7a-85de-c340173467fc@github.com>
Message-ID: <qo6413IipMwAHrTk2AUKTjLSM5Ea-czi3MfwYkduTe0=.6ba4abfa-2a69-4b67-99f0-b297e03f4dd2@github.com>

On Tue, 29 Apr 2025 17:02:38 GMT, kabutz <duke at openjdk.org> wrote:

> In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization.
> 
> Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():
> 
> 
> static {
>     // Prevent rare disastrous classloading in first call to LockSupport.park.
>     // See: https://bugs.openjdk.java.net/browse/JDK-8074773
>     Class<?> ensureLoaded = LockSupport.class;
> }
> 
> 
> Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:
> 
> sun.nio.ch.Poller
> jdk.internal.misc.ThreadFlock
> java.util.concurrent.ThreadPerTaskExecutor
> 
> It should probably also be in:
> 
> java.util.concurrent.Exchanger
> 
> Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.

This pull request has been closed without being integrated.

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

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

From dclarke at openjdk.org  Tue Jul  8 14:36:24 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Jul 2025 14:36:24 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM
 APIs
Message-ID: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>

This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.

These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.

I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

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

Commit messages:
 - feedback
 - general cleanup
 - small refactoring
 - Performance
 - implementing feedback
 - removed unrelated change
 - merge master into branch
 - panamization of kqueue

Changes: https://git.openjdk.org/jdk/pull/25546/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360025
  Stats: 1489 lines in 14 files changed: 1306 ins; 121 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/25546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25546/head:pull/25546

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

From pminborg at openjdk.org  Tue Jul  8 14:36:25 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Jul 2025 14:36:25 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

Some of the files are missing a blank line at the end.

src/java.base/macosx/classes/jdk/internal/ffi/generated/BindingUtils.java line 45:

> 43:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
> 44:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
> 45:     public static final ValueLayout.OfLong C_LONG = ValueLayout.JAVA_LONG;

This is `int` on Windows. So, we could perhaps use `Linker.nativeLinker().canonicalLayouts().get("long")` here? "size_t" and "wchar_t" are other canonical layouts that may differ across platforms.

src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 260:

> 258:      * }
> 259:      */
> 260:     public static int kevent64(int kq, MemorySegment changelist, int nchanges, MemorySegment eventlist, int nevents, int flags, MemorySegment timeout) {

Is this method ever used?

src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 261:

> 259:      */
> 260:     public static int kevent64(int kq, MemorySegment changelist, int nchanges, MemorySegment eventlist, int nevents, int flags, MemorySegment timeout) {
> 261:         var adapted$ = kevent64.ADAPTED;

Why do we do this intermediary step? What is the reason for bringing `kevent64.ADAPTED` on the stack, as it is only used once? I know this is a pattern of jextract's.

src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 263:

> 261:         var adapted$ = kevent64.ADAPTED;
> 262:         try {
> 263:             if (FFMUtils.TRACE_DOWNCALLS) {

I wonder what the price of this `if` branch might be (if any)? The javac compiler probably sees the 

`public static final boolean TRACE_DOWNCALLS = false;` as constant foldable and can eliminate the code at compile time.

src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 44:

> 42:  */
> 43: 
> 44: class KQueue {

This class could be `final`

src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 63:

> 61: 
> 62:     // filters
> 63:     static final int EVFILT_READ  = kqueue_h.EVFILT_READ();

Could we remove these constants and use `kqueue_h` constants directly?

src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 121:

> 119:                             kqfd, keventMS, 1, NULL,
> 120:                             0, NULL);
> 121:                 } while ((result == -1));

Is there a constant for this magic `-1`?

src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 147:

> 145:                     nevents, tsp);
> 146:             if (result < 0) {
> 147:                 if (result == errno_h.EINTR()) {

Shouldn't this be `result == -errno_h.EINTR()` instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-2987207196
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2156432012
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121817152
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121808733
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121802519
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121817810
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2156409376
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121812502
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121782927

From dclarke at openjdk.org  Tue Jul  8 14:36:25 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Tue, 8 Jul 2025 14:36:25 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>
Message-ID: <CAUA-5Kouk3oFWDX2g28AX3_v96yPyPRS15nYJG_YUQ=.e0473680-b68e-4200-9281-51354bb93002@github.com>

On Thu, 19 Jun 2025 08:19:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> src/java.base/macosx/classes/jdk/internal/ffi/generated/BindingUtils.java line 45:
> 
>> 43:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
>> 44:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
>> 45:     public static final ValueLayout.OfLong C_LONG = ValueLayout.JAVA_LONG;
> 
> This is `int` on Windows. So, we could perhaps use `Linker.nativeLinker().canonicalLayouts().get("long")` here? "size_t" and "wchar_t" are other canonical layouts that may differ across platforms.

I think this is a good idea and would allow us to make BindingUtils shared,
Though I wonder if it's best to move BindingUtils to be shared, or if its worth merging it into FFMUtils. I'd favour the second option

> src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 263:
> 
>> 261:         var adapted$ = kevent64.ADAPTED;
>> 262:         try {
>> 263:             if (FFMUtils.TRACE_DOWNCALLS) {
> 
> I wonder what the price of this `if` branch might be (if any)? The javac compiler probably sees the 
> 
> `public static final boolean TRACE_DOWNCALLS = false;` as constant foldable and can eliminate the code at compile time.

I think that's a good question, I can do some testing with it removed to see if theres any gain to be had

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2159147090
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2140347487

From alanb at openjdk.org  Tue Jul  8 14:36:26 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Jul 2025 14:36:26 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <LhFU7gwSkKsCsQXHIx3vT1hx_nZpDb0u5n4tMkpPyy0=.6dca580e-40a0-42c3-858b-cd178211e057@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 124:

> 122:                         kqfd, keventMS, 1, NULL,
> 123:                         0, NULL);
> 124:             } while ((result == KQUEUE_ERROR_VALUE));

The only case where the syscall should be restarted is EINTR.

src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 152:

> 150:                     return IOStatus.INTERRUPTED;
> 151:                 } else {
> 152:                     throw new IOException("kqueue_poll failed");

The syscall is "kqueue" rather than "kqueue_poll".

src/java.base/macosx/classes/sun/nio/ch/KQueuePoller.java line 41:

> 39:     private final int filter;
> 40:     private final int maxEvents;
> 41:     private final MemorySegment pollArrayRegions;

This is a poll array so I think very confusing to see "Regions" in the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2166376862
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2166377830
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2166368230

From liach at openjdk.org  Tue Jul  8 14:36:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Jul 2025 14:36:26 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <y_Uajk8J8-UKIidMzhVQWZGLJf2AhLrH2cm5cmYn2-8=.f7b6f6e1-e383-4980-9ce2-61c060592d2d@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.ffi.util;

If this is some general ffm utils for using ffm, you can put it in jdk.internal.foreign.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2117042413

From pminborg at openjdk.org  Tue Jul  8 14:36:26 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Jul 2025 14:36:26 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <y_Uajk8J8-UKIidMzhVQWZGLJf2AhLrH2cm5cmYn2-8=.f7b6f6e1-e383-4980-9ce2-61c060592d2d@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <y_Uajk8J8-UKIidMzhVQWZGLJf2AhLrH2cm5cmYn2-8=.f7b6f6e1-e383-4980-9ce2-61c060592d2d@github.com>
Message-ID: <q8Pxi-gMRw-wvEJciu7H7bPrUd4dp7qfXGKdt_FN4-g=.bf01b2c5-2912-424f-b39a-7cab8c8e845e@github.com>

On Sat, 31 May 2025 02:07:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 26:
> 
>> 24:  */
>> 25: 
>> 26: package jdk.internal.ffi.util;
> 
> If this is some general ffm utils for using ffm, you can put it in jdk.internal.foreign.

These methods are only intended to be used for "panamization" and are not for general use. So, this is the reason we propose to have them here. But maybe some of them might be of general interest?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2121790738

From alanb at openjdk.org  Tue Jul  8 15:10:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Jul 2025 15:10:41 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <NRKKo4sm-LdyM_dDmAllsw6OVh0AuCkr4o1uWc52Ns4=.7a37e85b-d1be-40a5-ac94-b357a008b2e3@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

I plan to review this but may be a week or two before I can get to it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25546#issuecomment-3049334858

From alanb at openjdk.org  Tue Jul  8 18:16:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Jul 2025 18:16:40 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <K2muH5DUzEhNWWO1gG7PhBFSYfK9g_geD3eM-V-ASMI=.504a280f-0126-4286-b917-1ceb0e3929a8@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <UmjHhAmdYONuXYwHGOY74XKHZeDKBjtfXF5ESDuSHGY=.d30ac15d-fa60-4880-a4c8-556505493bbf@github.com>
 <MCduZE958EiKd2K3UpGiF3Rb-CHlCBUJsbuVXRTmadM=.c234fe3f-f9a3-4848-9d62-2a2ac5c66a51@github.com>
 <qllpKbtzUIJ-dJPNiGZSBEvLSypkWga2vh2a8VKhNJI=.41f015a0-0a64-4c00-99cd-d2b2fc0544c5@github.com>
 <K2muH5DUzEhNWWO1gG7PhBFSYfK9g_geD3eM-V-ASMI=.504a280f-0126-4286-b917-1ceb0e3929a8@github.com>
Message-ID: <pqF8BOad6rY3f-E8nv1ilPjKj4cLgHVcu3OekFnvvv4=.4da8c66a-0d95-46e9-b254-2ade7155c83d@github.com>

On Fri, 13 Jun 2025 07:44:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think it's okay, it's just that the change is a reminder that all ThreadTracker usages can be replaced with a ScopedValue<Boolean> but may require a bit of work to allow using during early VM startup.
>
> I chatted with Andrew Haley yesterday about allowing ScopedValue be used in early startup. Charset is initialized very early in initPhase1, when initializing the system properties, so easy to get recursive initialization issues that surface or NPE or other exceptions.  There are several ways we can fix this and it means that TRACKER is not needed. I don't mind if we change it to use a StableValue now but I expect we will change it very soon to remove ThreadTracker and just replace with ScopedValue.

The issue with using ScopedValue early in startup is resolved so we can use `private static final ScopedValue<Boolean> IN_LOOKUP = ScopedValue.newInstance();` and get rid of the use of ThreadTracker from this class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25727#discussion_r2193153617

From bpb at openjdk.org  Wed Jul  9 16:05:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Jul 2025 16:05:39 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <yiULwOAeWizw3ZahXxx4vYdEYWfU6JRfNTeO1At6gLA=.05992cbe-e609-4c7a-80d3-db77f78d9c11@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
 <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>
 <yiULwOAeWizw3ZahXxx4vYdEYWfU6JRfNTeO1At6gLA=.05992cbe-e609-4c7a-80d3-db77f78d9c11@github.com>
Message-ID: <CMv9z4LDu0_V5VLSFPQE82xT_brxlcH8o_lgXS2k8o4=.9b3d1fad-3570-4249-b0b8-2d3d3fc6ef3f@github.com>

On Mon, 7 Jul 2025 13:14:44 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Okay, let's create a follow-up issue for that.
>
> Could there also be value in a more generic `CharBufferAsCharSequenceTest` test which covers the entirety of the `CharSequence` interface on the various `CharBuffer` implementations in various "states" (position, offset, limit, etc.)?

Please see https://bugs.openjdk.org/browse/JDK-8361715.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2195403477

From bpb at openjdk.org  Wed Jul  9 16:17:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Jul 2025 16:17:44 GMT
Subject: Integrated: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification
In-Reply-To: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
Message-ID: <npxY8-79TyqAFZtcK8YWcQW5aiYuDVgPwaJZdOBw_d8=.bc48aa1b-e0ea-4be2-bba5-13c2fe0f8d33@github.com>

On Wed, 2 Jul 2025 20:24:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

This pull request has now been integrated.

Changeset: 6249259c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6249259c8050f280fb1c489e816f09d5cd72a54b
Stats:     43 lines in 2 files changed: 28 ins; 3 del; 12 mod

8361299: (bf) CharBuffer.getChars(int,int,char[],int) violates pre-existing specification

Reviewed-by: alanb, liach

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

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

From bpb at openjdk.org  Wed Jul  9 20:38:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Jul 2025 20:38:11 GMT
Subject: [jdk25] RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification
Message-ID: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>

Hi all,

This pull request contains a backport of commit [6249259c](https://github.com/openjdk/jdk/commit/6249259c8050f280fb1c489e816f09d5cd72a54b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Brian Burkhalter on 9 Jul 2025 and was reviewed by Alan Bateman and Chen Liang.

Thanks!

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

Commit messages:
 - Backport 6249259c8050f280fb1c489e816f09d5cd72a54b

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

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

From liach at openjdk.org  Wed Jul  9 20:44:38 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Jul 2025 20:44:38 GMT
Subject: [jdk25] RFR: 8361299: (bf) CharBuffer.getChars(int, int, char[],
 int) violates pre-existing specification
In-Reply-To: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>
References: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>
Message-ID: <_rFbRDWt3XSTTnYvxqpwr5q3wnkq5IoYDxMZIOBNSqo=.6e84e19f-6b93-4c89-88ce-01c8e27240b4@github.com>

On Wed, 9 Jul 2025 20:34:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [6249259c](https://github.com/openjdk/jdk/commit/6249259c8050f280fb1c489e816f09d5cd72a54b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Brian Burkhalter on 9 Jul 2025 and was reviewed by Alan Bateman and Chen Liang.
> 
> Thanks!

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26227#pullrequestreview-3003028182

From alanb at openjdk.org  Thu Jul 10 05:53:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Jul 2025 05:53:49 GMT
Subject: [jdk25] RFR: 8361299: (bf) CharBuffer.getChars(int, int, char[],
 int) violates pre-existing specification
In-Reply-To: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>
References: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>
Message-ID: <Mm9dbcp8o5ZCSNYNChCqlCETc8cteRIPMIep5pZOD-A=.36319e83-506b-471f-b605-a0172d4d2a9f@github.com>

On Wed, 9 Jul 2025 20:34:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [6249259c](https://github.com/openjdk/jdk/commit/6249259c8050f280fb1c489e816f09d5cd72a54b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Brian Burkhalter on 9 Jul 2025 and was reviewed by Alan Bateman and Chen Liang.
> 
> Thanks!

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26227#pullrequestreview-3004036257

From bpb at openjdk.org  Thu Jul 10 15:17:45 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 10 Jul 2025 15:17:45 GMT
Subject: [jdk25] Integrated: 8361299: (bf)
 CharBuffer.getChars(int,int,char[],int) violates pre-existing specification
In-Reply-To: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>
References: <V3I07kk3mj7jFHART6fVDMXTidwNnKgg1Gf6QRYFUyg=.8bbf0be2-1648-4b1e-9feb-00226c419149@github.com>
Message-ID: <FZnxpi6_cLuC9elbxcA414bx1CdIehdPjO0obQKZODw=.9833b9cd-cb15-4192-ab3f-75b71a5248f3@github.com>

On Wed, 9 Jul 2025 20:34:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [6249259c](https://github.com/openjdk/jdk/commit/6249259c8050f280fb1c489e816f09d5cd72a54b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Brian Burkhalter on 9 Jul 2025 and was reviewed by Alan Bateman and Chen Liang.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 9b99ed8b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b99ed8b399fd587ba5cb73a44f73895a97277bf
Stats:     43 lines in 2 files changed: 28 ins; 3 del; 12 mod

8361299: (bf) CharBuffer.getChars(int,int,char[],int) violates pre-existing specification

Reviewed-by: liach, alanb
Backport-of: 6249259c8050f280fb1c489e816f09d5cd72a54b

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

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

From bpb at openjdk.org  Thu Jul 10 20:34:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 10 Jul 2025 20:34:53 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods
Message-ID: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>

For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.

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

Commit messages:
 - 8361209: (bf) Use CharSequence::getChars for StringCharBuffer bulk get methods

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

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

From bpb at openjdk.org  Thu Jul 10 20:34:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 10 Jul 2025 20:34:53 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods
In-Reply-To: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
Message-ID: <ke6QEQA_H57rb_Bylff6dVgAARu_QY4dET7pXawAIIA=.e54e8eec-e726-4387-b782-49bd2357b7a3@github.com>

On Thu, 10 Jul 2025 20:27:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.

The throughput of the methods affected is increased by approximately 4.8X. Sample results:

**Master branch**

Result "org.openjdk.bench.java.nio.StringCharBufferBulkGet.absoluteBulkGet":
  531557.108 ?(99.9%) 6055.644 ops/s [Average]
  (min, avg, max) = (529972.576, 531557.108, 533558.521), stdev = 1572.632
  CI (99.9%): [525501.464, 537612.752] (assumes normal distribution)

**This branch**

Result "org.openjdk.bench.java.nio.StringCharBufferBulkGet.absoluteBulkGet":
  2547276.973 ?(99.9%) 6955.224 ops/s [Average]
  (min, avg, max) = (2544172.461, 2547276.973, 2548847.355), stdev = 1806.250
CI (99.9%): [2540321.749, 2554232.197] (assumes normal distribution)

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

PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3058968191

From duke at openjdk.org  Mon Jul 14 12:43:33 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 14 Jul 2025 12:43:33 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and migrate
 to JUnit
Message-ID: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>

junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

Commit messages:
 - whitespace
 - move parameterized data creation into method
 - linux line endings and subSequence test
 - JDK-8361715: create junit for CharSequence behavior of CharBuffer

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

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

From liach at openjdk.org  Mon Jul 14 12:43:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Jul 2025 12:43:33 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <jQ2ldTG9wziY3OmjK-fKPNEVhE3kYrsgUfWE_o2-bps=.90b4606f-295f-46e6-ad0c-dc33dff7ad54@github.com>

On Sun, 13 Jul 2025 23:56:28 GMT, Brett Okken <duke at openjdk.org> wrote:

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

Unfortunately JDK guide asks to keep line ending as-is for git config, which makes fixing line ending problems easier if they exist, but make it harder to create new files with correct LF line endings on Windows.

Also one question about this static final List in class: Is this done from a performance POV? I usually just build the stream or list of arguments in the static factory method.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3067828407

From duke at openjdk.org  Mon Jul 14 12:43:34 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 14 Jul 2025 12:43:34 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit
In-Reply-To: <jQ2ldTG9wziY3OmjK-fKPNEVhE3kYrsgUfWE_o2-bps=.90b4606f-295f-46e6-ad0c-dc33dff7ad54@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <jQ2ldTG9wziY3OmjK-fKPNEVhE3kYrsgUfWE_o2-bps=.90b4606f-295f-46e6-ad0c-dc33dff7ad54@github.com>
Message-ID: <n98LYVecTT28K-urDytHF5sJi72vcq0FF1VDELK2UxE=.13683321-9eaa-4d68-b1b2-5058e7f6d388@github.com>

On Mon, 14 Jul 2025 04:52:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Unfortunately JDK guide asks to keep line ending as-is for git config, which makes fixing line ending problems easier if they exist, but make it harder to create new files with correct LF line endings on Windows.
> 
> Also one question about this static final List in class: Is this done from a performance POV? I usually just build the stream or list of arguments in the static factory method.

@liach line endings have been fixed.

The static list was from POV of performance, but it is not all that expensive to recreate each time, if that is preferred.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3069269662

From duke at openjdk.org  Mon Jul 14 12:43:34 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 14 Jul 2025 12:43:34 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <d_WxrEviLZOkF0N_ROfzrrEdpnX-eKXs1g-WV_XI104=.4817fc69-d529-463b-8cd2-397dc5500e5b@github.com>

On Sun, 13 Jul 2025 23:56:28 GMT, Brett Okken <duke at openjdk.org> wrote:

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

The getChars test does fail when run with builds of jdk 25 prior to the fix for https://bugs.openjdk.org/browse/JDK-8361299.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3069374475

From duke at openjdk.org  Mon Jul 14 13:07:25 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 14 Jul 2025 13:07:25 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v2]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  add tests for failure conditions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/fd92e8de..b74bb50c

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

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

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

From duke at openjdk.org  Mon Jul 14 13:18:39 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 14 Jul 2025 13:18:39 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v2]
In-Reply-To: <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>
Message-ID: <ZYI5BGo1xev1sejr8aOJWnviiA9Km2CbfSjgNjIa3L8=.ad696b93-6144-44da-b6de-327b41f4e1b0@github.com>

On Mon, 14 Jul 2025 13:07:25 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add tests for failure conditions

Should I add test data for CharBuffer coming from 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/ByteBuffer.html#asCharBuffer()

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3069585199

From bpb at openjdk.org  Mon Jul 14 21:43:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Jul 2025 21:43:25 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v2]
In-Reply-To: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
Message-ID: <77tq4eXWew4MW-b_Xn_gvVmesEIQmWOaq4hEXsde0aA=.2cc8deac-ba44-4d08-b372-fcf1924513ee@github.com>

> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.

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

  8361209: Fix problems due to ignoring slice offset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26251/files
  - new: https://git.openjdk.org/jdk/pull/26251/files/bed82d4b..fb5ea838

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

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

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

From bpb at openjdk.org  Mon Jul 14 21:51:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Jul 2025 21:51:38 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit
In-Reply-To: <d_WxrEviLZOkF0N_ROfzrrEdpnX-eKXs1g-WV_XI104=.4817fc69-d529-463b-8cd2-397dc5500e5b@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <d_WxrEviLZOkF0N_ROfzrrEdpnX-eKXs1g-WV_XI104=.4817fc69-d529-463b-8cd2-397dc5500e5b@github.com>
Message-ID: <dVqEGXf27ldpvwnPS-9hu7iK3wf2OaXWxuXDHv1jnUM=.827bc7e4-6ae3-4849-a2a5-a3d868267704@github.com>

On Mon, 14 Jul 2025 12:40:18 GMT, Brett Okken <duke at openjdk.org> wrote:

> The getChars test does fail when run with builds of jdk 25 prior to the fix for https://bugs.openjdk.org/browse/JDK-8361299.

Good, that is expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3071139780

From bpb at openjdk.org  Mon Jul 14 21:51:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Jul 2025 21:51:39 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v2]
In-Reply-To: <ZYI5BGo1xev1sejr8aOJWnviiA9Km2CbfSjgNjIa3L8=.ad696b93-6144-44da-b6de-327b41f4e1b0@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>
 <ZYI5BGo1xev1sejr8aOJWnviiA9Km2CbfSjgNjIa3L8=.ad696b93-6144-44da-b6de-327b41f4e1b0@github.com>
Message-ID: <Jnyxo2yXhDfmL1l7QRlcy7lM8ZeKYUtnLyVp2iipi9k=.a5a00822-cd05-47de-8e88-35e5cdde436c@github.com>

On Mon, 14 Jul 2025 13:16:24 GMT, Brett Okken <duke at openjdk.org> wrote:

> Should I add test data for CharBuffer coming from
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/ByteBuffer.html#asCharBuffer()

There is not usually any harm in having more test coverage.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3071141485

From duke at openjdk.org  Tue Jul 15 11:27:40 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 15 Jul 2025 11:27:40 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v2]
In-Reply-To: <77tq4eXWew4MW-b_Xn_gvVmesEIQmWOaq4hEXsde0aA=.2cc8deac-ba44-4d08-b372-fcf1924513ee@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <77tq4eXWew4MW-b_Xn_gvVmesEIQmWOaq4hEXsde0aA=.2cc8deac-ba44-4d08-b372-fcf1924513ee@github.com>
Message-ID: <H8RBW1CmU8DpB4XGKQjm2yN_CJvRmi2LY2hZc7J1Uys=.aa051050-3be1-47d6-a4c8-c82750761a1b@github.com>

On Mon, 14 Jul 2025 21:43:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361209: Fix problems due to ignoring slice offset

I think all 3 of those methods are implemented in the template to call through to a private `getArray` method in the template. Would it be simpler to make that method package scope and override it in StringCharBuffer?
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L953

In the X-Buffer template, there is a bulk putBuffer, with special handling for when the source is a `StringCharBuffer` to copy one byte at time.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1150-L1157
If the source is a `StringCharBuffer` and the instance we are putting into has a `char[]`, we should be able to use bulk transfer.

Maybe something like:


        } else { // src.isAddressable() == false
            assert StringCharBuffer.class.isInstance(src);
            if (this.hb != null) {
                ((StringCharBuffer) src).getArray(srcPos, this.hb, pos, n);
            } else {
                int posMax = pos + n;
                for (int i = pos, j = srcPos; i < posMax; i++, j++)
                    put(i, src.get(j));
            }
        }

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

PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3073206634
PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3073229159

From duke at openjdk.org  Tue Jul 15 11:56:26 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 15 Jul 2025 11:56:26 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v3]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <BlHG3uESFTFVTEBCm2grSl_tkn9EqPaWd3GWtW2MQ0E=.77d38d83-5480-4b1a-9994-b8e3670dfe88@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  add coverage for ByteBuffer as CharBuffer and test for codePoints

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/b74bb50c..bc3f5771

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

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

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

From alanb at openjdk.org  Tue Jul 15 13:04:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Jul 2025 13:04:40 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v2]
In-Reply-To: <Jnyxo2yXhDfmL1l7QRlcy7lM8ZeKYUtnLyVp2iipi9k=.a5a00822-cd05-47de-8e88-35e5cdde436c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>
 <ZYI5BGo1xev1sejr8aOJWnviiA9Km2CbfSjgNjIa3L8=.ad696b93-6144-44da-b6de-327b41f4e1b0@github.com>
 <Jnyxo2yXhDfmL1l7QRlcy7lM8ZeKYUtnLyVp2iipi9k=.a5a00822-cd05-47de-8e88-35e5cdde436c@github.com>
Message-ID: <fvHrq6zZljvrnnMWaDnHqtABGLR7axRUCxIaF5L7zqc=.f88e307f-aa66-4f0c-aeae-c9256bb6075b@github.com>

On Mon, 14 Jul 2025 21:49:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Should I add test data for CharBuffer coming from 
>> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/ByteBuffer.html#asCharBuffer()
>
>> Should I add test data for CharBuffer coming from
>> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/ByteBuffer.html#asCharBuffer()
> 
> There is not usually any harm in having more test coverage.

@bplb Do you mind checking how this overlaps with existing tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3073511715

From bpb at openjdk.org  Tue Jul 15 15:31:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 15:31:40 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v2]
In-Reply-To: <Jnyxo2yXhDfmL1l7QRlcy7lM8ZeKYUtnLyVp2iipi9k=.a5a00822-cd05-47de-8e88-35e5cdde436c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>
 <ZYI5BGo1xev1sejr8aOJWnviiA9Km2CbfSjgNjIa3L8=.ad696b93-6144-44da-b6de-327b41f4e1b0@github.com>
 <Jnyxo2yXhDfmL1l7QRlcy7lM8ZeKYUtnLyVp2iipi9k=.a5a00822-cd05-47de-8e88-35e5cdde436c@github.com>
Message-ID: <NhgYA9PcEfiq4wWXM0xGtZJj0ZQtuGB41_2DbfaOF9U=.266e8498-02b1-4357-8262-fecf35b684fb@github.com>

On Mon, 14 Jul 2025 21:49:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Should I add test data for CharBuffer coming from 
>> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/ByteBuffer.html#asCharBuffer()
>
>> Should I add test data for CharBuffer coming from
>> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/nio/ByteBuffer.html#asCharBuffer()
> 
> There is not usually any harm in having more test coverage.

> @bplb Do you mind checking how this overlaps with existing tests?

Will do.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3074138114

From bpb at openjdk.org  Tue Jul 15 21:35:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 21:35:01 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v3]
In-Reply-To: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
Message-ID: <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>

> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.

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

  8361209: Override getArray instead of API methods; modify absolute bulk put to use getArray for StringCharBuffer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26251/files
  - new: https://git.openjdk.org/jdk/pull/26251/files/fb5ea838..dce00b5a

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

  Stats: 38 lines in 3 files changed: 10 ins; 22 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26251/head:pull/26251

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

From bpb at openjdk.org  Tue Jul 15 21:35:01 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 21:35:01 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v2]
In-Reply-To: <H8RBW1CmU8DpB4XGKQjm2yN_CJvRmi2LY2hZc7J1Uys=.aa051050-3be1-47d6-a4c8-c82750761a1b@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <77tq4eXWew4MW-b_Xn_gvVmesEIQmWOaq4hEXsde0aA=.2cc8deac-ba44-4d08-b372-fcf1924513ee@github.com>
 <H8RBW1CmU8DpB4XGKQjm2yN_CJvRmi2LY2hZc7J1Uys=.aa051050-3be1-47d6-a4c8-c82750761a1b@github.com>
Message-ID: <tW-PtSdzwfAybSV6ywb9N0SjDTZLZTm20BMhweAQK7U=.e18e2e3d-2958-497b-b7c8-e903e50b9cc2@github.com>

On Tue, 15 Jul 2025 11:17:37 GMT, Brett Okken <duke at openjdk.org> wrote:

> Would it be simpler to make that method package scope and override it in StringCharBuffer?

Yes, that is definitely cleaner and simpler and uses less code. Please see dce00b5. Thanks for the suggestion!

> If the source is a `StringCharBuffer` and the instance we are putting into has a `char[]`, we should be able to use bulk transfer.

Yes, this works. Please again see dce00b5. I also added a `@Benchmark` to the micro to cover this. Performance is about 5x versus before.

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

PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3075774759
PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3075778666

From bpb at openjdk.org  Tue Jul 15 21:42:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 21:42:40 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v3]
In-Reply-To: <BlHG3uESFTFVTEBCm2grSl_tkn9EqPaWd3GWtW2MQ0E=.77d38d83-5480-4b1a-9994-b8e3670dfe88@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <BlHG3uESFTFVTEBCm2grSl_tkn9EqPaWd3GWtW2MQ0E=.77d38d83-5480-4b1a-9994-b8e3670dfe88@github.com>
Message-ID: <jfBqJnGOBbqBbBLL_5TGUHYfB2UHyQMzchsMkEZR54g=.9ed27559-d67c-4277-8208-8647511a6d79@github.com>

On Tue, 15 Jul 2025 11:56:26 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add coverage for ByteBuffer as CharBuffer and test for codePoints

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 24:

> 22:  */
> 23: 
> 24: import static org.junit.jupiter.api.Assertions.assertEquals;

By convention, we typically put static imports _after_ regular imports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2208758844

From bpb at openjdk.org  Tue Jul 15 21:59:40 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 21:59:40 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v3]
In-Reply-To: <BlHG3uESFTFVTEBCm2grSl_tkn9EqPaWd3GWtW2MQ0E=.77d38d83-5480-4b1a-9994-b8e3670dfe88@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <BlHG3uESFTFVTEBCm2grSl_tkn9EqPaWd3GWtW2MQ0E=.77d38d83-5480-4b1a-9994-b8e3670dfe88@github.com>
Message-ID: <bsAZSeKTkN7HEnBttL-QJ__pJpMTxKA2C_vRpI1Er-Q=.5e99bc96-dab3-49b2-a41c-dd083de35560@github.com>

On Tue, 15 Jul 2025 11:56:26 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add coverage for ByteBuffer as CharBuffer and test for codePoints

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 137:

> 135:     @ParameterizedTest
> 136:     @MethodSource("charBufferArguments")
> 137:     void testGetChars_range(CharSequence actual, char[] expected, int start, int stop, String description) {

Another small style point is that typically underscores are not used in (method) names in preference to camel case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2208788208

From bpb at openjdk.org  Tue Jul 15 23:54:43 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Jul 2025 23:54:43 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v2]
In-Reply-To: <NhgYA9PcEfiq4wWXM0xGtZJj0ZQtuGB41_2DbfaOF9U=.266e8498-02b1-4357-8262-fecf35b684fb@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <ak3PMx3Xcvf2jZNerW9vlsDmOAKrYrT-Cqzi_y4Y97E=.29268236-3ce0-4d6d-97ea-b00b79034c1a@github.com>
 <ZYI5BGo1xev1sejr8aOJWnviiA9Km2CbfSjgNjIa3L8=.ad696b93-6144-44da-b6de-327b41f4e1b0@github.com>
 <Jnyxo2yXhDfmL1l7QRlcy7lM8ZeKYUtnLyVp2iipi9k=.a5a00822-cd05-47de-8e88-35e5cdde436c@github.com>
 <NhgYA9PcEfiq4wWXM0xGtZJj0ZQtuGB41_2DbfaOF9U=.266e8498-02b1-4357-8262-fecf35b684fb@github.com>
Message-ID: <idHp4ri-VSWsyYrKqa8QL4voxWnvGZaq-NcdiQjCLZ4=.69e74081-f427-4ddd-a9ac-facdbc878150@github.com>

On Tue, 15 Jul 2025 15:29:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > @bplb Do you mind checking how this overlaps with existing tests?
> 
> Will do.

It looks like some of the range tests and the char get test overlap with `BasicChar` and `GetChars`, some of the `chars` test with `Chars`, and some of the slice testing with `StringCharBufferSliceTest`. Overall this test is focused on the correctness of the methods defined by `CharSequence` as manifested in the `CharBuffer` implementation.

The `testGetChars_range` sub-test helped me identify a problem in my PR #26251 which I then fixed.

All in all I think it adds extra coverage and is neither resource intensive nor slow.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3076100207

From duke at openjdk.org  Wed Jul 16 11:40:59 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 16 Jul 2025 11:40:59 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v4]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <YF2ZpjdAEbS6Aey-HzQWjN4-jDvvUd5q2euWd-pOMS8=.ac1995a7-9483-43db-a5d6-7fd0c1a66fe7@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  code conventions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/bc3f5771..08151468

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

  Stats: 32 lines in 1 file changed: 19 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26282/head:pull/26282

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

From duke at openjdk.org  Wed Jul 16 11:48:41 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 16 Jul 2025 11:48:41 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v4]
In-Reply-To: <YF2ZpjdAEbS6Aey-HzQWjN4-jDvvUd5q2euWd-pOMS8=.ac1995a7-9483-43db-a5d6-7fd0c1a66fe7@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <YF2ZpjdAEbS6Aey-HzQWjN4-jDvvUd5q2euWd-pOMS8=.ac1995a7-9483-43db-a5d6-7fd0c1a66fe7@github.com>
Message-ID: <lTV14RpyAmqEuWuZQMwU5bJJTLpPEx-t26BpQC4y4mk=.6fe4970f-56d0-4501-ab5d-5d04508c4829@github.com>

On Wed, 16 Jul 2025 11:40:59 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code conventions

> It looks like some of the range tests and the char get test overlap with ... `GetChars`

My intent was to be able to replace `GetChars`. I interpreted the linked [comment](https://github.com/openjdk/jdk/pull/26104#discussion_r2182361518) in the jira to express a desire to test the various edges of getChars with a broader set of `CharBuffer` implementations, which is what this test sets up for the testing parameters.

I did not carry forward the randomization of content, positions, limits, etc. because I prefer avoiding randomness in tests when it does not seem strictly required/valuable.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3078214677

From duke at openjdk.org  Wed Jul 16 15:42:41 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 16 Jul 2025 15:42:41 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v3]
In-Reply-To: <jfBqJnGOBbqBbBLL_5TGUHYfB2UHyQMzchsMkEZR54g=.9ed27559-d67c-4277-8208-8647511a6d79@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <BlHG3uESFTFVTEBCm2grSl_tkn9EqPaWd3GWtW2MQ0E=.77d38d83-5480-4b1a-9994-b8e3670dfe88@github.com>
 <jfBqJnGOBbqBbBLL_5TGUHYfB2UHyQMzchsMkEZR54g=.9ed27559-d67c-4277-8208-8647511a6d79@github.com>
Message-ID: <JwsVgEvv_Q9h62hAkD5Fk4t_VaNyfUyCNjaoN6G5ri8=.16b270fa-c0c2-423c-86c7-d18526fa6169@github.com>

On Tue, 15 Jul 2025 21:40:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add coverage for ByteBuffer as CharBuffer and test for codePoints
>
> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: import static org.junit.jupiter.api.Assertions.assertEquals;
> 
> By convention, we typically put static imports _after_ regular imports.

addressed in https://github.com/openjdk/jdk/pull/26282/commits/0815146848eb847f51f5526e5cff6a531c371806

> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 137:
> 
>> 135:     @ParameterizedTest
>> 136:     @MethodSource("charBufferArguments")
>> 137:     void testGetChars_range(CharSequence actual, char[] expected, int start, int stop, String description) {
> 
> Another small style point is that typically underscores are not used in (method) names in preference to camel case.

addressed in https://github.com/openjdk/jdk/pull/26282/commits/0815146848eb847f51f5526e5cff6a531c371806

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2210803670
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2210804024

From duke at openjdk.org  Wed Jul 16 15:47:40 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 16 Jul 2025 15:47:40 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v3]
In-Reply-To: <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>
Message-ID: <qu2IzT3lBIHU-JjVaDWRak05XL8k_B4CEGqScoQ5x5Y=.de9759ce-c068-47a8-bbb4-3c5ad9a78a16@github.com>

On Tue, 15 Jul 2025 21:35:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361209: Override getArray instead of API methods; modify absolute bulk put to use getArray for StringCharBuffer

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

> 954:         if (
> 955: #if[char]
> 956:             isAddressable() &&

is `isAddressable` only relevant for `StringCharBuffer`?
If so, this check becomes effectively dead code with `StringCharBuffer` overriding the method.
Perhaps an assert statement instead to avoid any future modification breaking the assumption?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26251#discussion_r2210816275

From bpb at openjdk.org  Wed Jul 16 21:55:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 21:55:02 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v4]
In-Reply-To: <lTV14RpyAmqEuWuZQMwU5bJJTLpPEx-t26BpQC4y4mk=.6fe4970f-56d0-4501-ab5d-5d04508c4829@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <YF2ZpjdAEbS6Aey-HzQWjN4-jDvvUd5q2euWd-pOMS8=.ac1995a7-9483-43db-a5d6-7fd0c1a66fe7@github.com>
 <lTV14RpyAmqEuWuZQMwU5bJJTLpPEx-t26BpQC4y4mk=.6fe4970f-56d0-4501-ab5d-5d04508c4829@github.com>
Message-ID: <ltyLEXxkdDAAT6MRdGCS0UZ9eMTqpK5srXG9IDzqetk=.c7a0b457-5e63-48a9-a240-cd448d525a57@github.com>

On Wed, 16 Jul 2025 11:46:06 GMT, Brett Okken <duke at openjdk.org> wrote:

> > It looks like some of the range tests and the char get test overlap with ... `GetChars`
> 
> My intent was to be able to replace `GetChars`.

That is the objective originally intended for the fix of this issue.

> I did not carry forward the randomization of content, positions, limits, etc. because I prefer avoiding randomness in tests when it does not seem strictly required/valuable.

Just to note that the test library `RandomFactory` logs the seed used and allows specifying the seed in order to replicate a given random set of parameters.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3081196858

From bpb at openjdk.org  Wed Jul 16 22:15:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 22:15:41 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v4]
In-Reply-To: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
Message-ID: <yQxUHIfA32sJmJc-jUWoc6ax9G8YfYCpJUwq_f0PxrY=.e0275397-75ae-43ad-9b1e-127e1886c1b6@github.com>

> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.

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

  8361209: In getArray(), verify non-addressable buffer not a StringCharBuffer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26251/files
  - new: https://git.openjdk.org/jdk/pull/26251/files/dce00b5a..3c88dac7

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

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

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

From bpb at openjdk.org  Wed Jul 16 22:22:49 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 22:22:49 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v3]
In-Reply-To: <qu2IzT3lBIHU-JjVaDWRak05XL8k_B4CEGqScoQ5x5Y=.de9759ce-c068-47a8-bbb4-3c5ad9a78a16@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>
 <qu2IzT3lBIHU-JjVaDWRak05XL8k_B4CEGqScoQ5x5Y=.de9759ce-c068-47a8-bbb4-3c5ad9a78a16@github.com>
Message-ID: <oHQ17V5nLWQEGtlKtgixludSZAIj-hrmsQ_KPDMU6LI=.f78418f8-8b66-463b-9cf7-4fbf29a41408@github.com>

On Wed, 16 Jul 2025 15:45:25 GMT, Brett Okken <duke at openjdk.org> wrote:

> Perhaps an assert statement instead to avoid any future modification breaking the assumption?

I added an `assert` in 3c88dac but I am not entirely sure it's the one you had in mind.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26251#discussion_r2211718015

From duke at openjdk.org  Wed Jul 16 22:57:46 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 16 Jul 2025 22:57:46 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v3]
In-Reply-To: <oHQ17V5nLWQEGtlKtgixludSZAIj-hrmsQ_KPDMU6LI=.f78418f8-8b66-463b-9cf7-4fbf29a41408@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>
 <qu2IzT3lBIHU-JjVaDWRak05XL8k_B4CEGqScoQ5x5Y=.de9759ce-c068-47a8-bbb4-3c5ad9a78a16@github.com>
 <oHQ17V5nLWQEGtlKtgixludSZAIj-hrmsQ_KPDMU6LI=.f78418f8-8b66-463b-9cf7-4fbf29a41408@github.com>
Message-ID: <IV95ZWBw9HwPUR9LvY97r03wS_6n3ImWtM0bAlY6_4w=.5ae4aded-f7a0-431c-a59e-3fa89c69bae0@github.com>

On Wed, 16 Jul 2025 22:19:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>  I am not entirely sure it's the one you had in mind.

:) yeah - I was thinking more like this:


    $Type$Buffer getArray(int index, $type$[] dst, int offset, int length) {
#if[char]
        assert !isAddressable();
#end[char]
        if (((long)length << $LG_BYTES_PER_VALUE$) > Bits.JNI_COPY_TO_ARRAY_THRESHOLD) {


But it was really just an idea to remove a check which should always be true now that overridden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26251#discussion_r2211772426

From bpb at openjdk.org  Wed Jul 16 23:15:48 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 23:15:48 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v3]
In-Reply-To: <IV95ZWBw9HwPUR9LvY97r03wS_6n3ImWtM0bAlY6_4w=.5ae4aded-f7a0-431c-a59e-3fa89c69bae0@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>
 <qu2IzT3lBIHU-JjVaDWRak05XL8k_B4CEGqScoQ5x5Y=.de9759ce-c068-47a8-bbb4-3c5ad9a78a16@github.com>
 <oHQ17V5nLWQEGtlKtgixludSZAIj-hrmsQ_KPDMU6LI=.f78418f8-8b66-463b-9cf7-4fbf29a41408@github.com>
 <IV95ZWBw9HwPUR9LvY97r03wS_6n3ImWtM0bAlY6_4w=.5ae4aded-f7a0-431c-a59e-3fa89c69bae0@github.com>
Message-ID: <f-RdyD1vXc79FEhzwLovu_FsmX9EztDHuwNeqnRjiKw=.173030f9-3b4f-441c-b585-cc57e29b6ce0@github.com>

On Wed, 16 Jul 2025 22:55:02 GMT, Brett Okken <duke at openjdk.org> wrote:

> #if[char]
>         assert !isAddressable();
> #end[char]

I think you intended `isAddressable()` in the above, not its negation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26251#discussion_r2211792089

From bpb at openjdk.org  Wed Jul 16 23:23:30 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Jul 2025 23:23:30 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v5]
In-Reply-To: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
Message-ID: <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>

> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.

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

  8361209: Fix assertion added in previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26251/files
  - new: https://git.openjdk.org/jdk/pull/26251/files/3c88dac7..11a73ffa

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

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

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

From duke at openjdk.org  Thu Jul 17 00:29:59 2025
From: duke at openjdk.org (Brett Okken)
Date: Thu, 17 Jul 2025 00:29:59 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v5]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <VU_bMaTpyDbYPlFGrA6cFNRmmWYj43YUu2HzXp32iFk=.1590ba83-de8f-4dba-aa27-0f62fcd2b06b@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  remove testng GetChars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/08151468..198e46e4

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

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

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

From duke at openjdk.org  Thu Jul 17 00:31:48 2025
From: duke at openjdk.org (Brett Okken)
Date: Thu, 17 Jul 2025 00:31:48 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v3]
In-Reply-To: <f-RdyD1vXc79FEhzwLovu_FsmX9EztDHuwNeqnRjiKw=.173030f9-3b4f-441c-b585-cc57e29b6ce0@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <HeSKewvSU26K-xyPZiqxVIBK1arhyFb0xGmRQudLVms=.0a0571d3-a20c-460e-97e6-22c0f66865ed@github.com>
 <qu2IzT3lBIHU-JjVaDWRak05XL8k_B4CEGqScoQ5x5Y=.de9759ce-c068-47a8-bbb4-3c5ad9a78a16@github.com>
 <oHQ17V5nLWQEGtlKtgixludSZAIj-hrmsQ_KPDMU6LI=.f78418f8-8b66-463b-9cf7-4fbf29a41408@github.com>
 <IV95ZWBw9HwPUR9LvY97r03wS_6n3ImWtM0bAlY6_4w=.5ae4aded-f7a0-431c-a59e-3fa89c69bae0@github.com>
 <f-RdyD1vXc79FEhzwLovu_FsmX9EztDHuwNeqnRjiKw=.173030f9-3b4f-441c-b585-cc57e29b6ce0@github.com>
Message-ID: <RKSPvqRdVR5i5pkVWg7YaXiCdNKuVN03n2-L_xNCyg8=.ec0d8510-b747-4f8f-935e-3b4ac108e065@github.com>

On Wed, 16 Jul 2025 23:12:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think you intended isAddressable() in the above, not its negation.

yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26251#discussion_r2211886038

From duke at openjdk.org  Thu Jul 17 00:43:49 2025
From: duke at openjdk.org (Brett Okken)
Date: Thu, 17 Jul 2025 00:43:49 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v5]
In-Reply-To: <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
Message-ID: <CgRcJM0tmLEupLa3Lh_ZHsY9hpHLZmfwivk-r2Y5EJ8=.008909ac-c1c5-4e1f-9149-fffad26b5062@github.com>

On Wed, 16 Jul 2025 23:23:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361209: Fix assertion added in previous commit

I am not an official reviewer, but LGTM

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

Marked as reviewed by bokken at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/26251#pullrequestreview-3027345015

From rriggs at openjdk.org  Thu Jul 17 14:04:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Jul 2025 14:04:50 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v5]
In-Reply-To: <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
Message-ID: <SCkpCkD5HBoC8wptM8EqwUrXFgTuS8U2tcCBzExyvn4=.fc34735e-da7f-443f-bdae-1bd67fe35b00@github.com>

On Wed, 16 Jul 2025 23:23:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361209: Fix assertion added in previous commit

Looks good; nice performance improvement!

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26251#pullrequestreview-3029679559

From cushon at openjdk.org  Thu Jul 17 15:25:59 2025
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 17 Jul 2025 15:25:59 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <gDgAzVOWllN9McWLxfco_q2EfeioJS8IcZL5zkHDBjY=.21f01a62-6a26-4412-9dba-258f600bc5fc@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

src/java.base/share/classes/java/nio/BufferCleaner.java line 203:

> 201:     }
> 202: 
> 203:     private static final class CleaningThread extends Thread {

Similar to https://bugs.openjdk.org/browse/JDK-8346124, should this be creating an `InnocuousThread`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25289#discussion_r2213655440

From bpb at openjdk.org  Thu Jul 17 20:17:51 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Jul 2025 20:17:51 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v5]
In-Reply-To: <SCkpCkD5HBoC8wptM8EqwUrXFgTuS8U2tcCBzExyvn4=.fc34735e-da7f-443f-bdae-1bd67fe35b00@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
 <SCkpCkD5HBoC8wptM8EqwUrXFgTuS8U2tcCBzExyvn4=.fc34735e-da7f-443f-bdae-1bd67fe35b00@github.com>
Message-ID: <5bDYHuWPsAaRa8akLR2otIT4pVBxpUhE-UihwHk8Yg8=.3ce0f265-5e1b-4728-aae4-ba2f5b44cf99@github.com>

On Thu, 17 Jul 2025 14:02:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Looks good; nice performance improvement!

@RogerRiggs and @bokken : thanks for the reviews and comments. I plan to integrate this tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3085342120

From bpb at openjdk.org  Thu Jul 17 22:24:50 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Jul 2025 22:24:50 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v4]
In-Reply-To: <ltyLEXxkdDAAT6MRdGCS0UZ9eMTqpK5srXG9IDzqetk=.c7a0b457-5e63-48a9-a240-cd448d525a57@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <YF2ZpjdAEbS6Aey-HzQWjN4-jDvvUd5q2euWd-pOMS8=.ac1995a7-9483-43db-a5d6-7fd0c1a66fe7@github.com>
 <lTV14RpyAmqEuWuZQMwU5bJJTLpPEx-t26BpQC4y4mk=.6fe4970f-56d0-4501-ab5d-5d04508c4829@github.com>
 <ltyLEXxkdDAAT6MRdGCS0UZ9eMTqpK5srXG9IDzqetk=.c7a0b457-5e63-48a9-a240-cd448d525a57@github.com>
Message-ID: <3L_tS-cSy7TB9-8DPU3jdm79z-_Uit1OcQ5v3_NMK4Q=.c41d318e-41cd-441b-baf1-92a3e3745d4e@github.com>

On Wed, 16 Jul 2025 21:51:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Just to note that the test library `RandomFactory` logs the seed used and allows specifying the seed in order to replicate a given random set of parameters.

For an example of using RandomFactory, please see the [AllocateDirectInit](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/Buffer/AllocateDirectInit.java
) test.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3085691202

From duke at openjdk.org  Fri Jul 18 13:23:11 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 18 Jul 2025 13:23:11 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v5]
In-Reply-To: <xwJxusDHN4OchAp9uwNX63F5aP4crEpLAd74LjbFsl8=.6de964a6-58fe-4d94-a2fc-5b2752d5dfd3@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <VU_bMaTpyDbYPlFGrA6cFNRmmWYj43YUu2HzXp32iFk=.1590ba83-de8f-4dba-aa27-0f62fcd2b06b@github.com>
 <xwJxusDHN4OchAp9uwNX63F5aP4crEpLAd74LjbFsl8=.6de964a6-58fe-4d94-a2fc-5b2752d5dfd3@github.com>
Message-ID: <iEun5kmr9NgIb1SWCSUcLx3KgkJa1OYTfLtZ-_PUcnA=.e981008f-d7f1-4ad1-9729-69080b47eb5c@github.com>

On Thu, 17 Jul 2025 22:22:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> It's trivial, but do you think it's worth adding a test for a `null` `dst` parameter of `getChars`?

yep

> Do you think that propagating something similar to `GetChars.testGetChars` would be worthwhile or do you think there is already sufficient coverage?

I'll take a stab at it and let me know what you think.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3089466044

From duke at openjdk.org  Fri Jul 18 13:23:11 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 18 Jul 2025 13:23:11 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v6]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <2adPKpRW64IUWplbC986YfWA6-gfGkKRxtYL1XNfRtY=.40326520-2898-4a18-9a1c-82cdd37b645f@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  add randomized test params and null dst test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/198e46e4..fe8c6043

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

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

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

From duke at openjdk.org  Fri Jul 18 14:16:45 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 18 Jul 2025 14:16:45 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v7]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <mZYjqX3duGqw9fqShYQw-lAnhj_sv5qgZLjNnipZAfk=.a4ccad08-4f40-4cca-9d5a-21f8ed46da9e@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  adjust indexes used in tests to accomodate random values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/fe8c6043..ccc8f802

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

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

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

From bpb at openjdk.org  Fri Jul 18 22:30:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Jul 2025 22:30:53 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v7]
In-Reply-To: <mZYjqX3duGqw9fqShYQw-lAnhj_sv5qgZLjNnipZAfk=.a4ccad08-4f40-4cca-9d5a-21f8ed46da9e@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <mZYjqX3duGqw9fqShYQw-lAnhj_sv5qgZLjNnipZAfk=.a4ccad08-4f40-4cca-9d5a-21f8ed46da9e@github.com>
Message-ID: <nEfvQg2n93K1r8VQW7DY9ipTUK4id-1VLrRxoLEd3KM=.44fe3eb8-b667-464f-bf34-25d336879920@github.com>

On Fri, 18 Jul 2025 14:16:45 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust indexes used in tests to accomodate random values

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 53:

> 51: 
> 52:     private static final Random RAND = RandomFactory.getRandom();
> 53:     private static final int SIZE = 128 + RAND.nextInt(1024);

You might want to use the two-arg [nextInt](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/random/RandomGenerator.html#nextInt(int,int)) here instead of an addition, e.g., `RAND.nextInt(128,1152)`.

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 66:

> 64:         int mid = cb.capacity() >>> 1;
> 65:         int start = RAND.nextInt(mid + 1); // from 0 to mid
> 66:         int end = mid + RAND.nextInt(cb.capacity() - mid + 1); // from mid to capacity

Same comment as above concerning the two-arg `nextInt`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2216997121
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2216997456

From duke at openjdk.org  Sat Jul 19 01:48:37 2025
From: duke at openjdk.org (Brett Okken)
Date: Sat, 19 Jul 2025 01:48:37 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v8]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <ZfYBJFzkiR7mLi9APWnA2tYa_Zy-pVKdg97NvgmvvIs=.fe61dcf4-b7b2-4e98-839b-40145cdea5e9@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  adjust indexes used in tests to accommodate random values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/ccc8f802..d1651d2d

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

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

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

From duke at openjdk.org  Sat Jul 19 01:54:13 2025
From: duke at openjdk.org (Brett Okken)
Date: Sat, 19 Jul 2025 01:54:13 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v9]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <l1yeraw-uV3ExEuu-bjEVuDgnX5I7-y3zi6F9iQn_V8=.dad8340f-9840-473c-bf0d-77a225bac4c5@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  use random methods which take range - and make ensure min range in use

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/d1651d2d..394832a4

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

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

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

From duke at openjdk.org  Sat Jul 19 01:54:14 2025
From: duke at openjdk.org (Brett Okken)
Date: Sat, 19 Jul 2025 01:54:14 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v7]
In-Reply-To: <nEfvQg2n93K1r8VQW7DY9ipTUK4id-1VLrRxoLEd3KM=.44fe3eb8-b667-464f-bf34-25d336879920@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <mZYjqX3duGqw9fqShYQw-lAnhj_sv5qgZLjNnipZAfk=.a4ccad08-4f40-4cca-9d5a-21f8ed46da9e@github.com>
 <nEfvQg2n93K1r8VQW7DY9ipTUK4id-1VLrRxoLEd3KM=.44fe3eb8-b667-464f-bf34-25d336879920@github.com>
Message-ID: <ZJWUHLWKiRWboIZjeHrUMZsr_ctG-vs_idQqGYfGpgA=.d02fe3d7-e010-4dc4-ad28-9436ae661999@github.com>

On Fri, 18 Jul 2025 22:27:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust indexes used in tests to accomodate random values
>
> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 53:
> 
>> 51: 
>> 52:     private static final Random RAND = RandomFactory.getRandom();
>> 53:     private static final int SIZE = 128 + RAND.nextInt(1024);
> 
> You might want to use the two-arg [nextInt](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/util/random/RandomGenerator.html#nextInt(int,int)) here instead of an addition, e.g., `RAND.nextInt(128,1152)`.

done
https://github.com/openjdk/jdk/pull/26282/commits/394832a472a03dc015ab857a679506b4e8ca34e6

> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 66:
> 
>> 64:         int mid = cb.capacity() >>> 1;
>> 65:         int start = RAND.nextInt(mid + 1); // from 0 to mid
>> 66:         int end = mid + RAND.nextInt(cb.capacity() - mid + 1); // from mid to capacity
> 
> Same comment as above concerning the two-arg `nextInt`.

done - also made sure there is a minimum "remaining" between position and limit
https://github.com/openjdk/jdk/pull/26282/commits/394832a472a03dc015ab857a679506b4e8ca34e6

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2217089822
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2217090104

From duke at openjdk.org  Sat Jul 19 16:18:53 2025
From: duke at openjdk.org (Brett Okken)
Date: Sat, 19 Jul 2025 16:18:53 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  name the parameterized tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/394832a4..65f9470a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26282&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26282&range=08-09

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

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

From liach at openjdk.org  Sun Jul 20 03:03:02 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 20 Jul 2025 03:03:02 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
Message-ID: <0ZamVkhtmpKYFUBqpxZp5gnPsgFl-62hXgRDYNHbaT0=.6edcc58b-343c-4446-b5e5-e4a17254d206@github.com>

On Sat, 19 Jul 2025 16:18:53 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   name the parameterized tests

Didn't know `@ParameterizedTest` could specify a name for failure reports - Another thing learnt today!

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3092716527

From swen at openjdk.org  Sun Jul 20 22:17:47 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 20 Jul 2025 22:17:47 GMT
Subject: RFR: 8359119: Change Charset to use StableValue [v2]
In-Reply-To: <l5D_p3SX_spsWDcXRAHC4qEBNNB9bkxY_C6Cfrn_SPY=.70b17a15-0390-4ced-b658-3954490660af@github.com>
References: <TQ1hWftS-obMd0ocVzaTgkCe7mI6be38FL5OsdZixRI=.82b1b28a-cb1f-4fcc-90cf-0d80bce57b63@github.com>
 <l5D_p3SX_spsWDcXRAHC4qEBNNB9bkxY_C6Cfrn_SPY=.70b17a15-0390-4ced-b658-3954490660af@github.com>
Message-ID: <1HAw1r5SQYTZXX2x4yX6se2gllfH4-o_awAHam6ryKY=.c1da7095-c3ac-4dd0-a9af-d7cc29442a03@github.com>

On Tue, 10 Jun 2025 15:15:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Fields and methods can better leverage the Stable Value API compared to using DCL and holder classes. There are also some fields that can be marked `@Stable`.
>> 
>> This PR passes tier1, tier2, and tier3 tests on multiple platforms.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert for loop
>  - Revert more
>  - Revert changes

After this proposal, the startup will load 9 more classes

* Java Code

public class Startup {
    public static void main(String[] args) throws Exception {
        Thread.sleep(1000);
    }
}



./build/macosx-aarch64-server-release/images/jdk/bin/java -verbose:class Startup


By comparing the output before and after this proposal, we can see that 9 more classes are loaded, as follows:

[info][class,load] java.nio.charset.Charset$2
[info][class,load] java.lang.StableValue
[info][class,load] java.util.Objects
[info][class,load] jdk.internal.lang.stable.StableSupplier
[info][class,load] jdk.internal.lang.stable.StableValueImpl
[info][class,load] java.nio.charset.Charset$3
[info][class,load] java.nio.charset.Charset$4
[info][class,load] java.nio.charset.Charset$5
[info][class,load] jdk.internal.ref.Cleaner

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

PR Comment: https://git.openjdk.org/jdk/pull/25727#issuecomment-3094824883

From bpb at openjdk.org  Tue Jul 22 16:42:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Jul 2025 16:42:58 GMT
Subject: RFR: 8361209: (bf) Use CharSequence::getChars for StringCharBuffer
 bulk get methods [v5]
In-Reply-To: <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
References: <Vs2XnQkMDskkhzaR_amQ9-4QQ84_qGE7O7aRrpdZAoQ=.599892f5-582f-423d-9747-6ca6d73b8a91@github.com>
 <Gf_7mljNgUOe2tvrTRfWJBgUmz46qVe9UtOxYSo2rC0=.b3586fda-3454-42ef-9d16-f70c2798a4cd@github.com>
Message-ID: <m9ftfoFo8FGmLRUYwtSN1HAI8fCTAs20lazXssnlKx4=.e90ecbb4-a4a1-4de4-b1da-269ebd04d9b7@github.com>

On Wed, 16 Jul 2025 23:23:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For `CharBuffer`s created from a `CharSequence`, use `CharSequence.getChars` to perform bulk gets instead of successively copying single characters.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361209: Fix assertion added in previous commit

The change in this request passed several hundred repetitions of the new test proposed in #26282.

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

PR Comment: https://git.openjdk.org/jdk/pull/26251#issuecomment-3103764941

From bpb at openjdk.org  Tue Jul 22 23:29:08 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Jul 2025 23:29:08 GMT
Subject: RFR: 8361495: (fc) Async close of streams connected to uninterruptible
 FileChannel doesn't throw AsynchronousCloseException in all cases
Message-ID: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>

Throw `AsynchronousCloseException` from `FileChannelImpl` methods if the channel is uninterruptible and was closed before the method (operation) could complete.

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

Commit messages:
 - 8361495: (fc) Async close of streams connected to uninterruptible FileChannel doesn't throw AsynchronousCloseException in all cases

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

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

From alanb at openjdk.org  Wed Jul 23 07:17:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 07:17:59 GMT
Subject: RFR: 8361495: (fc) Async close of streams connected to
 uninterruptible FileChannel doesn't throw AsynchronousCloseException in all
 cases
In-Reply-To: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
References: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
Message-ID: <MxvDhsyAMOtGdttQgnC-YnNjuAee1sS8EeQN3pqV0Qk=.ebefbe57-e30b-42a2-bcbd-52424907739d@github.com>

On Tue, 22 Jul 2025 23:21:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Throw `AsynchronousCloseException` from `FileChannelImpl` methods if the channel is uninterruptible and was closed before the method (operation) could complete.

The update to FileChannelImpl looks now. 

he change impacts the read methods of input streams obtained from Files.newInputStream and the write methods of output streams obtained from Files.newOutputStream. I'm wonder if we should create a new complete test for this long standing issue. Right now, the test only exercises the available method and I worry that it continues when it runs out of file desciptors.

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

PR Comment: https://git.openjdk.org/jdk/pull/26435#issuecomment-3106183869

From bpb at openjdk.org  Wed Jul 23 14:48:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Jul 2025 14:48:55 GMT
Subject: RFR: 8361495: (fc) Async close of streams connected to
 uninterruptible FileChannel doesn't throw AsynchronousCloseException in all
 cases
In-Reply-To: <MxvDhsyAMOtGdttQgnC-YnNjuAee1sS8EeQN3pqV0Qk=.ebefbe57-e30b-42a2-bcbd-52424907739d@github.com>
References: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
 <MxvDhsyAMOtGdttQgnC-YnNjuAee1sS8EeQN3pqV0Qk=.ebefbe57-e30b-42a2-bcbd-52424907739d@github.com>
Message-ID: <f1G5-epoJBVgWKGsjbpU5w834Vstb_E4ShYNVmsyeGA=.7afe4451-dea0-49b5-a7fa-2463ab15cb6e@github.com>

On Wed, 23 Jul 2025 07:15:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm wonder if we should create a new complete test for this long standing issue.

The test needs some work anyway so I will investigate.

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

PR Comment: https://git.openjdk.org/jdk/pull/26435#issuecomment-3108967051

From bpb at openjdk.org  Wed Jul 23 15:01:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Jul 2025 15:01:17 GMT
Subject: RFR: 8361495: (fc) Async close of streams connected to
 uninterruptible FileChannel doesn't throw AsynchronousCloseException in all
 cases [v2]
In-Reply-To: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
References: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
Message-ID: <JalhttqaOY6HiuCYOMCish7XlmstY1KAWazilOU3WCA=.11ab8a65-555f-4cce-bfc7-c77dd3e483bd@github.com>

> Throw `AsynchronousCloseException` from `FileChannelImpl` methods if the channel is uninterruptible and was closed before the method (operation) could complete.

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

  8361495: Clean up initial test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26435/files
  - new: https://git.openjdk.org/jdk/pull/26435/files/e6e647f3..8f708847

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

  Stats: 29 lines in 1 file changed: 8 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26435.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26435/head:pull/26435

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

From bpb at openjdk.org  Thu Jul 24 20:33:14 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Jul 2025 20:33:14 GMT
Subject: RFR: 8361495: (fc) Async close of streams connected to
 uninterruptible FileChannel doesn't throw AsynchronousCloseException in all
 cases [v3]
In-Reply-To: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
References: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
Message-ID: <G3blF5m9RjLSqiSrlsal_vOPN54sP9VAXqEFlzivcpM=.f5d10605-c47b-4b7d-b3bb-fb459d7f00a1@github.com>

> Throw `AsynchronousCloseException` from `FileChannelImpl` methods if the channel is uninterruptible and was closed before the method (operation) could complete.

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

  8361495: Add read and write tests and convert to JUnit 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26435/files
  - new: https://git.openjdk.org/jdk/pull/26435/files/8f708847..899f28cd

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

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

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

From bpb at openjdk.org  Thu Jul 24 20:35:54 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Jul 2025 20:35:54 GMT
Subject: RFR: 8361495: (fc) Async close of streams connected to
 uninterruptible FileChannel doesn't throw AsynchronousCloseException in all
 cases [v2]
In-Reply-To: <JalhttqaOY6HiuCYOMCish7XlmstY1KAWazilOU3WCA=.11ab8a65-555f-4cce-bfc7-c77dd3e483bd@github.com>
References: <4LSh6MSWFPMMg_ay5AQ1wKcWen1gQEqmZ8JQpsLpReU=.b6252979-43bb-4c8d-ab9c-105cd3000996@github.com>
 <JalhttqaOY6HiuCYOMCish7XlmstY1KAWazilOU3WCA=.11ab8a65-555f-4cce-bfc7-c77dd3e483bd@github.com>
Message-ID: <zDI4XCzmLmtyoiC_Cuwgx7iueswfLsUUg3B6QYIs2OI=.055c7f2b-67bb-4b78-836e-a370bc607b36@github.com>

On Wed, 23 Jul 2025 15:01:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Throw `AsynchronousCloseException` from `FileChannelImpl` methods if the channel is uninterruptible and was closed before the method (operation) could complete.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361495: Clean up initial test

The test as of commit 899f28c passed 100 repeats on Linux and Windows with the change to `FileChannelImpl`, but failed all 100 repeats on the same platforms without the implementation change.

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

PR Comment: https://git.openjdk.org/jdk/pull/26435#issuecomment-3114841375

From bpb at openjdk.org  Fri Jul 25 00:10:59 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Jul 2025 00:10:59 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
Message-ID: <cBbW65367A5Ea6wRn0oDCNFkY15Dp7fELIVeVGIjWIg=.38854db2-98c0-4101-8a94-7b6de9ded218@github.com>

On Sat, 19 Jul 2025 16:18:53 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   name the parameterized tests

The test looks fine to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26282#pullrequestreview-3053684265

From michaelm at openjdk.org  Fri Jul 25 12:15:05 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Jul 2025 12:15:05 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
Message-ID: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>

Hi,

This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
because that file was renamed, and webrev doesn't show the diffs side by side.
The effect of this change is to restore the method to pretty much what it was before, but taking account
of the changed categorisation of exceptions.

A test is not included since this was caught by an existing regression test.

Thanks,
Michael

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

Commit messages:
 - add test bugid
 - impl update

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

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

From djelinski at openjdk.org  Fri Jul 25 12:46:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 25 Jul 2025 12:46:53 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <iXowkpHLNw_IZg-GjAasRE7E0etYN_uMJDvJ1RqPyQI=.5f6a5541-2e48-4cab-bd89-3cd7cafa78ef@github.com>

On Fri, 25 Jul 2025 12:08:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26478#pullrequestreview-3055263287

From alanb at openjdk.org  Fri Jul 25 13:05:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 13:05:54 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <ZIU439kTDPLFd6VdQZfR7kPFhsfFHnJksKvgtsfUtlE=.85826fbb-7a24-4d42-bc88-046427e28079@github.com>

On Fri, 25 Jul 2025 12:08:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

test/jdk/java/nio/channels/SocketChannel/OpenLeak.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 6548464 8362581

I think you can drop this change to the test, it only accidentally uncovered this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26478#discussion_r2231034209

From michaelm at openjdk.org  Fri Jul 25 14:26:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Jul 2025 14:26:39 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX [v2]
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

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

  revert test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26478/files
  - new: https://git.openjdk.org/jdk/pull/26478/files/45cb3a46..c9a05bd6

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

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

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

From jpai at openjdk.org  Fri Jul 25 14:53:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Jul 2025 14:53:55 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX [v2]
In-Reply-To: <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
 <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
Message-ID: <Mep5Cl1hYAFcAOGsSTskcwO9Ir6oTn8pJLbVF3vYzTk=.63366235-5f2a-42e7-b3d3-d3eef1731abd@github.com>

On Fri, 25 Jul 2025 14:26:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
>> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
>> because that file was renamed, and webrev doesn't show the diffs side by side.
>> The effect of this change is to restore the method to pretty much what it was before, but taking account
>> of the changed categorisation of exceptions.
>> 
>> A test is not included since this was caught by an existing regression test.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test change

This looks good to me. I've verified that with this change, the timing for the test methods in `test/jdk/java/nio/channels/SocketChannel/OpenLeak.java` drops back to the same duration that was there before the changes that were done in https://bugs.openjdk.org/browse/JDK-8348986

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26478#pullrequestreview-3055757642

From alanb at openjdk.org  Fri Jul 25 15:56:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Jul 2025 15:56:03 GMT
Subject: RFR: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX [v2]
In-Reply-To: <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
 <Mr_xzU2Zk0wBiNY7NV-bCa4j66OhcKuLxLJnIixeOvs=.ae351bb7-1759-4188-a199-d9900eab7a64@github.com>
Message-ID: <QVenageCTzGFgjkWLclqZpq7-SfY-uMiQ_Lr6PQY8Tg=.c5664d37-5714-4fb3-9862-2acbf03ef629@github.com>

On Fri, 25 Jul 2025 14:26:39 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
>> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
>> because that file was renamed, and webrev doesn't show the diffs side by side.
>> The effect of this change is to restore the method to pretty much what it was before, but taking account
>> of the changed categorisation of exceptions.
>> 
>> A test is not included since this was caught by an existing regression test.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test change

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26478#pullrequestreview-3056015950

From rriggs at openjdk.org  Fri Jul 25 16:01:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Jul 2025 16:01:57 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
Message-ID: <iuaKL8DKutj8j7SfxYC_wA3h0uquw-qIFEW6wRjUV-0=.8ce38b9b-8758-458f-82d1-c0fde10111ad@github.com>

On Sat, 19 Jul 2025 16:18:53 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   name the parameterized tests

Looks good, a few comments.

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 43:

> 41: 
> 42: /*
> 43:  * @test

The @bug should be copied from the original and the bugid that prompted the additions should be added.

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 47:

> 45:  * @library /test/lib
> 46:  * @build jdk.test.lib.RandomFactory
> 47:  * @summary tests the CharBuffer implementations behaving as CharSequence in various states (postion, limit, offset)

typo: "postion" -> "position"

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 113:

> 111:         String stringBuf = new String(buf);
> 112: 
> 113:         for (int i = 0; i < 29; i += 7) {

Some description of why 29 and 7 would be useful.
Ditto, 1273 above, big but not too big?

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

PR Review: https://git.openjdk.org/jdk/pull/26282#pullrequestreview-3055904668
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2231421176
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2231417687
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2231454388

From duke at openjdk.org  Fri Jul 25 16:20:55 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 25 Jul 2025 16:20:55 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <iuaKL8DKutj8j7SfxYC_wA3h0uquw-qIFEW6wRjUV-0=.8ce38b9b-8758-458f-82d1-c0fde10111ad@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
 <iuaKL8DKutj8j7SfxYC_wA3h0uquw-qIFEW6wRjUV-0=.8ce38b9b-8758-458f-82d1-c0fde10111ad@github.com>
Message-ID: <xH86cJsTxjDKasLjY_06l4xRfHFVEEE6KjMaNN2el5g=.6508244d-ad53-4ed9-9eca-81474c732626@github.com>

On Fri, 25 Jul 2025 15:26:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   name the parameterized tests
>
> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 43:
> 
>> 41: 
>> 42: /*
>> 43:  * @test
> 
> The @bug should be copied from the original and the bugid that prompted the additions should be added.

should I include this issue's bug (8361715), or just the actual defect which drove the desire to add some tests (8361299 - which I will copy forward from GetChars)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2231544127

From rriggs at openjdk.org  Fri Jul 25 17:49:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Jul 2025 17:49:55 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <xH86cJsTxjDKasLjY_06l4xRfHFVEEE6KjMaNN2el5g=.6508244d-ad53-4ed9-9eca-81474c732626@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
 <iuaKL8DKutj8j7SfxYC_wA3h0uquw-qIFEW6wRjUV-0=.8ce38b9b-8758-458f-82d1-c0fde10111ad@github.com>
 <xH86cJsTxjDKasLjY_06l4xRfHFVEEE6KjMaNN2el5g=.6508244d-ad53-4ed9-9eca-81474c732626@github.com>
Message-ID: <7HTMHEcUPkuzOdqMksiTAJyvvXLAooDXy9tDT-TUYYo=.63b61a23-82ec-4d92-bba9-fe997c4ca5fd@github.com>

On Fri, 25 Jul 2025 16:18:31 GMT, Brett Okken <duke at openjdk.org> wrote:

>> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 43:
>> 
>>> 41: 
>>> 42: /*
>>> 43:  * @test
>> 
>> The @bug should be copied from the original and the bugid that prompted the additions should be added.
>
> should I include this issue's bug (8361715), or just the actual defect which drove the desire to add some tests (8361299 - which I will copy forward from GetChars)?

8361299 and 8343110 the issues containing the bug/enhancement being tested.
8343110 is the enhancement that added CharSequence.getChars and 8361299 an issue fixed after the original.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2231701584

From rriggs at openjdk.org  Fri Jul 25 17:53:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Jul 2025 17:53:55 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v10]
In-Reply-To: <7HTMHEcUPkuzOdqMksiTAJyvvXLAooDXy9tDT-TUYYo=.63b61a23-82ec-4d92-bba9-fe997c4ca5fd@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <iwwKKPOeWy-EzbDI8Bj9LNJQ4_sEE-E716Xuh6vMf4o=.aa87517b-ddc0-4e6a-95a9-594247363bda@github.com>
 <iuaKL8DKutj8j7SfxYC_wA3h0uquw-qIFEW6wRjUV-0=.8ce38b9b-8758-458f-82d1-c0fde10111ad@github.com>
 <xH86cJsTxjDKasLjY_06l4xRfHFVEEE6KjMaNN2el5g=.6508244d-ad53-4ed9-9eca-81474c732626@github.com>
 <7HTMHEcUPkuzOdqMksiTAJyvvXLAooDXy9tDT-TUYYo=.63b61a23-82ec-4d92-bba9-fe997c4ca5fd@github.com>
Message-ID: <GwD_kBg8lyH139XUdu7RrEryqSy5Cn-XgvZ5WqodiwA=.724bdd66-6897-4f6c-a169-3139bdbd3c6c@github.com>

On Fri, 25 Jul 2025 17:47:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> should I include this issue's bug (8361715), or just the actual defect which drove the desire to add some tests (8361299 - which I will copy forward from GetChars)?
>
> 8361299 and 8343110 the issues containing the bug/enhancement being tested.
> 8343110 is the enhancement that added CharSequence.getChars and 8361299 an issue fixed after the original.

Jtreg has a useful feature to run tests by bugid:
```-bug:<bugid>    Run only those tests which apply to the given bugid.```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2231707310

From duke at openjdk.org  Fri Jul 25 18:47:21 2025
From: duke at openjdk.org (Brett Okken)
Date: Fri, 25 Jul 2025 18:47:21 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

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

  code review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26282/files
  - new: https://git.openjdk.org/jdk/pull/26282/files/65f9470a..356a9b0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26282&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26282&range=09-10

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

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

From rriggs at openjdk.org  Fri Jul 25 19:30:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Jul 2025 19:30:55 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <4yfnZ-EESDuuRb4gtQwDoDFsiV4CD0XDEFGm2K8rod4=.ac4de191-ee4b-4dda-b30f-a2714b029fba@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

Looks good, thanks for the comments.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26282#pullrequestreview-3056585810

From bpb at openjdk.org  Fri Jul 25 20:53:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Jul 2025 20:53:56 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <jx9apMrag5Rngfg7NfrRctah1qYdFSemR3QfSi72gX8=.f7b27bfb-4533-4791-ac9e-67bed6c8f11e@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

Looks good.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26282#pullrequestreview-3056758816

From duke at openjdk.org  Sat Jul 26 07:51:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 26 Jul 2025 07:51:01 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <6NSMDqRy9CiytH25pQDGergFr8o7ofTDKe0151cIi3M=.a92d424e-5ee6-4945-9a7d-3a56f8545c7e@github.com>
Message-ID: <tYdVgQBeFsiI1UHHItThr7FhEluU5_1RclwEIYI2Ing=.8c7f471e-f0cf-4e4e-9709-6a8a9cd2147d@github.com>

On Thu, 19 Jun 2025 08:08:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> src/java.base/macosx/classes/sun/nio/ch/KQueue.java line 63:
> 
>> 61: 
>> 62:     // filters
>> 63:     static final int EVFILT_READ  = kqueue_h.EVFILT_READ();
> 
> Could we remove these constants and use `kqueue_h` constants directly?

No, because?those are?`private`, accessible only?through the?`public static`?getters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2232777224

From duke at openjdk.org  Sat Jul 26 07:51:01 2025
From: duke at openjdk.org (ExE Boss)
Date: Sat, 26 Jul 2025 07:51:01 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <goNlSp75pxPfwgD4zUK3kB9_3TKSm_O0z0G8I4zviGw=.fa378954-2a5f-46e0-93ee-ec91adb8082c@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

src/java.base/macosx/classes/sun/nio/ch/KQueuePoller.java line 44:

> 42: 
> 43:     KQueuePoller(boolean subPoller, boolean read) throws IOException {
> 44:         this.kqfd = kqueue_h.kqueue();

Note?that the?old?implementation of?`KQueue.create()` had?a?check for?negative `kqfd`:
https://github.com/openjdk/jdk/blob/d288ca28be7bfba3abe9f54cefbe53e73c25707e/src/java.base/macosx/native/libnio/ch/KQueue.c#L63-L71

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2232782518

From michaelm at openjdk.org  Sat Jul 26 22:25:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Sat, 26 Jul 2025 22:25:01 GMT
Subject: Integrated: 8362581: Timeouts in
 java/nio/channels/SocketChannel/OpenLeak.java on UNIX
In-Reply-To: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
References: <JNolgSmvHrEj3_svGhgCSIssrkA_7rvfQwN4_yGAYi0=.875059ed-50f0-44b9-9670-7143c5908f95@github.com>
Message-ID: <ho1IiJkVLCDGGNcrL9gcH8ZZMvo24leW4uUO2q7sChI=.2315d284-f2b7-44aa-ae79-5e89092205db@github.com>

On Fri, 25 Jul 2025 12:08:38 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a fix for 8362581 caused by the implementation for https://bugs.openjdk.org/browse/JDK-8348986
> An incorrect check was added to the method Exceptions.ioException() which wasn't noticed partly
> because that file was renamed, and webrev doesn't show the diffs side by side.
> The effect of this change is to restore the method to pretty much what it was before, but taking account
> of the changed categorisation of exceptions.
> 
> A test is not included since this was caught by an existing regression test.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: de59da27
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de59da27a60bd0afaf8deaf6d4a3d743a4f59db8
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8362581: Timeouts in java/nio/channels/SocketChannel/OpenLeak.java on UNIX

Reviewed-by: jpai, alanb, djelinski

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

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

From vyazici at openjdk.org  Mon Jul 28 09:47:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:04 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
Message-ID: <abFTzVczJjF1TbG3euS56RNLSkDGuU6vk1FzL4_wp74=.7b208c21-c259-4b7c-97c3-1be4e41cdcd4@github.com>

On Mon, 21 Jul 2025 13:01:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> I strongly suggest against using CCE as the standard exception. The only place that relies on CCE is `Files`; IAE is more suitable for everywhere else. I recommend adding the special CCE handling in `Files` alone so we can remove the redundant try-catch everywhere else.

@liach, thanks so much for the prompt feedback!

> I strongly suggest against using CCE as the standard exception.

Would you mind elaborating on the rationale behind this preference, please?

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3096905451

From alanb at openjdk.org  Mon Jul 28 09:47:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 09:47:05 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <PrrQBBv9ZvnJlAxL-e_E8J2LbMz6RVMO9XE2VYQogzI=.ad7b63f3-520f-49cd-85bc-56e35d44f733@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

newStringNoRepl has confused several maintainers as it's not immediately obvious that it means "no replace", or more specifically CodingErrorAction.REPORT behavior. So it's good to see this getting attention.

Anyone working on String expects CodingErrorAction.REPLACE behavior so having String methods use methods that don't throw would feel right.

There are "far away" APIs, Files.readXXX was mentioned, that require CodingErrorAction.REPORT behavior methods so having JLA methods throw CharacterCodingException is helpful. 

There are other far away APIs such as UUID and ZipCoder that specify a Charset and know that no exception will be throw. They want CodingErrorAction.REPORT behavior except that it's a bug if CharacterCodingException is thrown. These cases catch CCE and throw AssertionError, which is okay, and hopefully we have enough tests in all these area to ensure that it doesn't happen.

Anyway, from a first read of the changes then I think we need to make sure that the method descriptions are accurate. There are several places where "IAE" is mentioned but the methods are changed to throw CCE.  IAE is awkward in this area because throwing it, instead of CCE, makes it difficult to know if the handling is correct. There is constant code churn in this area and too easy to introduce a regression and "unexpected exception" if IAE is used to in place of a CharacterCodingException. 

Another high level comment from a first read is that it feels like there are two forms needed. One form is REPLACE action and doesn't throw. The other is REPORT action and throws CharacterCodingException. That is what we have already, it's just the naming is awkward.  So it may be that it's more about finding good names so that it's clear from all the use sites.

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3103589181

From liach at openjdk.org  Mon Jul 28 09:47:05 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 09:47:05 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <abFTzVczJjF1TbG3euS56RNLSkDGuU6vk1FzL4_wp74=.7b208c21-c259-4b7c-97c3-1be4e41cdcd4@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>
 <abFTzVczJjF1TbG3euS56RNLSkDGuU6vk1FzL4_wp74=.7b208c21-c259-4b7c-97c3-1be4e41cdcd4@github.com>
Message-ID: <5A1iktExyQTToHYQrz_0fGc6Uz-psGD4aGlUFcLtryM=.227fc254-37a6-4a48-b550-5c35ec349848@github.com>

On Mon, 21 Jul 2025 14:00:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Would you mind elaborating on the rationale behind this preference, please?

If you look at the history of `newStringNoRepl`, you will find it's originally added for JDK-8201276 in ca487166f4d18c162e8d8e4b2660d5d0381c5438. Since then, `newStringNoRepl` has been used by various other sites mostly as a utility. None of those further usages ever used the `CharacterCodingException`. In fact, in `String`, the actual implementation throws an IAE that is later wrapped in a CCE. I don't think we should punish all other users of this API just because `Files.readString` requires this CCE; the CCE wrapping can be moved to Files.readString.

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3097079813

From vyazici at openjdk.org  Mon Jul 28 09:47:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:03 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
Message-ID: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>

`NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

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

Commit messages:
 - Replace `requireNonNull` with implicit null checks
 - Merge remote-tracking branch 'upstream/master' into jlaNoRepl
 - Improve docs of touched methods and add NPE checks
 - Convert IAE-throwing methods into CCE-throwing ones
 - Rename `JavaLangAccess::*NoRepl` methods

Changes: https://git.openjdk.org/jdk/pull/26413/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356439
  Stats: 193 lines in 10 files changed: 82 ins; 34 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/26413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26413/head:pull/26413

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

From liach at openjdk.org  Mon Jul 28 09:47:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 28 Jul 2025 09:47:04 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <Y55-lbbFBZEzGNqlIn4LTWLsW22B_KhakQVJD0eEaLI=.798762d3-b450-4215-afc7-13882758cc96@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

I strongly suggest against using CCE as the standard exception. The only place that relies on CCE is `Files`; IAE is more suitable for everywhere else. I recommend adding the special CCE handling in `Files` alone so we can remove the redundant try-catch everywhere else.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 328:

> 326:      * @throws CharacterCodingException for malformed or unmappable bytes
> 327:      */
> 328:     String uncheckedNewString(byte[] bytes, Charset cs) throws CharacterCodingException;

The docs should mention these two details:
1. This method does not replace upon malformed data but fails
2. This method does not copy the byte array for validation (can add to the warning)

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

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26413#pullrequestreview-3038008799
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2219148757

From vyazici at openjdk.org  Mon Jul 28 09:47:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:05 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <PrrQBBv9ZvnJlAxL-e_E8J2LbMz6RVMO9XE2VYQogzI=.ad7b63f3-520f-49cd-85bc-56e35d44f733@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <PrrQBBv9ZvnJlAxL-e_E8J2LbMz6RVMO9XE2VYQogzI=.ad7b63f3-520f-49cd-85bc-56e35d44f733@github.com>
Message-ID: <2ljiZ6ehU1zSgacWy0c58GV-AbU4ATDh40BWTufiWh4=.8f8ca1d6-89df-4b22-a261-4b493f4266f4@github.com>

On Tue, 22 Jul 2025 16:03:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are several places where "IAE" is mentioned but the methods are changed to throw CCE.

@AlanBateman, thanks for the tip. Pushed 10cb72cf17b, which improves Javadoc in such places. While doing so, it also

* Ensures that `String` Javadoc matches the one shared in `JavaLangAccess`
* Adds some missing(?) `requireNonNull` checks, and documents them as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3112627244

From vyazici at openjdk.org  Mon Jul 28 09:47:06 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 28 Jul 2025 09:47:06 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

src/java.base/share/classes/java/lang/String.java line 1262:

> 1260:         MalformedInputException mie = new MalformedInputException(nb);
> 1261:         String msg = "malformed input off : " + off + ", length : " + nb;
> 1262:         mie.initCause(new IllegalArgumentException(msg));

Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing _extra diagnostics information_ and wrapping a `CCE` as a cause. After switching methods to throw `CCE`, which doesn't have a ctor accepting a `String` message, to retain this extra diagnostics information, I've added swapped their causal chain placement, and wrapped `IAE` with a `CCE` this time.

This played well with `CCE`-throwing methods, yet there are other `public` methods which did not have `throws CCE` in their footprint. For backward compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` wrapping the `CCE`, which matched the old behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2219032735

From duke at openjdk.org  Mon Jul 28 11:52:04 2025
From: duke at openjdk.org (duke)
Date: Mon, 28 Jul 2025 11:52:04 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <uope4_23_gNMXRlmQCS7ayNgDXton5giGBIUvLnQ93s=.599d4ca7-2630-4aef-a19c-4e1c7df18b03@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

@bokken 
Your change (at version 356a9b0fe5d1656018eb51432747ab9a58ea060f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3126863666

From duke at openjdk.org  Mon Jul 28 13:08:03 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 28 Jul 2025 13:08:03 GMT
Subject: Integrated: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit
In-Reply-To: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
Message-ID: <A6fUnsQlXbOuxprtfGRKrzXXInsK1vZzwZhHh7_ICB8=.938ca917-20c6-470d-b1fc-49fce881b6b7@github.com>

On Sun, 13 Jul 2025 23:56:28 GMT, Brett Okken <duke at openjdk.org> wrote:

> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)

This pull request has now been integrated.

Changeset: 08b0b346
Author:    Brett Okken <brett.okken at oracle.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08b0b34623e1e67fbc6078675a72ce9b3b126996
Stats:     552 lines in 2 files changed: 332 ins; 220 del; 0 mod

8361715: (bf) Improve java/nio/Buffer/GetChars.java and migrate to JUnit

Reviewed-by: bpb, rriggs

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

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

From alanb at openjdk.org  Mon Jul 28 13:36:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 13:36:05 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <b5rC8CoKw1Xw6ThcqvEobkg2lrQfVxIm8eYPY5PGT4I=.74b6def4-11c0-4400-9958-b9670e7fd855@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 91:

> 89:         CharBuffer rndSlicedRange = randomizeRange(rndRange.slice());
> 90:         cases.add(Arguments.of(rndSlicedRange, buf, rndRange.position() + rndSlicedRange.position(), rndRange.position() + rndSlicedRange.limit(), type + " sliced at " + rndRange.position() + " with position " + rndSlicedRange.position() + " and limit " + rndSlicedRange.limit()));
> 91:     }

This line will mess up future side-by-side views, can you re-format it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236498964

From duke at openjdk.org  Mon Jul 28 13:41:02 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 28 Jul 2025 13:41:02 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <b5rC8CoKw1Xw6ThcqvEobkg2lrQfVxIm8eYPY5PGT4I=.74b6def4-11c0-4400-9958-b9670e7fd855@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
 <b5rC8CoKw1Xw6ThcqvEobkg2lrQfVxIm8eYPY5PGT4I=.74b6def4-11c0-4400-9958-b9670e7fd855@github.com>
Message-ID: <pWOtDLuvp6fk6ng1p0EUaujtpOnbj3CItDyYvijTZA4=.dedf09c2-a908-4b58-a73b-4fb95f029167@github.com>

On Mon, 28 Jul 2025 13:33:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code review comments
>
> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 91:
> 
>> 89:         CharBuffer rndSlicedRange = randomizeRange(rndRange.slice());
>> 90:         cases.add(Arguments.of(rndSlicedRange, buf, rndRange.position() + rndSlicedRange.position(), rndRange.position() + rndSlicedRange.limit(), type + " sliced at " + rndRange.position() + " with position " + rndSlicedRange.position() + " and limit " + rndSlicedRange.limit()));
>> 91:     }
> 
> This line will mess up future side-by-side views, can you re-format it?

@AlanBateman do I just create another PR linked to the same jira for this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236520173

From alanb at openjdk.org  Mon Jul 28 14:04:58 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 14:04:58 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <fL1L_wj7jzNQmrtjhXi5p56IQDQvOQSV8YNDIL0qsss=.f6a6a7f1-cdc5-4f4f-8edd-e5790ecb288f@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 48:

> 46:  * @library /test/lib
> 47:  * @build jdk.test.lib.RandomFactory
> 48:  * @summary tests the CharBuffer implementations behaving as CharSequence in various states (position, limit, offset)

This would be clearer if replaced with "Tests CharBuffer implementations of CharSequence".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236623942

From alanb at openjdk.org  Mon Jul 28 14:11:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 14:11:07 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <hRch2gVqwOhzpU635cfcnItOcENTH0DGF-nkkPcN3LM=.6b54a59b-00e5-4490-8295-b5f99922591a@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 93:

> 91:     }
> 92: 
> 93:     static List<Arguments> charBufferArguments() {

This needs a clear comment to say what it returns, or many we should split it so we have more than one method source.

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 227:

> 225:     @ParameterizedTest(name="{4}")
> 226:     @MethodSource("charBufferArguments")
> 227:     void testGetCharsNegativeSourceBeg(CharSequence actual, char[] expected, int start, int stop, String description) {

The parameter that is being tested here is "srcBegin" so maybe using that naming instead of switching to "SourceBeg" (same comment for several other methods).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236634766
PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236645458

From alanb at openjdk.org  Mon Jul 28 14:20:06 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Jul 2025 14:20:06 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <xvsvtOPXjiOUXpnHcvj3BgRAyFQT6IqF_QcZIoanizA=.768cea80-285b-4010-8b57-b0f68ccce30a@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 100:

> 98:         populateAndAddCases("LEHeapByteBuffer", ByteBuffer.allocate(SIZE*2).order(ByteOrder.LITTLE_ENDIAN).asCharBuffer(), args);
> 99:         populateAndAddCases("BEDirectByteBuffer", ByteBuffer.allocateDirect(SIZE*2).order(ByteOrder.BIG_ENDIAN).asCharBuffer(), args);
> 100:         populateAndAddCases("LEDirectByteBuffer", ByteBuffer.allocateDirect(SIZE*2).order(ByteOrder.LITTLE_ENDIAN).asCharBuffer(), args);

Having BE or LE at the start of the type name is a bit confusing, would be clear (and more like charset names) to append rather than prepend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236683766

From duke at openjdk.org  Mon Jul 28 14:52:05 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 28 Jul 2025 14:52:05 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <hRch2gVqwOhzpU635cfcnItOcENTH0DGF-nkkPcN3LM=.6b54a59b-00e5-4490-8295-b5f99922591a@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
 <hRch2gVqwOhzpU635cfcnItOcENTH0DGF-nkkPcN3LM=.6b54a59b-00e5-4490-8295-b5f99922591a@github.com>
Message-ID: <x_vyRr0pwiWPmWoeAngjVIHtjt5ex4CiXODg0Ds7Ezo=.6cfc18b6-eea6-4176-a98d-1c568e2d4e11@github.com>

On Mon, 28 Jul 2025 14:05:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code review comments
>
> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 93:
> 
>> 91:     }
>> 92: 
>> 93:     static List<Arguments> charBufferArguments() {
> 
> This needs a clear comment to say what it returns, or maybe we should split it so we have more than one method source.

Would something like this work:


    /**
     * Returns a {@code List} of {@link Arguments}, with each entry representing a test case scenario.
     * <ul>
     * <li>CharBuffer - the instance to be tested</li>
     * <li>char[] - the data expected to be backing the current state of the CharBuffer</li>
     * <li>int start - index (inclusive) into char[] where the CharBuffer should be positioned</li>
     * <li>int stop - index (exclusive) into char[] where the CharBuffer should be limited</li>
     * <li>String - description of the test scenario</li>
     * </ul>
     */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26282#discussion_r2236807417

From duke at openjdk.org  Mon Jul 28 16:46:05 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 28 Jul 2025 16:46:05 GMT
Subject: RFR: 8361715: (bf) Improve java/nio/Buffer/GetChars.java and
 migrate to JUnit [v11]
In-Reply-To: <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
References: <3v-QgWE-UR8EcgdcfwixOd_Oksoz-81camq5RsWPiKw=.4aaddfe2-bfc4-41a9-b534-eba04826882c@github.com>
 <DPVE8TbVpLrz4xJhvjLoSl_kpSThkZK8GwrJZ0WumwA=.c5d3100e-033e-458d-962d-d7aff8c38ae5@github.com>
Message-ID: <qlbFZKmLkC0__6r-nJZ71jJrWMkpxv87vBPH0m7Nhf8=.544a796d-6c73-4fde-8a4e-10d931870afc@github.com>

On Fri, 25 Jul 2025 18:47:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> junit for CharSequence behavior of CharBuffer covering different CharBuffer implementations in various states (offset, position, limit)
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code review comments

Code review comments which came in after integration/merge will be addressed as part of https://bugs.openjdk.org/browse/JDK-8364213 and PR https://github.com/openjdk/jdk/pull/26512

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

PR Comment: https://git.openjdk.org/jdk/pull/26282#issuecomment-3128100939

From duke at openjdk.org  Mon Jul 28 16:49:06 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 28 Jul 2025 16:49:06 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test comments
Message-ID: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>

Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.

Update/clarify test summary tag
Document the values generated for arguments
Move the endian-ness qualifier in the test descriptor string to not be first
Change test method names to more closely match arg names of method under test

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

Commit messages:
 - 8364213: (bf) Improve java/nio/Buffer/GetChars.java test comment

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

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

From duke at openjdk.org  Mon Jul 28 17:30:53 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 28 Jul 2025 17:30:53 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments
In-Reply-To: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
Message-ID: <2f_EXV8IRAtgcGztQdMW9BwOMYQXvO6XEJvt1BDa9E8=.29ba4506-92d4-47af-8a93-941e84825e93@github.com>

On Mon, 28 Jul 2025 16:43:05 GMT, Brett Okken <duke at openjdk.org> wrote:

> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
> 
> Update/clarify test summary tag
> Document the values generated for arguments
> Move the endian-ness qualifier in the test descriptor string to not be first
> Change test method names to more closely match arg names of method under test

@AlanBateman - this is addressing your comments in prior review

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

PR Comment: https://git.openjdk.org/jdk/pull/26512#issuecomment-3128264280

From rriggs at openjdk.org  Tue Jul 29 13:27:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 13:27:56 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <WObG1v-uiiW5td-qzSA06iRjh3U8fzfnKqX4DZf3gLE=.f63ef6b7-0e32-4345-8bec-24e7925b2b20@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

If CCE should have a constructor with a message, it can be added if you have a clear idea how it would be used.

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

PR Comment: https://git.openjdk.org/jdk/pull/26413#issuecomment-3132536387

From rriggs at openjdk.org  Tue Jul 29 14:26:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 14:26:56 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
Message-ID: <13urR68f8U8oqjrcaX1BtKI-EtD41ySuYt-oz333PdA=.c97d8293-2fbe-415d-983d-92b7e1c9d175@github.com>

On Mon, 21 Jul 2025 12:10:51 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)

src/java.base/share/classes/java/lang/String.java line 571:

> 569:     }
> 570: 
> 571:     private static String utf8ThrowingIae(byte[] bytes, int offset, int length) {

Iae should be all-caps. `IAE`

src/java.base/share/classes/java/lang/String.java line 579:

> 577:     }
> 578: 
> 579:     private static IllegalArgumentException cce2iae(CharacterCodingException cce) {

More readable would be "cceToIAE"
But this whole construct is suspect because of the contortions needed.

src/java.base/share/classes/java/lang/String.java line 1289:

> 1287:     }
> 1288: 
> 1289:     private static void throwMalformed(byte[] val) throws MalformedInputException {

It is unnecessary to add add @throws of RuntimeExceptions, conventionally they are omitted as clutter and any RuntimeException can be thrown at any time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2237974608
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2239826290
PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2239865577

From rriggs at openjdk.org  Tue Jul 29 14:26:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Jul 2025 14:26:58 GMT
Subject: RFR: 8356439: Rename JavaLangAccess::*NoRepl methods
In-Reply-To: <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>
References: <tH1CVPbhMAFgJ9nO5En6PwEKLey-flcbvZoOQ--JjwY=.6381a545-0661-41f6-afad-4c8f2b8574df@github.com>
 <UA0pGbsuzu3uVXQiMX6bXjQOdbpmnAhVOyR1tuk5mEo=.327cbc19-fd65-40af-89a0-fd19c65d4672@github.com>
Message-ID: <vpm4fE0UvlmqWd-E9O2vT_Me8_I6q0DRwGvFnEBO76E=.5a14fcac-a1c4-42be-8f83-a361ddd2e92f@github.com>

On Mon, 21 Jul 2025 12:19:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `NoRepl`-suffixed `String` methods denote methods that do not replace invalid characters, but throw `CharacterCodingException` on encounter. This behavior cannot easily be derived from the method footprints, has been a source of confusion for maintainers, and is not uniformly adopted, e.g., `newStringUTF8NoRepl()` and `getBytesUTF8NoRepl()` does *not* throw `CCE`. This PR removes `NoRepl` suffix from method names and consistently uses `throws CCE` in method footprints. (b4845109e18 passes `tier1,2`.)
>
> src/java.base/share/classes/java/lang/String.java line 1262:
> 
>> 1260:         MalformedInputException mie = new MalformedInputException(nb);
>> 1261:         String msg = "malformed input off : " + off + ", length : " + nb;
>> 1262:         mie.initCause(new IllegalArgumentException(msg));
> 
> Earlier `throw(Malformed|Unmappable)` methods were throwing `IAE` containing _extra diagnostics information_ and wrapping a `CCE` as a cause. After switching methods to throw `CCE`, which doesn't have a ctor accepting a `String` message, to retain this extra diagnostics information, I've added swapped their causal chain placement, and wrapped `IAE` with a `CCE` this time.
> 
> This played well with `CCE`-throwing methods, yet there are other `public` methods which did not have `throws CCE` in their footprint. For backward compatibility, in those spots, I've used `cce2iae` to obtain, again, a `IAE` wrapping the `CCE`, which matched the old behavior.

Introducing CCE (an IOException) into more places in string handling is going in the wrong direction.
As declared exceptions, they have to be caught and handled or re-thrown. That makes the source more complex and harder to maintain, as seen in the cce2iae mechanism.
The prior use of IAE encapsulating a CCE as needed is simpler and more consistent with other Runtime exception handling in most of the String class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26413#discussion_r2240031460

From alanb at openjdk.org  Tue Jul 29 15:51:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Jul 2025 15:51:55 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments
In-Reply-To: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
Message-ID: <PlnJA_cYa5xHV6y6dPbFk01QRMDVjITgukGmtUun4Rc=.9679dbb0-c7ef-417b-ae1c-c1e4be52007e@github.com>

On Mon, 28 Jul 2025 16:43:05 GMT, Brett Okken <duke at openjdk.org> wrote:

> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
> 
> Update/clarify test summary tag
> Document the values generated for arguments
> Move the endian-ness qualifier in the test descriptor string to not be first
> Change test method names to more closely match arg names of method under test

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 104:

> 102:      * <li>String - description of the test scenario</li>
> 103:      * </ul>
> 104:      */

That helps a bit but I think we need to break up charBufferArguments into simpler/maintainable methods that have clear comments to document the test cases that they generate. Right now it's just way too hard to see what is tested and not tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2240275588

From duke at openjdk.org  Wed Jul 30 15:06:38 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 30 Jul 2025 15:06:38 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v2]
In-Reply-To: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
Message-ID: <8pyjusvuWTD8M-mn2xDxWDA5w7gviyHutevoXupOUCA=.bdb26d8f-2b42-4518-a532-114ba4bd0f65@github.com>

> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
> 
> Update/clarify test summary tag
> Document the values generated for arguments
> Move the endian-ness qualifier in the test descriptor string to not be first
> Change test method names to more closely match arg names of method under test

Brett Okken has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - better documentation for "random" test cases
   
   fix for random range generation (JDK-8364345)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26512/files
  - new: https://git.openjdk.org/jdk/pull/26512/files/42334abf..36b6bae7

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

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

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

From duke at openjdk.org  Wed Jul 30 15:06:39 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 30 Jul 2025 15:06:39 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v2]
In-Reply-To: <PlnJA_cYa5xHV6y6dPbFk01QRMDVjITgukGmtUun4Rc=.9679dbb0-c7ef-417b-ae1c-c1e4be52007e@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
 <PlnJA_cYa5xHV6y6dPbFk01QRMDVjITgukGmtUun4Rc=.9679dbb0-c7ef-417b-ae1c-c1e4be52007e@github.com>
Message-ID: <OrDS6RPPKwhqwD0Nv-edruFCSy4-ZQ1Yt9LF1z_1a5k=.6a65efb1-8bdf-44b5-a508-2416b33f2c3c@github.com>

On Tue, 29 Jul 2025 15:49:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - better documentation for "random" test cases
>>    
>>    fix for random range generation (JDK-8364345)
>
> test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 104:
> 
>> 102:      * <li>String - description of the test scenario</li>
>> 103:      * </ul>
>> 104:      */
> 
> That helps a bit but I think we need to break up charBufferArguments into simpler/maintainable methods that have clear comments to document the test cases that they generate. Right now it's just way too hard to see what is tested and not tested.

I have started by adding more documentation to the "random" tests.
I agree this makes it much easier to reason about what scenarios are covered.
It is actually making me wonder if the "static" tests are even worth keeping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2243010510

From rriggs at openjdk.org  Wed Jul 30 15:53:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Jul 2025 15:53:58 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v2]
In-Reply-To: <8pyjusvuWTD8M-mn2xDxWDA5w7gviyHutevoXupOUCA=.bdb26d8f-2b42-4518-a532-114ba4bd0f65@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
 <8pyjusvuWTD8M-mn2xDxWDA5w7gviyHutevoXupOUCA=.bdb26d8f-2b42-4518-a532-114ba4bd0f65@github.com>
Message-ID: <uPipX3RrGqSu9OvHnxmWG5IzSx3-BBmltYcEzWRyFqA=.8d8a2acf-be8e-4986-9b95-af665e0b1bdc@github.com>

On Wed, 30 Jul 2025 15:06:38 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
>> 
>> Update/clarify test summary tag
>> Document the values generated for arguments
>> Move the endian-ness qualifier in the test descriptor string to not be first
>> Change test method names to more closely match arg names of method under test
>
> Brett Okken has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - better documentation for "random" test cases
>    
>    fix for random range generation (JDK-8364345)

test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java line 77:

> 75: 
> 76:     /**
> 77:      * Generates random content to use for populating <i>cb</i> then calling through to {@code addCases(String, char[], CharBuffer, List)}

Try to keep the line lengths under 100 chars (80 is better).
It makes it possible to do size-by-size reviews that some reviewers prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26512#discussion_r2243145495

From duke at openjdk.org  Wed Jul 30 17:54:11 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 30 Jul 2025 17:54:11 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v3]
In-Reply-To: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
Message-ID: <f_hQhJt8USVqhxFBoaNbfvjftJC9LtRUnS0IOZHUoCE=.aac7e580-18c5-4d77-9d86-487f3a0e9c78@github.com>

> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
> 
> Update/clarify test summary tag
> Document the values generated for arguments
> Move the endian-ness qualifier in the test descriptor string to not be first
> Change test method names to more closely match arg names of method under test

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

  wrap some longer lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26512/files
  - new: https://git.openjdk.org/jdk/pull/26512/files/36b6bae7..562eba7a

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

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

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

From duke at openjdk.org  Wed Jul 30 18:03:10 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 30 Jul 2025 18:03:10 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v4]
In-Reply-To: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
Message-ID: <XYJC_B6c8jl3A9NoP8m2Brz9r4p6hE4Y4pfsHse6muQ=.6e29fbbf-2843-4d99-94e4-7a3e5d515cc1@github.com>

> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
> 
> Update/clarify test summary tag
> Document the values generated for arguments
> Move the endian-ness qualifier in the test descriptor string to not be first
> Change test method names to more closely match arg names of method under test

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

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26512/files
  - new: https://git.openjdk.org/jdk/pull/26512/files/562eba7a..0263f51b

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

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

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

From mcimadamore at openjdk.org  Thu Jul 31 09:53:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Jul 2025 09:53:58 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
Message-ID: <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>

On Fri, 30 May 2025 12:00:28 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
> 
> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
> 
> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 51:

> 49:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
> 50:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
> 51:     public static final ValueLayout.OfLong C_LONG = (ValueLayout.OfLong) Linker.nativeLinker().canonicalLayouts().get("long");

This seems problematic. On Windows, the C type `long` has a `JAVA_INT` layout, because it only uses 32 bits. The reason jextract re-generates all these constants is that they can, in general, vary by platform, so my general feeling is that we can't just have a shared set of layout constants at these level -- the constants will need to be added in the platform-specific directories. If you want to make this layer more portable, then the `C_LONG` constant should be dropped, and clients should use either `C_INT` or `C_LONG_LONG` (which is what most portable C APIs end up doing anyway).

Another possible way to have a more robust shared layer is to use definitions in stdint.h -- e.g. not `C_INT`, but `C_INT32_T` (but then you might have issues, as the jextract-generated files you are importing depend on names like `C_INT`).

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 99:

> 97:             .or(Linker.nativeLinker().defaultLookup());
> 98: 
> 99:     public static void traceDowncall(String name, Object... args) {

The tracing downcal support is also something that might be moved directly to the Linker -- either as a Linker option, or as a global flag, similar to `Xcheck:jni` (not in this PR)

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 106:

> 104:     }
> 105: 
> 106:     public static MemorySegment findOrThrow(String symbol) {

Hopefully this can go away once we update jextract to a new version that doesn't require this (not in this PR):
https://github.com/openjdk/jextract/pull/280

src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 118:

> 116:     }
> 117: 
> 118:     public static MemoryLayout align(MemoryLayout layout, long align) {

As observed in the past, this `align` method could probably just be added on `MemoryLayout` (not as part of this PR, this is just a general observation).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244889620
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244899130
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244904140
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244897270

From mcimadamore at openjdk.org  Thu Jul 31 09:53:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Jul 2025 09:53:58 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
Message-ID: <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>

On Thu, 31 Jul 2025 09:45:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 51:
> 
>> 49:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
>> 50:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
>> 51:     public static final ValueLayout.OfLong C_LONG = (ValueLayout.OfLong) Linker.nativeLinker().canonicalLayouts().get("long");
> 
> This seems problematic. On Windows, the C type `long` has a `JAVA_INT` layout, because it only uses 32 bits. The reason jextract re-generates all these constants is that they can, in general, vary by platform, so my general feeling is that we can't just have a shared set of layout constants at these level -- the constants will need to be added in the platform-specific directories. If you want to make this layer more portable, then the `C_LONG` constant should be dropped, and clients should use either `C_INT` or `C_LONG_LONG` (which is what most portable C APIs end up doing anyway).
> 
> Another possible way to have a more robust shared layer is to use definitions in stdint.h -- e.g. not `C_INT`, but `C_INT32_T` (but then you might have issues, as the jextract-generated files you are importing depend on names like `C_INT`).

IMHO the more honest approach is to move these constants closer to the _h generated files that use them, as that's the way jextract intends them to be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2244894284

From mcimadamore at openjdk.org  Thu Jul 31 12:17:57 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 31 Jul 2025 12:17:57 GMT
Subject: RFR: 8360025: (se) Convert kqueue Selector Implementation to use
 FFM APIs
In-Reply-To: <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>
References: <TM-kE1ikMg1jSOq2BzhnFO1lOqzLv8WGy1xxrMEtCbw=.09124cfc-c08f-4c12-822a-084e6fc22579@github.com>
 <Ff05ao90-5o4GMTnLclSrFfBY8y3WTKWROAccW_Gw1s=.58507938-39d3-46e2-ae9f-e641c87acb57@github.com>
 <O_8NkCWn3ufZSs51ProN7S6rwiNBqKJ8bgK6gFy28Vo=.6faf6e80-3674-4095-a886-5a69a07aeda7@github.com>
Message-ID: <g5myrFBNeMK9tEw7IwwXeC1Ut2UblEPY10I1jQgDCpE=.32a118f3-49d7-4793-a279-4981ce72bbf6@github.com>

On Thu, 31 Jul 2025 09:46:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/ffi/util/FFMUtils.java line 51:
>> 
>>> 49:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
>>> 50:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
>>> 51:     public static final ValueLayout.OfLong C_LONG = (ValueLayout.OfLong) Linker.nativeLinker().canonicalLayouts().get("long");
>> 
>> This seems problematic. On Windows, the C type `long` has a `JAVA_INT` layout, because it only uses 32 bits. The reason jextract re-generates all these constants is that they can, in general, vary by platform, so my general feeling is that we can't just have a shared set of layout constants at these level -- the constants will need to be added in the platform-specific directories. If you want to make this layer more portable, then the `C_LONG` constant should be dropped, and clients should use either `C_INT` or `C_LONG_LONG` (which is what most portable C APIs end up doing anyway).
>> 
>> Another possible way to have a more robust shared layer is to use definitions in stdint.h -- e.g. not `C_INT`, but `C_INT32_T` (but then you might have issues, as the jextract-generated files you are importing depend on names like `C_INT`).
>
> IMHO the more honest approach is to move these constants closer to the _h generated files that use them, as that's the way jextract intends them to be used.

(Also, the latest version of jextract uses `Linker.canonicalLayouts` to derive these constants, which might be more robust longer term)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2245216232

From alanb at openjdk.org  Thu Jul 31 16:20:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Jul 2025 16:20:54 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v4]
In-Reply-To: <XYJC_B6c8jl3A9NoP8m2Brz9r4p6hE4Y4pfsHse6muQ=.6e29fbbf-2843-4d99-94e4-7a3e5d515cc1@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
 <XYJC_B6c8jl3A9NoP8m2Brz9r4p6hE4Y4pfsHse6muQ=.6e29fbbf-2843-4d99-94e4-7a3e5d515cc1@github.com>
Message-ID: <NB2CohHVgEJTAlA92nnufjfwhF62rkvrvFh0h0PUtSI=.86bccc30-1269-4bb5-8b98-4c4a8a6c2301@github.com>

On Wed, 30 Jul 2025 18:03:10 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Address code review comments which came in post integration/merge of https://github.com/openjdk/jdk/pull/26282.
>> 
>> Update/clarify test summary tag
>> Document the values generated for arguments
>> Move the endian-ness qualifier in the test descriptor string to not be first
>> Change test method names to more closely match arg names of method under test
>
> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

[JDK-8364345](https://bugs.openjdk.org/browse/JDK-8364345) tracks an intermittent failure with the test where CharBufferAsCharSequenceTest.randomizeRange fails.

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

PR Comment: https://git.openjdk.org/jdk/pull/26512#issuecomment-3140561226

From duke at openjdk.org  Thu Jul 31 16:57:54 2025
From: duke at openjdk.org (Brett Okken)
Date: Thu, 31 Jul 2025 16:57:54 GMT
Subject: RFR: 8364213: (bf) Improve java/nio/Buffer/GetChars.java test
 comments [v4]
In-Reply-To: <NB2CohHVgEJTAlA92nnufjfwhF62rkvrvFh0h0PUtSI=.86bccc30-1269-4bb5-8b98-4c4a8a6c2301@github.com>
References: <QZ62aJaZA2XbludyIc3AOdML1cCzOwSIQI9InS3ITIM=.11fa6b8b-2f66-4ca5-bda5-6960f406a8d2@github.com>
 <XYJC_B6c8jl3A9NoP8m2Brz9r4p6hE4Y4pfsHse6muQ=.6e29fbbf-2843-4d99-94e4-7a3e5d515cc1@github.com>
 <NB2CohHVgEJTAlA92nnufjfwhF62rkvrvFh0h0PUtSI=.86bccc30-1269-4bb5-8b98-4c4a8a6c2301@github.com>
Message-ID: <H5n5w4F2nqA3pJXcdTKISRdrF-wOpM-0kdfbw35sdps=.74f2499b-9410-45f0-b4e8-46dae65f087d@github.com>

On Thu, 31 Jul 2025 16:17:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brett Okken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> [JDK-8364345](https://bugs.openjdk.org/browse/JDK-8364345) tracks an intermittent failure with the test where CharBufferAsCharSequenceTest.randomizeRange fails.

@AlanBateman [JDK-8364345](https://bugs.openjdk.org/browse/JDK-8364345) was fixed in https://github.com/openjdk/jdk/pull/26512/commits/5ec88b87cf525d5ac19147b28e98f225f9f67deb

The problem was when a `CharBuffer` which had already had a random range applied was sliced and then randomized again.

https://github.com/openjdk/jdk/pull/26512/files#diff-07e323ba9598a996e3c48942181ad955762b67e6759c9f210ebb69c049d76606R116

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

PR Comment: https://git.openjdk.org/jdk/pull/26512#issuecomment-3140685589

From alexei.olkhovskii at servicenow.com  Thu Jul 31 19:34:35 2025
From: alexei.olkhovskii at servicenow.com (Alexei Olkhovskii)
Date: Thu, 31 Jul 2025 19:34:35 +0000
Subject: NIO Socket.read() may not respect the socket timeout
In-Reply-To: <CH4PR08MB10510AFBA879C545EBBF88DEF8D66A@CH4PR08MB10510.namprd08.prod.outlook.com>
References: <CH4PR08MB1051010F0EB8E98012D9C3BA88D64A@CH4PR08MB10510.namprd08.prod.outlook.com>
 <e2131fa9-0c42-426a-8698-6515f5b5efe3@oracle.com>
 <CH4PR08MB10510844B2F10A5DC410D40E08D67A@CH4PR08MB10510.namprd08.prod.outlook.com>
 <c813aede-581a-45d7-aa02-ff461a831989@oracle.com>
 <CH4PR08MB1051078FA9DA27F54C44E0F328D67A@CH4PR08MB10510.namprd08.prod.outlook.com>
 <b0ea0482-1736-4948-8bc1-a934a7dfba01@oracle.com>
 <CH4PR08MB10510AFBA879C545EBBF88DEF8D66A@CH4PR08MB10510.namprd08.prod.outlook.com>
Message-ID: <CH4PR08MB10510055D739395AD8ADF06678D27A@CH4PR08MB10510.namprd08.prod.outlook.com>

@Alan Bateman<mailto:alan.bateman at oracle.com> just noticed your commit addressing the issue and wanted to say that we really appreciate you opening the bug and fixing it.
The problem is getting hot lately and the fix will be very helpful. Thank you!

Ref: https://bugs.openjdk.org/browse/JDK-8358496

--
Regards, Alexei (team: Data Scale/Dev-Persistence, dept: Platform Engineering, Loc: San Diego, Mgr: Venkata Koya, Teams/MM: alexei.olkhovskii)

From: Alexei Olkhovskii <alexei.olkhovskii at servicenow.com>
Date: Thursday, May 29, 2025 at 14:20
To: Alan Bateman <alan.bateman at oracle.com>, nio-dev at openjdk.org <nio-dev at openjdk.org>
Subject: Re: NIO Socket.read() may not respect the socket timeout
> It's hard to know if there if there is a case where concurrent reads from the same TCP/socket stream make sense ... If there is a protocol where it's possible to do something sensible when reading subsets of bytes, and with different timeouts, or code handling SocketTimeoutException then maybe your point could be looked ...

Yes, a conscious design involving concurrent Socket use would be a strange thing, no argument there. Also, your point about connect() makes total sense.

Going back to read(), what would be the way out of the situation for the API users? The app has detected stale data in the socket buffer and tries to clean things up. It isn?t aware the other reader is still alive and calls JDBC abort(). The JDBC spec allows Connection sharing, the driver isn?t even obliged to check for concurrency. Sure, it is doing a questionable read(), but while taking the timeout precautions.
In this situation NIO is the only player aware of the other reader. Which brings us to the choice: try to eliminate the reason the other player is holding the lock (which sounds like an uphill battle) or behave transparently to the lock presence: wait for the timeout interval and return -1 like if there was no data. Besides, the lock is an internal library mechanism whose existence has only surfaced accidently.
>From the API user standpoint, the second option sounds simpler to handle. Not saying we ever will but should someone want to code around a hund read, that?d bring a lot of complexity.

> I'd prefer not use that to justify doing something to help a workaround when it does happen.

Please note that we?d not make the situation worse than today, should somebody attempt to call read() concurrently. The logical difference would be ?the call returned no data because **there is** no data? vs ?the call returned no data because somebody else is reading it and we?ve timed out? (as opposed to today?s ?wait for an uncertain interval till the other party has finished their read?).

--
Regards, Alexei

From: Alan Bateman <alan.bateman at oracle.com>
Date: Thursday, May 29, 2025 at 10:40
To: Alexei Olkhovskii <alexei.olkhovskii at servicenow.com>, nio-dev at openjdk.org <nio-dev at openjdk.org>
Subject: Re: NIO Socket.read() may not respect the socket timeout
[External Emai

________________________________

On 28/05/2025 20:46, Alexei Olkhovskii wrote:
> This may be an issue with the reserved stack area. There was work done in JDK 9 via JEP 270 [1] but I think it needs to be looked at again.
Perhaps https://bugs.openjdk.org/browse/JDK-8318888<https://bugs.openjdk.org/browse/JDK-8318888> is also relevant.

Yes, there are a few reports of issues when continuing after SOE.


But regardless of the reason the other thread is holding the lock, don?t you think the socket timeout should be respected for read(), connect(), etc?

The connect method is only allowed once. It would be strange to create an unconnected Socket and then attempt to have 2 threads invoke connect. The second attempt must fail with SocketException (it will be "Connection in progress" or "Socket closed"). You are right that the second attempt will block, maybe beyond the connect timeout it specifies, before it throws the SocketException. I don't think this is worth spending time on as there is impossible for the second connect to succeed.

It's hard to know if there if there is a case where concurrent reads from the same TCP/socket stream make sense. At one point it was possible to have a Socket to a UDP socket but that mis-feature is deprecated a long time ago. If several threads are reading from the same stream then it requires coordination at a higher level, something that understands the protocol, meaning the lock contention will be further up the stack. If there is a protocol where it's possible to do something sensible when reading subsets of bytes, and with different timeouts, or code handling SocketTimeoutException then maybe your point could be looked. For now, I think the issue here is the "lock corruption" and we need to understand this a bit more. I'd prefer not use that to justify doing something to help a workaround when it does happen.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250731/b21829d6/attachment-0001.htm>