Java 8u31 plug-ins cause signed applets to load much more slowly

I've noticed that signed applets load much slower with the latest plug-ins (included in Java 8u31 and 7u75) I have debugged many cases and found that the problem is directly related to the size of the jar file referenced in the JNLP file The problem is that every time the applet starts, the cached jar files will be "re indexed", which takes time

To reproduce the problem I did this: I created a minimal applet, and in the JNLP file I used to deploy it, I added a fairly large (e.g. 30MB) number of unrelated Jar files (not even referenced, so the classloader doesn't load them) Of course, I am using version control in JNLP and capturing all HTTP traffic to ensure that the delay is not due to traffic (re download or certificate revocation check, etc.) I run the applet to enable tracing, then trace the log file through XML and find out where the delay arrives: they are always from jarsigningverifier

Has anyone seen such a thing?

It's very easy to see and reproduce this behavior, and I wonder if there's something I overlook In the past few years, after working extensively on applets, I completely lost what could happen I can verify that the plug-in restored to the previous version (and every other previous version) works as expected

I have submitted the error report of Oracle, but I haven't heard it yet Any information or ideas will help, TIA

Solution

Also here I thought I was crazy. Thank you for sharing this content

We are using Java Web start, but it shares the same problem and re indexes all jar files (in our example, it is an application with quite a few jars, so it needs age at first)

In addition to Oracle's sudden decision to check the certificate for deploying TLS, this led to some errors on Linux and MAC (we used the startssl certificate not included in the Java keystore on windows, because it uses the platform at all)

Moreover, in order to make it worse, on Windows x86, if - XX: doescapeanalysis or - XX: optimizestringconcat exists in the JVM parameter, 8u31 will crash silently, although both parameters are standard in Java 8 (but not in 7. They have been listed and still exist) The 64 - bit engine does not have this problem

The next thing they change is now. If they have changed, they will overwrite the start icon (we changed them to put the path of the 64 bit engine there), so it will change the path back to the 32-bit engine every time

Oracle's behavior did not help at all because they did not publish any of these changes in their update log, let alone announce certificate changes in the next few days

I want to hear from anyone who shares problems and possible solutions

Patrick