This was on my TODO list back in 2005 or so. I never got around to it, in part because of my personal and Sun's corporate Unix focus, and because waiting for Win98 to be de-supported was a great way to procrastinate. It's good for Microsoft employees (actual Windows users) to work on this - you have a much better idea of what Windows users actually expect. My own never-realized plan was to simply silently switch to full Unicode - use the "W" version of the API anywhere we talk to the OS (by default). But I don't know how existing users might be broken. "default unicode charset" is a bizarre concept to me. Do windows users really have a "regular" charset and a "unicode" charset? If they do, we probably want to keep that concept out of the public non-Windows API somehow. Also, the "W" API is implicitly UTF-16, not any other flavor of Unicode. You probably want to capitalize "unicode". On Mon, Jun 22, 2015 at 2:01 PM, Kirk Shoop (MS OPEN TECH) < Kirk.Shoop@microsoft.com> wrote:
Hi,
Issue: https://bugs.openjdk.java.net/browse/JDK-8124977
Webrev: http://cr.openjdk.java.net/~kshoop/8124977/
This webrev intends to address interaction between Windows console and java apps.
Two switches were added that change the behavior of the launcher. The defaults do not change the launcher behavior.
-Dwindows.UnicodeConsole=true - switches on Unicode support in the Windows console. This optional switch causes the launcher to call GetCommandLineW() and parse the arguments in unicode. It also modifies how the codepage for console output is selected.
-Dfile.encoding.unicode="UTF-8" - identifies Unicode charset to use; If not specified, UTF-8 is used by default. Ignored when windows.UnicodeConsole is not set to true. When the first switch is used, this optional switch allows the codepage for console output to be controlled.
I would like to get feedback on the approach here and any additional work that is required solve these particular Unicode issues on Windows.
Kirk