[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-core-libs-dev
Subject:    RE: RFR 8124977 cmdline encoding challenges on Windows
From:       Martin Sawicki <marcins () microsoft ! com>
Date:       2015-09-28 18:09:44
Message-ID: BLUPR03MB4408297D06531A2E10E0DF3A84F0 () BLUPR03MB440 ! namprd03 ! prod ! outlook ! com
[Download RAW message or body]

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-bounces@openjdk.java.net] On Behalf Of \
                Kumar Srinivasan
Sent: Thursday, June 25, 2015 6:26 AM
To: Kirk Shoop (MS OPEN TECH) <Kirk.Shoop@microsoft.com>
Cc: Valery Kopylov (Akvelon) <v-valkop@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


[prev in list] [next in list] [prev in thread] [next in thread]