JDK-8144005 : JnlpxArgs NullPointerException
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u65
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2015-11-24
  • Updated: 2016-11-03
  • Resolved: 2016-11-03
Related Reports
Relates :  
java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

Microsoft Windows 7 Ultimate 64bit
Microsoft Windows [Version 6.1.7601]

We randomly receive the following NPE when launching an installed webstart application from a shortcut:

	at com.sun.javaws.JnlpxArgs.execProgram(Unknown Source)
	at com.sun.javaws.Launcher.relaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
	at com.sun.javaws.Launcher.prepareToLaunch(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)

Cannot use secure launcher with main class: B 
#### Java Web Start Error:
#### null

Once we receive this exception, further attempts to re-launch continue to fail. 

The ways to recover we have found so far are:
1) Re-download the jnlp from the website, but this seems to only work for that run
2) Remove the application from the Java control panel and re-download jnlp
3) Toggling certain options in the control panel like 'Enable logging' 'Enable trace' cause it to work a few times, then fails.

When it fails, the error message always complains about a class that does not exist, for example 'B'. 
Sometimes it tries to use a random snippet of the java args in our jnlp file as the classname.

I wanted to attach a debugger to see where the corruption was taking place, but first tried launching the failing app from the cmd line.
Once I was able to consistently get the NPE, I opened up a cmd window and pasted the shortcut target and ran... and it ran fine. 
Double clicking the shortcut continued to fail.

Upon further investigation of what javaws.Main/Launcher is doing, appears the args that are passed are corrupt, at least the value of -Djnlpx.vmargs. 
This is a base64 string of the args used in the jnlp file, but sometimes the values when decoded result in garbage chars. 
The code that parses the classname out of the cmd string returns early because of these and results in the NPE.

An example good run has the following args:
sun.java.command=com.sun.javaws.Main -secure -notWebJava C:\Users\swerner\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\1\143a1481-774eee27

And a bad run:
sun.java.command=com.sun.javaws.Main -notWebJava C:\Users\swerner\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\1\143a1481-774eee27

(I removed args that appeared in both or really have nothing to do with this issue)

In a good run the args are decoded as:

And in a bad run, one time it was decoded as:

So to sum up:
1) Same cmd line executed in shell works, fails in shortcut
2) When fails, -Djnlpx.vmargs appears truncated and does not decode correctly, resulting in the reported NPE

Not sure how to get it to actually fail, but happens a lot to myself and many of our clients. Didn't really notice it till moving to Java 8.

This bug can be reproduced always.

The ways to recover we have found so far are:
1) Re-download the jnlp from the website, but this seems to only work for that run
2) Remove the application from the Java control panel and re-download jnlp
3) Toggling certain options in the control panel like 'Enable logging' 'Enable trace' cause it to work a few times, then fails.

Closing this as Cannot Reproduce, based upon update from the submitter: "I haven't seen this error in a while and none of our users are reporting it anymore, so believe it can be closed. I thought I saw a release with a bug description in the area, but couldn't tell you which one it was anymore, been a while. The issue I had been seeing was the jnlp launcher would write out some secure jnlp args, and in some cases re-running the app it would read them in corrupted, then pass to the parser which would NPE. That area was closed src, so wasn't really able to debug much further. It was always re-producible on my machine but my co-workers never failed".

but JDK-8079347 was fixed in 8u40 and this is filed against 8u65, however I also cannot reproduce with 8u65 or later. Closing for now as incomplete pending reproducible testcase.

Checked this for JDK 8u65, 8u66 b18, and 9 ea b93 and couldn't reproduce the issue as reported. Run, https://portal.enfusionsystems.com/launcher/launcher.jnlp and the application launches fine through cmd line as well as shortcut. Note: Delete cache after every iteration. This looks like a duplicate of JDK-8064358.