On Thu, 14 Oct 2021 23:43:47 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> @takiguc - if JShell is still an issue, is there a chance you could try this: >> https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686 >> >> Not sure if it will help, but it might (this won't change the default >> charset, but could send the output in a sensible encoding for the console. >> >> Thanks! > > I believe both @lahodaj and my proposed changes are needed, which I provided > here: > https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5 > Can you check this works? Hello @naotoj . [82a9033](https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5) worked on Windows platform, then I got your point. To minimize changes, I think I should create new method and call from JShellToolBuilder.java and JShellToolProvider.java. static PrintStream derivePrintStream(PrintStream ps) { if (Charset.defaultCharset().equals(NATIVE_CHARSET)) { return ps; } else { return new PrintStream(new WriterOutputStream( new OutputStreamWriter(ps, NATIVE_CHARSET), Charset.defaultCharset())); } } Additionally, I tested this issue on non-UTF-8 platform like RHEL7/CentOS7 EUC locale (ja_JP.eucjp). It seemed JLine's terminal's encoding was still UTF-8. I could not input Japanese character as expected, also Cut & Paste with Japanese string did not work. In my investigation, Charset.defaultCharset() was used on AbstractTerminal.java https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java#L55-L62 I should be like, this.encoding = encoding != null ? encoding : nativeCharset; (JLine was upgraded by b19, I need to rebase if it's required) One more thing, For Inter-Process Communication between jshell front-end and agent, I think default charset should be same for non UTF-8 environment. I think JdiInitiator.java should be modified. Please give me your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/5771
