FULL PRODUCT VERSION :
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)


A DESCRIPTION OF THE PROBLEM :
The java webstart application launch process is two-phased:

The first phase runs javaws, which downloads the application, updates verifies, etc.

The first stage then launches another JVM to run the application - the second stage.

The problem is that the second stage also seems to download, or at least update the cache, for jars that the first stage has already processed.

If you look at the log in the error message section, it does this for every jar, on every launch, even subsequent ones.

I believe the problem is in the CacheEntry.readIndexFile(), in that it is ALWAYS calling saveUpgrade() - something is wrong with the "check" code.

All of our jars are 1.5+ signed, and include timestamps (although the same problem occurs without timestamps).

In an application with lots of jars, this re-writing of the jars is causing EXTREMELY SLOW start-up.

ADDITIONAL REGRESSION INFORMATION: 
It also does not work with jre1.7.0_67.

It works - start-up is instant - if I use jre1.7.0_21 and I remove the java cache before the first start. It is fine on subsequent starts.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
enable logging and tracing and start any java webstart app. You will see that every dependent jar is ALWAYS "upgraded", on every launch.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It may need to upgrade your cache on the first launch, but certainly not if it's empty, or just downloaded.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
network: Cache entry found [url: http://devrt:8088/optionscity/optionscity/metro/filedrop.jar, version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://devrt:8088/optionscity/optionscity/metro/filedrop.jar
cache: registerReference: com.sun.deploy.cache.MemoryCache$CachedResourceReference@2628e91c: 1
cache: registerReference: com.sun.deploy.cache.MemoryCache$CachedResourceReference@2628e91c: 2
security: blacklist: hasBeenModifiedSince 0 (we have 1426275512000)
cache: Trying to update in place /home/rengels/.java/deployment/cache/6.0/45/14c2752d-33924178.idx
cache: Upgrade writing to disk for /home/rengels/.java/deployment/cache/6.0/45/14c2752d-33924178
security: blacklist: check contains UT6O+cMmwfsRuDdAnrilgQvB904IFUjhFDJD44Trlmc=, state now IN_MEMORY
security: blacklist: not  found in cache
security: Trusted libraries list file not found
cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}
cache: Upgrade of entry done
cache: readIndexFile returning success

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
use jre1.7.0_21