RFR: 8264208: Console charset API [v11]
rriggs at openjdk.java.net
Thu Apr 22 15:21:45 UTC 2021
On Tue, 20 Apr 2021 22:35:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:
>> Please review the changes for the subject issue. This has been suggested in a recent discussion thread for the JEP 400 [(https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. A CSR has also been drafted, and comments are welcome [(https://bugs.openjdk.java.net/browse/JDK-8264209)].
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> - Refined the test case.
> - Merge branch 'master' into JDK-8264208
> - Changed shell based test into java based
> - Added link to Charset#defaultChaset() in InputStreamReader.
> - Modified javadocs per suggestions.
> - Added @see links.
> - Added Console::charset() relation with System.in
> - Added comment to System.out/err init.
> - Reflected further review comments.
> - Reverted PrintStream changes
> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/72f17eb7...e585d16f
src/java.base/share/classes/java/io/Console.java line 597:
> 595: return null;
> 596: }
> 597: });
Please keep the charset() method and return CHARSET.
I'm looking at a use case that needs to know the platform charset regardless of whether the console exists.
When a process is launched it may be redirected to /dev/tty or a pseudo tty and in that case
a Reader from that stream should be able to use the encoding of the platform.
Its still a work in progress, but it would save some refactoring or duplication later.
More information about the core-libs-dev