I don't remember it being considered, but I think it falls outside the scope of
JEP 477 (emphasis mine):
> We achieve this effect by declaring a new top-level class in the java.io
> package named, simply, IO. It declares the above three static methods for
> **textual** I/O with the console, and nothing else.
java.io.IO is closely related to java.io.Console, which provides access to a
terminal in a more or less canonical mode to read and write _strings_. While it
might be useful for Console to separately provide access to a terminal in the
raw mode, I'm not sure how often developers, let alone on-ramp developers, need
it. In my experience, programming games, such as those you mentioned, is better
introduced with GUI, where they have java.awt.event.KeyListener.
-Pavel
> On 8 May 2024, at 14:59, Olexandr Rotan <rotanolexandr...@gmail.com> wrote:
>
> Has it been considered to add a readKey() method to IO class? In my
> experience, it is pretty commonly used by beginners when they write things
> like console games (snake, catcher game etc.). I am aware there is
> System.in.read() method, but since we decided to promote some methods to
> separate methods in IO class, maybe readKey() or simple read() should also be
> considered?
>
> On Wed, May 8, 2024 at 4:16 PM Pavel Rappo <pra...@openjdk.org> wrote:
> On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>
> >> If we specify that, it would be very much unlike all other `Console`
> >> methods that are covered by this:
> >>
> >> * Unless otherwise specified, passing a {@code null} argument to any
> >> method
> >> * in this class will cause a {@link NullPointerException} to be thrown.
> >
> > I haven't given it a try, but a brief look at the code suggests that if the
> > console implementation backed by JLine gets used, then a `null` prompt may
> > not generate a `NullPointerException` (since JLine appears to allow `null`)
> > whereas if the internal JDK console implementation gets used then a
> > `NullPointerException` will get thrown. If the expectation is to disallow a
> > `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand
> > off to the underlying console implementations might be required.
>
> Good catch!
> `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)`
> does not throw `NullPointerException` (NPE), which it must. I'll fix the bug
> and add a test.
>
> Speaking of NPE. The newly added `Console.print` and `Console.println`
> methods do not throw NPE if passed null. While that's how it should be, they
> don't specify that, so the class-level NPE clause applies:
>
> * Unless otherwise specified, passing a {@code null} argument to any
> method
> * in this class will cause a {@link NullPointerException} to be thrown.
> ...
> public sealed class Console implements Flushable permits ProxyingConsole {
>
> I'll fix that.
>
> We should also specify NPE (or absence thereof) on methods of `IO`.
> Otherwise, this package clause applies:
>
> * Unless otherwise noted, passing a {@code null} argument to a
> constructor or
> * method in any class or interface in this package will cause a
> * {@code NullPointerException} to be thrown.
> ...
> package java.io;
>
> @stuart-marks speaking of exceptions. Do we need to add explicit `@throws`
> tag to `IO` methods?
>
> @throws {@code IOError} if {@code System.console()} returns {@code null}
>
> While it would make sense, it would also look superfluous: we already specify
> that error condition in the class comment and then in every method's main
> description. Do we need to add one more note on `IOError`?
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064
