On 20/10/2022 01:05, Reinier Zwitserloot wrote:
:
JDK18 brought JEP400 which changes the default charset encoding to
UTF-8. This, probably out of necessity, goes quite far, in that
|Charset.defaultCharset()| is now more or less a constant - always
returns UTF_8. It’s now quite difficult to retrieve the OS-configured
encoding (the ’native’ encoding).
However, that does mean one of the most common lines in all of java’s
history, is now necessarily buggy: |new Scanner(System.in)| is now broken.
System.in has always been problematic, including new Scanner(System.in),
as it could be connected to anything.
As Ron noted, Console (since Java 6) provides readLine, reader, and
printf so it's not bad for reading and writing lines of text, something
that will be typical when starting out. Yes, Console is problematic for
tooling that takes ownership of the console. We've been mulling over
introducing a SPI for that - if you back through the archives then
you'll see some early discussion on that. If the JDK has a SPI then it
would mean that jshell and IDEs would be able to provide an
implementation that works in respective environments and so provide a
better experience for code that uses System.console.
You are right that further work is required to move away from using
System.in directly. JDK-8295672 [1] is tracking some of the ideas for
possible APIs. The focus is a bit different to your list as we don't
want to expose the notion of Charsets to new users nor provide APIs like
System.charIn that wouldn't support reading lines or work with
redirection. Prototypes and experimentation will required to find the
right API to propose.
-Alan
[1] https://bugs.openjdk.org/browse/JDK-8295672
