Hi Kumar, Please find updated webreview here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.04/
Thanks, Vladimir. -----Original Message----- From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com] Sent: Sunday, November 22, 2015 8:14 AM To: Martin Sawicki <marc...@microsoft.com> Cc: Kirk Shoop <kirk.sh...@microsoft.com>; Vladimir Shcherbakov <vlas...@microsoft.com>; core-libs-dev Libs <core-libs-dev@openjdk.java.net> Subject: Re: RFR 8124977 cmdline encoding challenges on Windows Hi Martin, et. al., Sorry for not getting back earlier, I am very busy right now with my other large commitments for JDK9. I will sponsor this "enhancement/bug fix" sometime in the new year, meanwhile, there is the changeset [1] which is likely to cause merge conflicts, and perhaps logic issues. Thanks Kumar [1] https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhg.openjdk.java.net%2fjdk9%2fdev%2fjdk%2frev%2f3b201a9ef918&data=01%7c01%7cvlashch%40microsoft.com%7c4d49ae546dba4d29b7be08d2f3589ee1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I2FKvBn82%2fxhW3D%2fi%2bRWaNOJk7Mg4lt2P0sdzLS%2fT9Q%3d > Hi all > Here's an updated webrev attempting to take into account the various pieces > of feedback we have received: > > Issue: > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs. > openjdk.java.net%2fbrowse%2fJDK-8124977&data=01%7c01%7cvlashch%40micro > soft.com%7c4d49ae546dba4d29b7be08d2f3589ee1%7c72f988bf86f141af91ab2d7c > d011db47%7c1&sdata=FjmfM%2fnPbWB%2fMsUU8uDzAUo3aPu3zOELVsJO%2fsUIq9E%3 > d > Webrev: > > https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fcr.openj > dk.java.net%2f~kshoop%2f8124977%2fwebrev.03%2f&data=01%7C01%7Cvlashch% > 40microsoft.com%7C4d49ae546dba4d29b7be08d2f3589ee1%7C72f988bf86f141af9 > 1ab2d7cd011db47%7C1&sdata=101HBPar2AZ63GJWyubWH0DiKmNI%2bOxknN667BJnWY > 0%3d > > (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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs >> .openjdk.java.net%2fbrowse%2fJDK-8124977&data=01%7c01%7cvlashch%40mic >> rosoft.com%7c4d49ae546dba4d29b7be08d2f3589ee1%7c72f988bf86f141af91ab2 >> d7cd011db47%7c1&sdata=FjmfM%2fnPbWB%2fMsUU8uDzAUo3aPu3zOELVsJO%2fsUIq >> 9E%3d >> >> Webrev: >> >> https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fcr.open >> jdk.java.net%2f~kshoop%2f8124977%2f&data=01%7C01%7Cvlashch%40microsof >> t.com%7C4d49ae546dba4d29b7be08d2f3589ee1%7C72f988bf86f141af91ab2d7cd0 >> 11db47%7C1&sdata=RAA%2b5aIzKtrk5X85oLXKlPzbpSk%2bgJZRI%2b0QSI11B0M%3d >> >> 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
