JEP 400 vs new Scanner(System.in)

[Alan Bateman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221020/778fba67/attachment.htm>