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:
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
