On Thu, 1 May 2025 17:40:56 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> Hello @tats-u , there is no bother, I appreciate you looking at this. >> >> The addition of `stdin.encoding` in >> [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened >> very quickly. I worked with @naotoj and @AlanBateman on it and we think it >> does the right thing, but there are many Windows configurations that we >> don't have the opportunity to test, so more feedback is helpful. >> >> Initially it would be good to understand if `stdin.encoding` is specified >> and implemented correctly, and whether it provides the right behavior for >> `java.lang.IO` in JEP 512. >> >> In the future we can consider additional uses of `stdin.encoding` in other >> parts of the JDK. > > `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 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070927346
