On Thu, 1 May 2025 23:33:00 GMT, Tatsunori Uchino <d...@openjdk.org> wrote:
>> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting >> idea, but would introduce compatiblity concerns. It would have been simpler >> if we had `stdin/out/err.encoding` system properties prior to JEP 400. >> As to testing on Windows, I would like to know how the Windows `UILanguage` >> affects these, afaik we only have tested on English Windows. Say how it >> works on Japanese Windows with English system locale. However, since we have >> not changed any existing behavior (from the code wise), I don't think we >> would see any issues. > > In Java 17 or prior, non-advanced Windows users especially whose language has > a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had > been satisfied the behavior at that time. > JEP 400 broke everything in stdin in Windows. Currently we need to check both > stdin.encoding and (sun.)stdout.encoding in every constructor caller to > support older Java versions. > > One idea to fix is to check whether the parameter InpuReader is System.in or > not in the constructor of InputStreamReader. > > https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418 I think we have only to change console encodings by e.g. `chcp 932` (CMD) or `[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::Get Encoding(932)` (PowerShell) in Windows. They correspond to `GetConsoleCP` and `GetConsoleOutputCP`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070940588
