JDK-8210038 : JNLP 'arch' attribute fails with NPE in SingleInstanceServiceImpl
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u181
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2018-08-24
  • Updated: 2019-03-19
  • Resolved: 2018-09-05
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 8
8u202 b01Fixed
Related Reports
Relates :  
JDK-8182548 - Release Note: Set 32 or 64 bit JRE requirements in a JNLP file
Relates :  
JDK-8210262 - jar resource may be required in both archetectures
Relates :  
JDK-8210261 - Web Start cannot handle 'x86_64' in arch attribute
Description
ADDITIONAL SYSTEM INFORMATION :
Dell 
Intel Core i7-6820HQ @2.7Ghz
Microsoft Windows [Version 6.1.7601] / Windows 7 enterprise SP1
Java1.8u181 i586
Java1.8u181 x64

A DESCRIPTION OF THE PROBLEM :
Since JDK-8182548, the "arch" can specify 'in order' which jvm archtecture to select.
Basically i require an x64 VM to run my app using webstart because of memory usage. 
With both 1.8u181 i586 and x64 installed (as per JDK-8182548) on windows 7.
My JNLP settings were arch="x86_64" and on a separate testrun arch="amd64"
It never runs 64bit.
Whith arch="x86_64" the trace file states:

Log started: Fri, 24 Aug 2018 16:13:28 +0200
Java Web Start 11.181.2.13
Using JRE version
 1.8.0_181-b13 Java HotSpot(TM) Client VM
