System properties defined in applet "java_arguments" parameter are not passed through correctly

NOTE
----
There are Two testcases described below. The second relates to the addendum toward the bottom of this report.

SYNOPSIS
--------
System properties defined in applet "java_arguments" parameter are not passed through correctly

OPERATING SYSTEMS
-----------------
Windows Vista
Windows 7
NOT reproducible on Windows XP

FULL JDK VERSION
----------------
All JDK 7 builds
6u17 onwards (seemingly exposed, but not directly caused, by the fix for 6858117)

PROBLEM DESCRIPTION from LICENSEE
---------------------------------
Some system properties specified using the -D option in the "java_arguments" HTML applet tag parameter are not being passed through correctly on Windows Vista and Windows 7. The problem does not occur on Windows XP.

We discovered this problem while trying to set the jnlp.altCrossDomainXMLFiles system property to define a custom location for a crossdomain.xml file. Contrary to expectations, the value for jnlp.altCrossDomainXMLFiles is not set in the VM process that eventually runs the applet, which prevents the crossdomain.xml from being picked up. The same option is applied correctly under Windows XP and other platforms.

TESTCASE
--------
Attached.

REPRODUCTION INSTRUCTIONS
-------------------------
1. Extract the contents of the attached package
2. Open HelloWorld.html in a browser

Expected behaviour:
The value of the system property jnlp.altCrossDomainXMLFiles should be printed (in the testcase it is given the value "http://www.example.com/crossdomain.xml"). This is the behaviour on Windows XP.

Actual behaviour:
The value of jnlp.altCrossDomainXMLFiles is not printed. (The testcase prints the value of java.version is instead, upon finding that jnlp.altCrossDomainXMLFiles is null). This is the behaviour on Windows Vista/7.

ADDENDUM from LICENSEE
----------------------
There is more to this issue than we first thought. The overall handling of the "java_arguments" parameter seems to be incorrect, in that it does not behave in accordance with the documentation.

The documentation states:

- Any applet parameters specified using the <param> tag are merged with those specified in the JNLP file. If the same parameter is specified via both the <applet> tag and the JNLP file, the <applet> tag's version overrides the JNLP file's version, except for the java_arguments and java_version parameters.

- The new java_arguments and java_version parameters are unnecessary in JNLP applets. The mechanisms in the JNLP file for requesting a JRE version, or passing command-line arguments to the JVM, are used instead. Command-line arguments and JRE version requests from the JNLP file override those specified in the HTML for the applet.

This isn't 100% clear, but it seems that if java_arguments is set in the HTML applet tag, *and* java-vm-args is set in the jnlp file, the plugin should only pick up the arguments from the java-vm-args parameter in the jnlp, and ignore the contents of the java_arguments parameter in the HTML file.

We created a simple testcase where we specify two arguments in the java_arguments HTML parameter, and one in the jnlp java-vm-args parameter. In this case, contrary to expectations, the plugin runs with the java_arguments (see attached testcase). However, if we specify two different properties in java_arguments and java-vm-args, the VM runs as expected, with only the arguments specified in java-vm-args (recreate this by removing the "-Djnlp.altCrossDomainXMLFiles" property from the java_arguments parameter in the HTML file). This inconsistent behaviour can be seen on XP as well as Windows 7/2008.

The original issue and this issue both seem to be caused by the way in which the plugin handles the JVM options presented in these two parameters. The problem involves the way the isDefault variable is set in JVMParameters.java, and then how it is used in the satisfies() method. It is very likely that there are other scenarios in which this code does not behave as expected.