FULL PRODUCT VERSION :
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) Client VM (build 25.31-b07, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.3.9600]

A DESCRIPTION OF THE PROBLEM :
Startup time of applet with many jar files has been increased dramatically. This happens consistently with all version that use the latest plugin (e.g. 1.8.0_31 and 1.7.0_75). It can be reproduced by all our testers and customers consistently. Our enterprise applet is about 25MB in size: every previous version could start it in 4-5 seconds, the new version takes 20-30 seconds.
The error seems to be related to some .idx files being rebuild by the java-plugin. There is no http request from the plugin while the applet tries to start.

REGRESSION. Last worked in version 8u25

ADDITIONAL REGRESSION INFORMATION:
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode, sharing)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Startup time of applet with many jar files has been increased dramatically.
To reproduce just create an applet (anything, doesn't matter), and in the jnlp file add multiple .jar files:
<resources>
        <j2se version="1.6+"/>
        <jar href="TSASignedApplet.jar" main="true" version="1"/>
        
        <jar href="test1.jar" version="1"/>
        <jar href="test2.jar" version="1"/>
        <jar href="test3.jar" version="1"/>
        <jar href="test4.jar" version="1"/>
    </resources>

There is no need for the extra jar files (test1.jar, ...) to be referenced from the actual applet, any set of irrelevant jar files will showcase the problem. Make sure that the test jar files are more than 30MB to clearly notice the problem.

The problem occurs every time with the newest plugin (11.31.2.13). No previous version of the plug-in sufferes from this.

Enabling tracing, show that the delays occur around these lines for each:
cache: Upgrade of entry done
cache: readIndexFile returning success
network: Created version ID: 0123121051
network: Created version ID: 0123120839
security: blacklist: hasBeenModifiedSince 0 (we have 1422007982824)
cache: Trying to update in place C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\13\2f65e68d-6758253c-0123121051-.idx
cache: Upgrade writing to disk for C:\Users\Costas\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\13\2f65e68d-6758253c-0123121051-
security: blacklist: check contains rKQVhGnJ5Kz5RN8dVCJnFWvWeCc=, 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}

Things to notice:
1. The line "security: blacklist: hasBeenModifiedSince 0 (we have 1422007982824)" shows 0: previous versions didn't
2. The line "cache: Trying to update in place..." does not appear in previous version of the plugin
3. It seems that the delay is really at this line: "cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}".


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The applet should start as with every previous version

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
no particular code is needed. The simplest applet will show the problem. The key is to add several large .jar file in the jnlp file (unrelated, no need to be referenced)
---------- END SOURCE ----------

SUPPORT :
YES