Hi all Here's an updated webrev attempting to take into account the various pieces of feedback we have received:
Issue: https://bugs.openjdk.java.net/browse/JDK-8124977 Webrev: http://cr.openjdk.java.net/~kshoop/8124977/webrev.03/ (Vladimir Shcherbakov is now working on this from our side) Looking forward to any other feedback. Thanks -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Kumar Srinivasan Sent: Thursday, June 25, 2015 6:26 AM To: Kirk Shoop (MS OPEN TECH) <kirk.sh...@microsoft.com> Cc: Valery Kopylov (Akvelon) <v-val...@microsoft.com>; core-libs-dev Libs <core-libs-dev@openjdk.java.net> Subject: Re: RFR 8124977 cmdline encoding challenges on Windows Hi Kirk, Thanks for proposing this change. If you notice all the posix calls are wrapped in JLI_* this gives us the ability to use "W" functions. I almost got it done, several years ago, but we upgraded to VS2010 and my work based on VS2003 keeled over, meanwhile my focus was "shifted" to something else. main.c: is really envisioned to be a stub compiled by the tool launchers, like java, javac, javah, jar etc. I prefer to see all the heavy logic in this file moved to the platform specific file windows/java_md.* For the reason specified above we need to move fprintf or any naked posix calls to JLI_* indirections. I don't see any tests ? The tests must be written in java and placed in jdk/test/tools/launcher, there is a helper framework TestHelper.java. There are other changes in nio, charsets etc, this will be reviewed by my colleague specializing in that area (Sherman) cc'ed. Thanks Kumar On 6/22/2015 2:01 PM, Kirk Shoop (MS OPEN TECH) 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
