Changed how JNLP-launched applets both detect the need for a relaunch
due to mismatched command-line arguments, and pass command-line
argument requests back to the browser during relaunches.
Now, instead of adding any additional system properties to the command
line, they are simply added to the parameter map in the
StartAppletMessage as the java_arguments parameter. This allows the
existing browser-side code to work unmodified. Issues like multiple
JVM instances being spawned for multiple runs of the same JNLP applet
are transparently fixed with this change.
The current JVM's command-line arguments are passed to the
JNLP2Manager via a JVMParameters object directly from PluginMain. The
preexisting mechanism for passing these command-line arguments from
the browser side to the client JVM, which was previously necessary to
determine whether the client JVM instance was secure, is reused.
The use of the JnlpxArgs class in the new plug-in was eliminated. It
is not applicable in its current form.
The system property javaplugin.vm.options was added, mainly as an aid
for testing. Permission was granted to read this system property from
unsigned applets, though this may need to be changed in the future.
The appletJRERelaunch method on Applet2Listener was changed to remove
the JREDesc argument and to instead take the requested Java version as
a String. The -Xmx and -Xms parameters are fabricated as command-line
arguments within the JNLP2Manager during the relaunch process to hide
complexity and reduce the number of places in the code that need to
know about the JREDesc class.
This work uncovered several preexisting bugs in the new plug-in, such
as the JVMParameters class losing the -Xmx specification when
serialized from the server to the client side. Other refactorings such
as the introduction of the ArgUtil class and a renaming of the
PropertyNames class to ParameterNames were also done. Javadoc in the
JREDesc class was corrected. Some minor cleanups to tests written by
###@###.### were also made.
More work is needed. JRE version selection via JNLP files is not yet
implemented. The notion of the JRE's path, and matches against it in
the JNLP2Manager's launch mechanism, needs to be completely
eliminated. Auto-download support is also not yet implemented.