<div dir="ltr">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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2024 at 4:16 PM Pavel Rappo <<a href="mailto:prappo@openjdk.org">prappo@openjdk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <<a href="mailto:jpai@openjdk.org" target="_blank">jpai@openjdk.org</a>> wrote:<br>
<br>
>> If we specify that, it would be very much unlike all other `Console` methods that are covered by this:<br>
>> <br>
>>     * Unless otherwise specified, passing a {@code null} argument to any method<br>
>>     * in this class will cause a {@link NullPointerException} to be thrown.<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
    * Unless otherwise specified, passing a {@code null} argument to any method<br>
    * in this class will cause a {@link NullPointerException} to be thrown.<br>
    ...<br>
    public sealed class Console implements Flushable permits ProxyingConsole {<br>
<br>
I'll fix that.<br>
<br>
We should also specify NPE (or absence thereof) on methods of `IO`. Otherwise, this package clause applies:<br>
<br>
    * Unless otherwise noted, passing a {@code null} argument to a constructor or<br>
    * method in any class or interface in this package will cause a<br>
    * {@code NullPointerException} to be thrown.<br>
    ...<br>
    package <a href="http://java.io" rel="noreferrer" target="_blank">java.io</a>;<br>
<br>
@stuart-marks speaking of exceptions. Do we need to add explicit `@throws` tag to `IO` methods?<br>
<br>
    @throws {@code IOError} if {@code System.console()} returns {@code null}<br>
<br>
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`?<br>
<br>
-------------<br>
<br>
PR Review Comment: <a href="https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064" rel="noreferrer" target="_blank">https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064</a><br>
</blockquote></div>