RFR 8124977 cmdline encoding challenges on Windows

Mon Feb 22 16:00:25 UTC 2016

Hi Naoto, Sherman,  can you please take a look.
I tested with the jprt build and test all tests pass.

Hi Vladimir, et. al.,

It appears that there has been more simplifications from the previous 
webrev.04. :-)

It would've helped if you highlight the changes you have made from the 
previous
revision, unfortunately this is one of the deficiencies of webrev.

There are some inconsistencies in the coding conventions:

parse_manifest.c
+ if (q == 0) return -1;

we expect the return to be on the next line.

similarly main.c

if (0 == q)
{

I can fix those up. If I were to push this change, who should I 
attribute the
changes to ? ie. in the Contributed-by: line of the commit info ?
Please note these have to be email addresses of the contributors.

Thanks
Kumar

> Hi Kumar,
>
> We posted another web review here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.05/
>
> The patch was successfully tested.
>
> Test details:
> * Regression tests folder: jdk/test/tools/launcher/
> * Builds were used: windows-x86_64-normal-server-fastdebug, windows-x86_64-normal-server-release, windows-x86-normal-server-release;
> * Platforms were used:  Windows 7(64 bit), Windows 8.1, Windows Server 2012 R2 DC, Windows 10 ;
> * System locales were used: English (United States), Persian, Japanese (Japan), Chinese (Traditional, Taiwan), Russian (Russia);
>
> Thanks,
> Vladimir.
>
> -----Original Message-----
> From: Martin Sawicki
> Sent: Thursday, January 14, 2016 11:34 AM
> To: Kumar Srinivasan <kumar.x.srinivasan at oracle.com>; Vladimir Shcherbakov <vlashch at microsoft.com>
> Cc: core-libs-dev Libs <core-libs-dev at openjdk.java.net>; Naoto Sato <naoto.sato at oracle.com>
> Subject: RE: RFR 8124977 cmdline encoding challenges on Windows
>
> 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.srinivasan at oracle.com]
> Sent: Tuesday, January 12, 2016 2:35 PM
> To: Martin Sawicki <marcins at microsoft.com>; Vladimir Shcherbakov <vlashch at microsoft.com>
> Cc: core-libs-dev Libs <core-libs-dev at openjdk.java.net>; Naoto Sato <naoto.sato at 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.srinivasan at oracle.com>; Martin Sawicki
>>> <marcins at microsoft.com>
>>> Cc: Kirk Shoop <Kirk.Shoop at microsoft.com>; core-libs-dev Libs
>>> <core-libs-dev at 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.open
>>> jdk.java.net%2f~kshoop%2f8124977%2fwebrev.04%2f&data=01%7C01%7Cmarcin
>>> s%40microsoft.com%7C13ff309b775c4c019fc308d31ba0c43c%7C72f988bf86f141
>>> af91ab2d7cd011db47%7C1&sdata=3hhbO5mNPyTvtrTb4kCR42zsWGPGzDhqnmjpNfwn
>>> bIw%3d
>>>
>>> Thanks,
>>> Vladimir.
>>>
>>> -----Original Message-----
>>> From: Kumar Srinivasan [mailto:kumar.x.srinivasan at oracle.com]
>>> Sent: Sunday, November 22, 2015 8:14 AM
>>> To: Martin Sawicki <marcins at microsoft.com>
>>> Cc: Kirk Shoop <Kirk.Shoop at microsoft.com>; Vladimir Shcherbakov
>>> <vlashch at microsoft.com>; core-libs-dev Libs
>>> <core-libs-dev at 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.op
>>> enjdk.java.net%2fjdk9%2fdev%2fjdk%2frev%2f3b201a9ef918&data=01%7c01%7
>>> cvlashch%40microsoft.com%7c4d49ae546dba4d29b7be08d2f3589ee1%7c72f988b
>>> f86f141af91ab2d7cd011db47%7c1&sdata=I2FKvBn82%2fxhW3D%2fi%2bRWaNOJk7M
>>> g4lt2P0sdzLS%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%40mic
>>>> ro
>>>> soft.com%7c4d49ae546dba4d29b7be08d2f3589ee1%7c72f988bf86f141af91ab2d
>>>> 7c
>>>> d011db47%7c1&sdata=FjmfM%2fnPbWB%2fMsUU8uDzAUo3aPu3zOELVsJO%2fsUIq9E
>>>> %3
>>>> d
>>>> Webrev:
>>>> https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fcr.ope
>>>> nj
>>>> dk.java.net%2f~kshoop%2f8124977%2fwebrev.03%2f&data=01%7C01%7Cvlashc
>>>> h%
>>>> 40microsoft.com%7C4d49ae546dba4d29b7be08d2f3589ee1%7C72f988bf86f141a
>>>> f9
>>>> 1ab2d7cd011db47%7C1&sdata=101HBPar2AZ63GJWyubWH0DiKmNI%2bOxknN667BJn
>>>> WY
>>>> 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-bounces at openjdk.java.net]
>>>> On Behalf Of Kumar Srinivasan
>>>> Sent: Thursday, June 25, 2015 6:26 AM
>>>> To: Kirk Shoop (MS OPEN TECH) <Kirk.Shoop at microsoft.com>
>>>> Cc: Valery Kopylov (Akvelon) <v-valkop at microsoft.com>; core-libs-dev
>>>> Libs <core-libs-dev at 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%2fbu
>>>>> gs
>>>>> .openjdk.java.net%2fbrowse%2fJDK-8124977&data=01%7c01%7cvlashch%40m
>>>>> ic
>>>>> rosoft.com%7c4d49ae546dba4d29b7be08d2f3589ee1%7c72f988bf86f141af91a
>>>>> b2
>>>>> d7cd011db47%7c1&sdata=FjmfM%2fnPbWB%2fMsUU8uDzAUo3aPu3zOELVsJO%2fsU
>>>>> Iq
>>>>> 9E%3d
>>>>>
>>>>> Webrev:
>>>>> https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fcr.op
>>>>> en
>>>>> jdk.java.net%2f~kshoop%2f8124977%2f&data=01%7C01%7Cvlashch%40micros
>>>>> of
>>>>> t.com%7C4d49ae546dba4d29b7be08d2f3589ee1%7C72f988bf86f141af91ab2d7c
>>>>> d0
>>>>> 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