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.sh...@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 >
