Long startup delay for Java WebStart application since Java 1.7.0u40
This occurred with the version 1.8.0_221 as well in the web start application. I have done it and the problem that i found was that each time the webstart application was being downloaded and wasn't loading from the cache. Here are a few changes that i made in the deployment.properties file I added these two thing in it
deployment.security.tls.revocation.check=NO_CHECK deployment.security.revocation.check=NO_CHECK
deployment.security.mixcode=DISABLE
You can change these settings from the configure java gui tool as well In the jnlp file i changed these two things 1. changed the update check setting to background from always 2. Increased the heap size from 128 and 256 respectively
<update check="background"/>
<j2se version="1.8+" initial-heap-size="256m" max-heap-size="512m"/>
Then i went to the command prompt and typed these
javaws -import -system -shortcut jnlp.jnlp
javaws -system -Xnosplash -wait jnlp.jnlp
The first command imports the jnlp into the system cache and the second one forces the jnlp to be run from the system cache rather that from the application one or by downloading it first.
To be safe run this command first to clear the non installed applications from the cache as well
javaws -clearcache
This has greatly minimized the time but it still takes 4 mins to open the application. But before that it was taking more than 15 so it's a big improvement. This is an extension to Micheal B's answer
I have experienced this problem and it was because of the certificate revocation checks enforced by default. Disable that (advanced tab => Perform certificate revocation checks on") and it should be fine !
Yes, atulsm's answer gave the right kick. But read on: I tried to follow the hint, but it did not look good since in the Java Control Panel the entry already was disabled (the tick was not set). Setting it resulted in the tickmark being only shown temporarily (as soon as a the WebStart application was executed and terminated again, the setting went back to not selected), so it seems as if the setting is not properly written into Java's config file.
FINALLY: I checked the Deployment Configuration File and set deployment.security.revocation.check=NO_CHECK
manually in the deployment properties. That did solve the problem!