On Mon, 14 Jul 2025 20:23:25 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> In prior JDK releases, `System.console()` could return a `Console` instance >> even when the JVM was not attached to an interactive terminal. This could >> lead to confusion, particularly when input was not from a keyboard or output >> was redirected, such as to or from a file or pipe, especially when using >> methods like `readPassword()`. Starting with JDK 25, the default behavior >> has changed: `System.console()` now returns `null` if standard input and/or >> output is redirected. However, if a JLine-based Console implementation is >> explicitly specified via the system property >> `-Djdk.console=jdk.internal.le`, the previous behavior may still occur. >> This PR aims to align the behavior of the JLine-based `Console` >> implementation with the default `System.console()` behavior. The actual code >> change is a one-liner in `JdkConsoleProviderImpl.java`; the rest of the >> changes are adjustments to test cases to reflect the updated behavior. A >> corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflects review comments ecki wrote: > I know my View of console is always a bit controversial, but having access to > /dev/tty despite a program have redirected stdout and stderr would be a > feature, not something you actively need to disable. But I guess writing system tools it not something Java ever was made for :) [extracted from HTML and edited slightly by me] There is as usual a bunch of history here. The Java `Console` class doesn't use /dev/tty at all. In retrospect it might have been preferable for it to have used `/dev/tty` from the beginning, at least on Unix. However, that's not the case; it's always been a wrapper around the combination of stdin and stdout. Having to support equivalent functions on Windows might have played a part in this design. In any case, since its introduction in JDK 1.6, `Console` has been based on stdin and stdout and not /dev/tty. The question then arises as to what should happen if one or both of stdin or stdout have been redirected. Historically, if either were redirected, `System.console()` would return null, meaning that "the console does not exist." More recently, we introduced the JLine console provider in order to provide line editing. Unfortunately this confused the situation, as it would provide a non-null `Console` instance in certain cases even if stdin or stdout were redirected, leading to confused and inconsistent behavior. That's what this PR is fixing. There's still a broader question of, could `Console` use /dev/tty? Calling `System.console()` to obtain a `Console` instance might open /dev/tty directly. This could work even if all of stdin, stdout, and stderr are redirected. And it could provide a full set of features (including no-echo when reading passwords, and line editing) even in this case. This could be quite useful. However, this would be an incompatbile behavior change. Given the history of `Console`, there are programs out there that assume that it is based around stdin and stdout and mix operations on them. However, it might be possible to create a `Console` based on /dev/tty, and applications that are prepared for this change could opt into using this implementation. There are also questions about how this would work on Windows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26273#issuecomment-3211704997
