FULL PRODUCT VERSION :
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

This also occurs on the latest builds of java 1.7.

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows Version 6.1.7600

A DESCRIPTION OF THE PROBLEM :
When you pass in any string argument to java.exe, if that argument contains non-ascii characters, those characters will be converted to the ascii "?' character. This is especially destructive if the argument is a filepath, since it means that the path will not actually refer to the intended file on the filesystem!

(We noticed this problem because our Asian users--who have non-ascii user names and thus non-ascii home directory paths-- are unable to use our software to open files from the commandline.)

Note that this bug is a duplicate of bug 6584897, which was closed as a duplicate of another bug that doesn't even exist in the bug database. Since 6584897 does not appear to be invalid, it does appear to be fairly severe, and it also does not appear to be fixed even in the latest builds, I'm guessing that it probably shouldn't be closed yet.

Also, this bug is really easy to fix; just use GetCommandLineW instead of GetCommandLine, as described in bug 6584897:

http://msdn.microsoft.com/en-us/library/ms683156%28v=vs.85%29.aspx

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See bug 6584897.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should be able to pass unicode characters into java.exe's command line.
ACTUAL -
You cannot pass unicode characters into java.exe's command line.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See bug 6584897.

Or just write a main() method that prints out your args to a utf-8 encoded file or console, and then pass some non-unicode characters into java.exe as args when you run that method.

You can get some examples of non-unicode characters here:

http://translate.google.com/#en|zh-CN|test
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Sadly, the only way to work around this is to start java directly by using java.dll. :(