java.lang.NullPointerException
	at com.sun.jnlp.SingleInstanceServiceImpl.getIDString(Unknown Source)
	at com.sun.javaws.Launcher.launch(Unknown Source)
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main.access$000(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

(with   arch="x86"   the or omitting the arch  attribute, the JVM does start, but in the 32bit VM)

REGRESSION : Last worked in version 8u181

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
install both 1.8u181  64 and 32 bit
run jnlp file with one(or multiple) resource sets, where 'arch' is either "x86_64" or "amd64"
the popup [Java...] appears and dissapears after long.
The trace file shows it encountered a nullpointer.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application running on a  JVM x64 
ACTUAL -
The launcher terminates with a nullpointer.

---------- BEGIN SOURCE ----------
<?xml version="1.0" encoding="utf-8"?>

<jnlp spec="1.0+" codebase="https://localhost:8443/">
  <information>
    <title>a</title>
    <vendor>b</vendor>
    <homepage href="https://localhost:8443/index.html"/>
    <description>c</description>
    <offline-allowed/>
  </information>
  
  <security>
    <all-permissions/>
  </security>
 
  <resources  arch="x86_64">
    <property name="jnlp.versionEnabled" value="true"/>  
    <j2se version="1.8*" initial-heap-size="128M" max-heap-size="512M" java-vm-args="-Dsun.java2d.d3d=false"/>
    <property name="java.util.Arrays.useLegacyMergeSort" value="true"/>
    <jar href="https://localhost:8443/lib/a.jar" version="10.03.0000" main="true"/>
    <jar href="https://localhost:8443/lib/b.jar" version="10.03.0000"/>
    <jar href="https://localhost:8443/lib/c.jar" version="10.03.0000"/>
    <jar href="https://localhost:8443/lib/d.jar" version="10.03.0000"/>
  </resources>  
 
  <application-desc main-class="x.y.z">
    <argument>-host</argument>     <argument>localhost</argument>
    <argument>-port</argument>     <argument>8443</argument>
    <argument>-secure</argument>   <argument>true</argument>
  </application-desc>
</jnlp>
---------- END SOURCE ----------

FREQUENCY : always
Comments
I am splitting this up into three bugs. JDK-8210038 (This one) - is now just about the NPE which is a regression. JDK-8210262 - covers the existing case where resources are required for both architectures JDK-8210261 - covers the existing case where only 'amd64' works as the arch value for specifying 64 bit arch. Fixing this bug will allow the "proper" error message to be shown.
31-08-2018
the problem just moves down the line when SingleInstanceImpl is fixed. This is not a regression. Main line launcher code has always expected jnlp file to have at least some resources else LaunchDescException with "launch.error.noappresources" String is thrown. Trying to move that assumption and check to after relaunch is problematic, and may not be desirable.
28-08-2018
The work-around applies, but the underlying problem is that LaunchDesc.getCanonicalHome() returns null, the exception is in getHomeString(). If there is no jnlp href, then the url of the main jar is used, but in this case there is no main jar either without the work-around (before relaunching into 64 bit)
28-08-2018
the problem is likely: String session = rds.getResourceProperties(). getProperty(LaunchDesc.SIS_SESSION_PROPERTY); although res is not null, there are no resources when running in 32 bit (before relaunch) so rds.getResourceProperties(), causing NPE. possible work-arround: add a non qualified resources block to the jnlp with a jar in it like: <resources> <jar href="hello.jar"/> </resources> then it will relaunch properly using the first resource block with the arch="amd64" this case works: <jnlp codebase="http:/mysite.com/64/hello" > <information> <title>Hello Java Web Start</title> <vendor>Bat Test</vendor> </information> <resources arch="amd64"> <j2se version="1.7+" href="http://java.sun.com/products/autodl/j2se"/> <jar href="hello.jar" /> </resources> <resources> <jar href="hello.jar"/> </resources> <application-desc main-class="hello"/> the drawback here is that on system with out 64 bit java installed, it will launch hello.jar in 32 bit mode, perhaps enhanced work-around would be to use a different jar who's main class just reported that 64 bit java is required to run this app. anyway - I will fix in 8u202.
28-08-2018
OK - now I can reproduce with simple local testcase - when jnlp file has no href I get the NPE in SingleInstanceServiceImpl.getIDString() as above. The attachment is not a valid test because it is a modified jnlp file (to have the arch attribute) but it has an href, which points back to the unmodified jnlp file - which is the jnlp file that runs, thus it runs in 32 bit. but simply by removing the jnlp href in the attached jnlp file the problem can be shown.
28-08-2018
OK - still cannot reproduce. I have 64 and 32 bit 8u181 installed and 64 bit 7u201 installed and can launch webstart from 32 bit 8u181 and it will run si app with 7u201 and get newActivations when I launch it another time. First launch is always with 32 bit 8u181, and it properly relaunches to 64 bit 7u201
28-08-2018
oddly - trying same as above with single instance enabled app also worked fine (using "amd64") in my case I am just relaunching from 8u181 32 bit to 8u181 64 bit. will try the same thing with 64 bit 7u and app requesting to use that
28-08-2018
I tried the same thing as above except using "x86_64" (as Pardeep used above) and it failed. I am not sure why amd64 works but x86_64 does not but that is a separate problem. I will now try with an app that utilizes the single instance service
28-08-2018
NPE from SingleInstanceServiceImpl.getIDString() - likely a regression caused by JDK-8185002 or related SingleInstance enhancements in 8u172 (now in 8u181). Testing first with simple non-SI app below requesting 64 bit (with both 32 and 64 bit 8u181 installed: <jnlp codebase="http://my-site.com/test/hello" href="hello64.jnlp"> <information> <title>Hello Java Web Start</title> <vendor>Bat Test</vendor> <offline-allowed/> <shortcut> </shortcut> </information> <resources arch="amd64"> <jar href="hello.jar" /> <j2se version="1.8"/> </resources> <application-desc main-class="hello"/> </jnlp> This works fine - begins in 32-bit 8u181 and relaunches into 64 bit 8u181 to run the app
28-08-2018
As per JDK-8182548, the Web Start applications can specify requested JREs with their arch attributes, and select the first one available that matches, even if it is not the same arch (32 bit vs 64 bit) as the currently running JRE. However, according to submitter his application has arch=x86_64 or amd64 specified, yet it fails to run with 64 bits. ======================================================== Checked this with JDK 8u191 and could confirm following: With arch="x86_64" and arch="amd64" the jnlp get loaded with 32-bit version when both 32-bit and 64-bit versions are installed. To verify, run attached jnlp with respective java version. Not sure about the concern as per JDK-8182548, In order to launch a 64 bit 1.8 JRE, a 64 bit 9 JRE must be installed. If only a 32 bit 9 JRE is installed, the 64 bit 1.8 JRE is unavailable.
28-08-2018