JDK-6676879 : Nightly: Javaws Basic acceptans test (BAT.jnlp) failed on UNIX platforms in nightly build
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2008-03-18
  • Updated: 2010-09-08
  • Resolved: 2008-06-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b21Fixed
Related Reports
Relates :  
JDK-6678865 - Long command lines or applet parameter lists break new plug-in on Windows
Relates :  
JDK-6678860 - Nightly: Javaws Unix native launcher selects wrong JRE out of deployment.properties
Description
Javaws Basic acceptance test (BAT.jnlp) failed on UNIX platforms in nightly build

How to reproduce:
 - install jre1.6.0_10 promoted build 13 (jre1.6.0_10_prom)
 - install jre1.6.0_10 latest nightly (jre1.6.0_10_nightly)
 - run first jre1.6.0_10_prom/bin/javaws http://nicole1.sfbay.sun.com:8080/JavawsMustangIntegTest/hellojaws/BAT.jnlp
 - now run jre1.6.0_10_nightly/bin/javaws http://nicole1.sfbay.sun.com:8080/JavawsMustangIntegTest/hellojaws/BAT.jnlp
Application is not launching with an Exception coming:
java.lang.NullPointerException
at com.sun.javaws.DefaultMatchJRE.endTraversal(Unknown Source)
at com.sun.javaws.LaunchSelection.selectJRE(Unknown Source)
at com.sun.javaws.jnl.LaunchDesc.selectJRE(Unknown Source)
at com.sun.javaws.jnl.LaunchDesc.<init>(Unknown Source)
at com.sun.javaws.jnl.XMLFormat.parse(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Also I noticed difference in the way how application launching now:
Before (latest promoted jre) - after splash screen it is launched almost immediately.
Now - after splash you can see "Downloading application" window, then 
"Launching application" window , then again "Downloading application" 
window and "Launching application" window and finally application launched.

hellojaws.jar is not signed, no vm-args, only one property - jnlp.TESTNAME (see below):

<?xml version="1.0" encoding="utf-8"?>
<!-- @(#)BAT.jnlp	1.10 07/09/06 -->
<jnlp codebase="$$codebase">
  <information>
    <title>Java Web Start Test Case -- BAT</title>
    <vendor>Sun Microsystems, Inc.</vendor>
    <homepage href="homepage.html"/>
    <description>Basic Acceptance Test</description>
    <description kind="one-line">This test is 
        used for basic acceptance test for Java Web Start.</description>
    <description kind="tooltip">Not worth to run it again.</description>
    <description kind="short">A boring test.</description>
    <icon kind="default" href="images/Button_Default.jpg"/>
    <icon kind="disabled" href="images/Button_Disabled.jpg"/>
    <icon kind="selected" href="images/Button_Selected.jpg"/>
    <icon kind="rollover" href="images/Button_Rollover.jpg"/>
  </information>
  <resources>
    <j2se version="1.2+"/>
    <jar href="jar/hellojaws.jar"/>
    <property name="jnlp.TESTNAME" value="BAT_TEST"/>
  </resources>
  <application-desc main-class="hellojaws"/>
</jnlp>
Comments
SUGGESTED FIX JAVAWS native launcher: - If sysGetRegistryJREs()'s single product_version == NULL, we are running the Unix implementation of a fake registry. In this case: - JRE matches regardless of the product_version - SetJRERegistered -> "false" This shall allow to find the running JRE (returned by sysGetRegistryJREs) within the user properties. This will also allow to write the JRE entries back to the user properties (registered:=false) - Add jnlfile->auxProps to java_arg_addAux as well, to make 'em visible to JAVAWS Launcher.java. This removes the unnecessary relaunch for secure arguments. - All properties, the auxProps and the 'jnlpx.*' properties needs proper quoting, depending on the running OS. Windows: "-Dlala=la la" "-Djnlpx.vmargs=-client \"-Dlala=la la\"" Unix: -Dlala=\"la la" -Djnlpx.vmargs="-client -Dlala=\"la la\"" - sprintf -> snprintf, where we abstract snprintf as sysStrNPrintF, implemented using vsnprintf (POSIX/ANSI) and _vsnprintf (Windows). - Restrict command line size Win2k/NT4 maximum: 2047 Posix/Unix: 4095 Implemented in JVMParameters, used by - JAVAWS launcher - OOPP JVMLauncher FIXME: Currently OOPP's client JVM is confused with incoming messages, if command line size > 2047. This must be due to a bug within the Serializer implementation. Therefor we restrict the command line size to 2047 (like Windows) until this bug is fixed. +++ Exception cleanup: com.sun.javaws.jnl.ResourcesDesc.visitPackageElements(..) - catched case where extensionDesc==null. +++ testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6676879/ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6676879.2 workspace: deploy engineer: sven.gothel
21-03-2008
SUGGESTED FIX JAVAWS native launcher: - Always store JRE entries, if they come from the user's property file - Ignore ProductVersion==NULL as a criteria for matching JRE in RescanJREs, else the sysGetRegistryJREs will be added each run. - Add jnlfile->auxProps to java_arg_addAux as well, to make 'em visible to JAVAWS Launcher.java. This removes the unnecessary relaunch for secure arguments. - The auxProps needs proper quoting, depending on the running OS. Windows: "-Dlala=la la" Unix: -Dlala=\"la la" For both, the property passing itself, and the embedded 'jnlpx.vmargs'
19-03-2008
EVALUATION The native launcher's DetermineVersion() pciks the first matching one, in our case 'jre1.6.0_10_prom', even though it was started using 'jre1.6.0_10_nightly'. If we have 2 concurrent version (which is our case here), it shall try to match sysGetApplicationHome() with the path, which should be the desired JRE. The root cause is, that the 'jre1.6.0_10_prom' is removed from the properties. This disables us to find the java.home JRE in the properties.
19-03-2008
EVALUATION JREInfo.getJREHome() is null in this error case. The first JAVAWS run using 'jre1.6.0_10_prom' add's 'jre1.6.0_10_prom' to the JRE properties. The second JAVAWS run using 'jre1.6.0_10_nightly' will launch (through the native launcher.c) 'jre1.6.0_10_prom', i.e.: jnlpx.jvm='jre1.6.0_10_prom' jnlpx.home='jre1.6.0_10_nightly' 'java.home' is therefore 'jre1.6.0_10_prom', but Config.refreshProps() doesn't register 'jre1.6.0_10_prom' anymore, and therefor JREInfo.getJREHome() can't find it and returns NULL.
19-03-2008