On Tue, 3 Feb 2026 17:36:16 GMT, Naoto Sato <[email protected]> wrote:
>> Fixing an issue in Console where write is blocked if other thread is waiting
>> to read, which is caused by unnecessary read/write locks. Removing those
>> would solve the problem, as the read/write synchronization is performed at
>> the StreamEn/Decoder level. One unrelated change is to refactor
>> double-checked locking with LazyConstant.
>
> Naoto Sato has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the unrelated changes brought in
> by the merge/rebase. The pull request contains nine additional commits since
> the last revision:
>
> - Reflects Jai's review comments
> - Merge branch 'master' into
> JDK-8340830-Console-readLine-printf-mutually-blocking
> - Added @requires condition
> - added jline test run
> - Merge branch 'master' into
> JDK-8340830-Console-readLine-printf-mutually-blocking
> - Fixed indentation
> - Made ProxyingConsole value-based, used anonymous class for LazyConstant
> - Refine exceptions
> - initial commit
test/jdk/java/io/Console/ReadWriteBlockingTest.java line 27:
> 25: * @test
> 26: * @bug 8340830
> 27: * @summary Check if writing to Console is not blocked by other thread's
> read.
Should we make it apparent in the summary that this test is non-deterministic?
test/jdk/java/io/Console/ReadWriteBlockingTest.java line 78:
> 76: CountDownLatch latch = new CountDownLatch(2);
> 77:
> 78: Thread.ofVirtual().start(() -> {
Based on the way this test is setup with _expect_, I think the previous testing
code was actually better at detecting the issue at hand, since it "presumably"
had a higher chance to `readLine` first. Given the old implementation,
`readLine` would acquire the write lock unnecessarily, preventing `printf` from
entering and executing, causing the test to fail since _expect_ would never
receive the "printf() invoked" and never be able to provide input to `readLine`.
The new test "presumably" has equal chances to either read or write first.
However, if the `printf` executes first, I don't see how the test will fail.
With the old implementation, even if `printf` acquires the lock at first and
`readLine` was blocked from entering, `printf` will eventually finish and
release the lock, and provide the expected message to _expect_.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760567760
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760540406
