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

[Naoto Sato]

On Tue, 3 Feb 2026 10:37:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @requires condition
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 40:
> 
>> 38:  */
>> 39: @ValueBased
>> 40: final class ProxyingConsole extends Console {
> 
> I am not familiar with `@ValueBased` and I just read up its documentation. Based on what it says about constructors https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/doc-files/ValueBased.html#L48:
> 
>> the class does not declare (or has deprecated any) accessible constructors
> 
> since `ProxyingConsole` declares a `ProxyingConsole(JdkConsole delegate)` constructor, does it still qualify as a `@ValueBased` class?

I think that should be OK, as `ProxyingConsole` is a private class

> test/jdk/java/io/Console/ReadWriteBlockingTest.java line 66:
> 
>> 64:             jdkDir + "/bin/java",
>> 65:             "-classpath", testClasses,
>> 66:             "ReadWriteBlockingTest");
> 
> I think it's an oversight that the `-Djdk.console=jdk.internal.le` system property is being set in the `@run` of this test definition instead of being passed here to the launched `java` application. I think the test might have to be refactored a bit to have one single `@run ....` and then here in the test method launch the `java` main() with and without that system property.

Good catch! Thanks. The test was not running jline indeed. Now the system property is passed down to the java launcher so that the test correctly checks for both java.base and jline implementations. I think keeping the test run separately would help diagnose the jtreg logs.

> test/jdk/java/io/Console/readWriteBlocking.exp line 27:
> 
>> 25: eval spawn $argv
>> 26: 
>> 27: expect {
> 
> More of a question than a review, given what this regression test is for - detecting a deadlock in `Console` API implementation, is the use of `expect` tool necessary for this test? Or could the test just ensure that the launched `java` application completes normally after the two threads read/write using the `Console` instance?

Yes, it is necessary. Without running it through `expect`, `System.console()` returns null for java.base, as the jtreg environment is not an interactive terminal environment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760219089
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760229748
PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2760223403