Hi mh, any progress on the issue of the last figure?
I’ll check with the debugger team on Monday. As i recall, all debugger-side issues here were fixed, but some platforms (including .NET 4.x on Windows, but i don’t recall about Java) simply defaulted to a non-Unicode code page.
For a fact, .NET 4.x apps don’t show Unicode on the output on Windows because .NET is set to not output Unicode — it’s not a debugger issue, and setting the proper codepage on the Console class fixes that. Java might be the same… (on Mac, both are fine by default)…
2 Likes
Hello!
Java has the same problem as .NET, default code page is non-Unicode.
The following helps to output unicode symbols
System.setOut(new java.io.PrintStream(System.out, true, "utf-8"));
2 Likes
Thanks mh and elenap for the info and help.
One more question for curious:
I read the news, it said that java 18 is just released and it uses utf-8 by default. In water, I tried to target JDK 18 without this line, it has the same problem with JDK 18. Not sure why, the code page mean the code page in JDK or in water IDE?
System.setOut(new java.io.PrintStream(System.out, true, "utf-8"));
1 Like
A really easy test is: what happens if you run the same app in a Command Prompt window? If you also don’t see Unicode, then it’s because the app isn’t emitting Unicode properly. If you do see Unicode there, and only then, could it be an issue of the debugger mangling/flattening the output.
The code page used by your app (and the underlying Java APIs it uses) to send strings to StdOUT.
FWIW, with OpenJDK 18 on Windows 11, i get Unicode output with Elena’s fix, but not without — in Water.
In Terminal, i get flattened ASCII ("??") without setting the codepage, and what looks like badly interpreted UTF-8 with it (which i assume is Window’s bug, or a Java bug?)
Hi mh,
On my computer, it behave like this (I am using Windows 11 Chinese version), actually the behavious always the same regardless the JDK version.
With elenap’s fix:
In water, fine.
In windows command prompt, not fine.
Without the fix:
In water, not fine.
In windows command prompt, fine.
The strange thing is, I never has this problem when using any version of JDK with Intellia Idea with Win 10/11. Never has to put elenap’s line into the code to show the unicode contents. If using Idea, both debug panel and windows command prompt are fine.
The problem is quite a big trouble. If I put the fixing line in the code, I still need to remove it when ready to run it outside water (I mean, running on Win 11 and getting correct outputs on windows command prompt.) If I do not put the fixing line in the code, in water I can not get correct contents for debugging.
Also I am not sure the fixing line will just work for the method or the class or the whole app? If just work for the method, then it mean I will have to add/remove the fixing line again and again.
Curious. i wonder if Chinese Windows has a different default code page set for COmmand Prompt, or someting like that…
This is a long long story, I will try to explain.
By default, Chinese Windows use GBK (936), but in the windows NT kernel, it uses UTF16. Why it uses UTF16 but not UTF8, that’s because, when Windows 2000 is release, there is no UTF-8 in the world. Also, UTF16 can save space when storing Chinese strings.
The difference is (if I remember correctly):
For GBK, english uses 1 byte, and chinese uses 2 bytes.
For UTF8, english uses 1 byte, and chinese uses 3 bytes.
For UTF16, english uses 1 byte, and chinese uses 2 bytes.
Also tried to keep the code page 65001 (UTF8), and uses JDK 18 (which claim use UTF8 by default), without the fixing line.
It behave the same as JDK 17.