Starting Java WebStart fails when installing JNLP on JRE 1.6 and JRE 1.7 is installed

Question

At my company, we download and run the JNLP application tied to JRE 1.6.0_20. We use the system cache function to load the JAR.

When we install JRE 1.7 on the PC, WebStart does not start. When we turn on the logs, we see the following exception:

java.lang.ExceptionInInitializerError at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source) at java.net.URL.openConnection(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.createUrlConnection(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source) at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source) at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source) at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source) at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source) at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source) at com.sun.deploy.net.DownloadEngine.getCachedFile(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) Caused by: java.lang.ClassCastException: sun.security.ssl.X509TrustManagerImpl cannot be ast to com.sun.net.ssl.internal.ssl.X509ExtendedTrustManager at com.sun.deploy.security.X509ExtendedDeployTrustManager.<init>(Unknown Source) at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source) ... 16 more 

Is there a known workaround?

Answer 1

This is a setup issue, a plugin launch issue for multiple JREs. Reinstall the entire plugin with the updated version of JRE. See error database

Answer 2

This may affect your situation badly, but I found a solution to this problem. I modified the JNLP file to indicate which JRE to use. In our case, the JNLP file had the following:

 <j2se java-vm-args="-Xmx512m -Dsun.java2d.noddraw=true" version="1.6+"/> 

And, apparently, " 1.6+ " allows you to run up to 1.7. So I deleted the " + ", for example:

 <j2se java-vm-args="-Xmx512m -Dsun.java2d.noddraw=true" version="1.6"/> 

And now the application is working fine. If you can change the JNLP file to be sent via the URL of your application, that would be better. In our case, this was not an option (JNLP comes with a third-party software package), so I downloaded JNLP, edited it, and now we launch the application by double-clicking the .jnlp file (or by running 1.6 javaws.exe on it).

Below is the documentation in JNLP format if you need more information.

Answer 3

In my case, the following worked to solve this problem:

I needed to add "*", which means that it will find the last 1.6 JRE found on the machine. For some reason, just using "1.6" didn't help me, and 1.7 continued to block the launch.