P4
FULL PRODUCT VERSION :
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
I have also confirmed this bug on Mac OS X Version 10.5.8 with the latest JRE and Web Start.
A DESCRIPTION OF THE PROBLEM :
A JNLP file can contain zero or more <argument> tags like shown below.
<jnlp ...>
<application-desc main-class="...">
<argument>firstArg</argument>
<argument>secondArg</argument>
</application-desc>
</jnlp>
The content of each <argument> tag is suppose to be passed to the main method of the class specified in <application-desc main-class="...">. However, if a new application JAR file is downloaded, Web Start does not pass these arguments to the main method. Instead main is called with args.length equal to 0.
Subsequent launches of the JNLP application will get the arguments until the application's JAR file is updated and downloaded again.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a simple class that echos the main method's arguments.
2. Build a JAR file for that class and deploy on a web server.
3. Write a JNLP file that contains application arguments as described in the "Description" section of this bug report.
4. In a web browser, download the JNLP file by typing it's URL into the address bar and pressing [ENTER].
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application JAR file is downloaded. The application's main class's main method is invoked with the arguments specified in the JNLP file.
ACTUAL -
The application JAR file is downloaded. The application's main class's main method is invoked with zero arguments.
An attempt to download the JNLP file a second time will launch the application with the correct parameters. However, if the application's JAR file is updated on the server, the next launch of the application will fail to get the application parameters.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
N/A. This is a runtime problem, but no exception is generated. I suspect that there is logic in the Web Start application launcher that is simply skipping the JNLP application argument processing when an application JAR file is downloaded. The fix might be as simple as moving a block of code into or out of an IF statement.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public static void main (String [] args)
{
System.out.println("args.length = " = args.length);
for (String arg : args)
System.out.println("[" + arg + "]");
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There are two possible workarounds, neither particularly good. One workaround is to close the JNLP application and relaunching it using the same link that launched it before. The problem with this workaround is that most users will not know to do this and may not even notice that the application failed to launch with the proper information.
The second workaround is to find and extract the application arguments from the JNLP file. This is the workaround I took. However, the location of the JNLP file is OS-specific. On Windows XP, the JNLP file is downloaded to System.getProperty("java.io.tmpdir"). On Max OS X, the JNLP file is downloaded to System.getProperty("user.home") + "/Downloads". I have not checked where the JNLP is downloaded to under Solaris, Linux, or any mobile platform.
Furthermore, it is possible that the download location for JNLP files could change from one release of an OS to another. As such, this is not a stable workaround.
Also, if anyone uses this workaround, it is necessary to make sure that you do not extract arguments from a JNLP file if the JNLP application was launched from a shortcut instead of from a JNLP file link. The way I accomplish this is by marking the downloaded JNLP file after extracting parameters by appending "[consumed]" to it. This breaks the JNLP file structure, but at that time the JNLP file is no longer needed.
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
Java HotSpot(TM) Client VM (build 14.1-b02, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
I have also confirmed this bug on Mac OS X Version 10.5.8 with the latest JRE and Web Start.
A DESCRIPTION OF THE PROBLEM :
A JNLP file can contain zero or more <argument> tags like shown below.
<jnlp ...>
<application-desc main-class="...">
<argument>firstArg</argument>
<argument>secondArg</argument>
</application-desc>
</jnlp>
The content of each <argument> tag is suppose to be passed to the main method of the class specified in <application-desc main-class="...">. However, if a new application JAR file is downloaded, Web Start does not pass these arguments to the main method. Instead main is called with args.length equal to 0.
Subsequent launches of the JNLP application will get the arguments until the application's JAR file is updated and downloaded again.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a simple class that echos the main method's arguments.
2. Build a JAR file for that class and deploy on a web server.
3. Write a JNLP file that contains application arguments as described in the "Description" section of this bug report.
4. In a web browser, download the JNLP file by typing it's URL into the address bar and pressing [ENTER].
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application JAR file is downloaded. The application's main class's main method is invoked with the arguments specified in the JNLP file.
ACTUAL -
The application JAR file is downloaded. The application's main class's main method is invoked with zero arguments.
An attempt to download the JNLP file a second time will launch the application with the correct parameters. However, if the application's JAR file is updated on the server, the next launch of the application will fail to get the application parameters.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
N/A. This is a runtime problem, but no exception is generated. I suspect that there is logic in the Web Start application launcher that is simply skipping the JNLP application argument processing when an application JAR file is downloaded. The fix might be as simple as moving a block of code into or out of an IF statement.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public static void main (String [] args)
{
System.out.println("args.length = " = args.length);
for (String arg : args)
System.out.println("[" + arg + "]");
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There are two possible workarounds, neither particularly good. One workaround is to close the JNLP application and relaunching it using the same link that launched it before. The problem with this workaround is that most users will not know to do this and may not even notice that the application failed to launch with the proper information.
The second workaround is to find and extract the application arguments from the JNLP file. This is the workaround I took. However, the location of the JNLP file is OS-specific. On Windows XP, the JNLP file is downloaded to System.getProperty("java.io.tmpdir"). On Max OS X, the JNLP file is downloaded to System.getProperty("user.home") + "/Downloads". I have not checked where the JNLP is downloaded to under Solaris, Linux, or any mobile platform.
Furthermore, it is possible that the download location for JNLP files could change from one release of an OS to another. As such, this is not a stable workaround.
Also, if anyone uses this workaround, it is necessary to make sure that you do not extract arguments from a JNLP file if the JNLP application was launched from a shortcut instead of from a JNLP file link. The way I accomplish this is by marking the downloaded JNLP file after extracting parameters by appending "[consumed]" to it. This breaks the JNLP file structure, but at that time the JNLP file is no longer needed.