CODEWITHSUNDEEP
javajava-7jnlpjava-web-start
Raghavendra
Raghavendra

Reputation: 71

Java WebStart launch fails when a JNLP is fixed to JRE 1.6 and JRE 1.7 is installed

At my company, we download and launch a JNLP application that is tied to a JRE 1.6.0_20. We use the system cache feature to download the JARs.

When we install a JRE 1.7 on the PC, WebStart fails to launch. When we enable 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?

Upvotes: 7

Views: 8568

Answers (3)

r.blooberi
r.blooberi

Reputation: 3

In my case, the following worked to resolve this issue -

I needed to add the '*', which implies that the latest 1.6 JRE found on the machine will be picked up. For some reason, just using '1.6' did not work for me, and 1.7 continued to block the launch.

Upvotes: 0

S&#39;pht&#39;Kr
S&#39;pht&#39;Kr

Reputation: 2839

This may not apply well to your situation, but I found a solution for this for our problem. I modified the JNLP file to specify what 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, the "1.6+" allows for execution under 1.7. So I removed the "+", like so:

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

And now the application works fine. If you can change the JNLP file that gets served via your application URL, that would be best. In our case, that wasn't an option (the JNLP comes from a 3rd party software package), so I downloaded the JNLP, edited it, and now we launch the application by double-clicking the modified .jnlp file (or running the 1.6 javaws.exe on it).

Here is some documentation on the JNLP file format if you need further information.

Upvotes: 1

Mossaddeque Mahmood
Mossaddeque Mahmood

Reputation: 927

This is an installation issue, plugin launch problem for multiple JRE. Reinstall all plugin with updated JRE. See bug database

Upvotes: 1

Related Questions