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] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b201a9ef918
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
