FULL PRODUCT VERSION :
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Version 6.1.7601

A DESCRIPTION OF THE PROBLEM :
We have an application that deploys through Webstart, with a JNLP in the main application jar, using "*" placeholders for arguments. All app jars are signed.

The dynamically generated JNLP has matching argument elements, but is passing accented characters in one of them. For example: (in UTF-8) "??qu???".

It appears that webstart is detecting that the JNLP is signed, which is correct but this causes a relaunch of webstart. When the restart is done, webstart has crafted a JNLP but the argument is now: "???qu????".

It has read the source JNLP using "windows-1252", and used that charset in emitting the new JNLP. This causes the application to get incorrect data as an argument, and it malfunctions because of it.

If one forces UTF-8, such as:

javaws -J-Dfile.encoding=UTF-8 xx.jnlp

the application successfully runs (ensure that the cache is empty for testing, since after it has been tried (good or bad) created JNLP is now in the cache).

This can also be worked around for launches of the JNLP file type through the File Explorer, by editing the windows registry, setting the (Default) of the HKEY_CLASSES_ROOT\JNLPFile\Shell\Open\Command to:

"C:\Program Files (x86)\Java\jre7\bin\javaws.exe" "-J-Dfile.encoding=UTF-8" "%1"

This also permits success launching through Internet Explorer, apparently through Firefox, but this has not been highly tested, on all browsers, nor is editing the registry an appropriate workaround for a large distributed customer set. However, it does demonstrate that if you can find in the webstart code, where it is not reading as the correct dataset, the problem could be resolved.

In reality webstart should grab the argument, according to the encoding specified in the JNLP header, and write the new JNLP to the cache with the same encoding.

Currently we can run the application without signing the JNLP, but put up with the warning dialogs. However, when you make JNLP signing mandatory, applications that have to pass non-ISO-8859-1 type arguments will fail, with no well accepted workaround.

REGRESSION.  Last worked in version 6u45

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. create a trivial webstart launched application, that simply prints its command-line, such as:

        for (char c : args[0].toCharArray()) {
            System.out.print((int) c + " ");
        }
        System.out.println();
        System.out.println(Arrays.deepToString(args));

2. craft a JNLP for the app, with an <argument> with an accented string

3. put a copy of the JNLP with the argument as a * into the main application jar, so that it is signed (following the 5.4.1 section of: file:///C:/Users/tomoke/Desktop/javawsSpec7/7.0/launch.html#signed)

4. launch the application through javaws

It will show you the wrong encoding for the argument, using the default Charset for it, rather than the JNLP's specified encoding.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The argument is correctly passed from the supplied JNLP through to the application.
ACTUAL -
The argument was incorrect

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
As noted above, launching javaws with -J-Dfile.encoding=UTF-8 and editing the registry worked around the problem.