RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking [v6]

[Justin Lu]

On Tue, 3 Feb 2026 17:36:16 GMT, Naoto Sato <naoto at openjdk.org> 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