Thanks for the feedback. Investigating the regression failure. We'll get back as soon as we figure this out. (and yes, we'll run this through some localized Windows VMs)
Cheers -----Original Message----- From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com] Sent: Tuesday, January 12, 2016 2:35 PM To: Martin Sawicki <marc...@microsoft.com>; Vladimir Shcherbakov <vlas...@microsoft.com> Cc: core-libs-dev Libs <core-libs-dev@openjdk.java.net>; Naoto Sato <naoto.s...@oracle.com> Subject: Re: RFR 8124977 cmdline encoding challenges on Windows Hi Martin, Vladimir, It was suggested that this patch be tested on localized Windows machines and/or trying with the various Windows native encodings, appreciate if you can verify this as well. Thanks Kumar On 1/11/2016 1:10 PM, Kumar Srinivasan wrote: > Hi, > > Was on vacation, I started to prepare the patch from webrev.04 > for integration. Please note: made some adjustments to your > patch to pass jcheck, ie. usage of tabs and space at line endings, > and modifications to Copyright dates. > > Also fixed a minor bug on unix replaced JLI_TRUE with JNI_TRUE. > I have attached a patch to for your reference. > > However, there is a regression test failure on Windows, > jdk/test/tools/launcher/I18NTest.java > > ---Test info---- > Executed command: C:\mmm\jdk\bin\javac.exe i18nH▒lloWorld.java > > ++++Test Output++++ > javac: file not found: i18nHélloWorld.java > ----End test info----- > > Have you run all the launcher regression tests with this changeset ? > > Thanks > Kumar > >> Hi Kumar, just wondering if there are any updates on processing this >> submission. >> Thanks! >> >> -----Original Message----- >> From: Vladimir Shcherbakov >> Sent: Wednesday, November 25, 2015 2:38 PM >> To: Kumar Srinivasan <kumar.x.sriniva...@oracle.com>; Martin Sawicki >> <marc...@microsoft.com> >> Cc: Kirk Shoop <kirk.sh...@microsoft.com>; core-libs-dev Libs >> <core-libs-dev@openjdk.java.net> >> Subject: RE: RFR 8124977 cmdline encoding challenges on Windows >> >> Hi Kumar, >> >> Please find updated webreview here: >> https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fcr.openjdk.java.net%2f~kshoop%2f8124977%2fwebrev.04%2f&data=01%7C01%7Cmarcins%40microsoft.com%7C13ff309b775c4c019fc308d31ba0c43c%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=3hhbO5mNPyTvtrTb4kCR42zsWGPGzDhqnmjpNfwnbIw%3d >> >> 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 >
