United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6663089 Issues with system property and JVM command-line argument specification to applets via JNLP
JDK-6663089 : Issues with system property and JVM command-line argument specification to applets via JNLP

Details
Type:
Bug
Submit Date:
2008-02-14
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-03-25
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b13)

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

Description
This is a follow-on bug for the work done for re-launching an applet specified via JNLP in 6662404. Issues that need to be fixed:

 - If system properties are specified in the JNLP file, and the same applet is visited multiple times, multiple JVM instances are being launched because apparently we are unable to detect that a previously-launched JVM instance satisfies the new applet's command-line argument request.

 - Passing arbitrary JVM command-line arguments is not currently working.

                                    

Comments
EVALUATION

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.
                                     
2008-02-14
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u10/6663089.1
                                     
2008-02-14



Hardware and Software, Engineered to Work Together