The standard input in Java can be accessed, typically, though System.in or, if System.console() returns non-null, through that returned java.io.Console object.

In JDK 22, System.console() returns an object in all cases where it previously returned one, and in some other cases where it previously returned null. For that reason, it's important that reading from System.console() is consistent with reading from System.in.

Now, java.io.Console provides two ways of reading: readLine() and reader(). readLine() returns lines, whereas reader() returns java.io.Reader, which can then be used to read lines. For example, it can be wrapped into java.io.BufferedReader, which provides readLine().

The way BufferedReader slices a stream of characters into a stream of lines is OS-agnostic and standard across many Java APIs, such as java.io, java.lang.String, java.nio.file.Files.

Wrapped into BufferedReader, System.console().reader() seems to be consistent with System.in. However, System.console.readLine() is not: it slices lines differently. Thus, System.console().readLine() behaves in a non-intuitive and unexpected way. It should be fixed, specified, or both.