java 8u31插件导致签名的applet加载速度慢得多

Question

i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.

To reproduce the issue i did this: I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (eg 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....

Has anyone else seen something like that?

It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.

I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help, TIA

Answer 1

Same here. I thought already I'm getting crazy. Thanks for sharing this.

We are using Java Web Start, but it's sharing the same problem of re-indexing all jar files (in our case it's an app with quite some jars, so starting takes ages).

Aside from the fact that Oracle suddenly decided to check the certificate of the deploy TLS, which caused some hickup on Linux and Macs (we used a StartSSL certificate there, which isn't included in the Java keystore - on Windows it works as it uses the platforms root certs, too).

And, to make it even worse, on Windows x86 the 8u31 silently dies if -XX:+DoEscapeAnalysis or -XX:+OptimizeStringConcat is present in the JVM arguments, though both parameters are standard in Java 8 (but not in 7, that's why they've been included, still). The 64bit engine doesn't have that problem.

The next thing they changed is they now overwrite the start icons if they've been changed (we changed them to put the 64bit engine's path in there), so it stubbornly changes the path back to the 32bit engine every time.

The behaviour of Oracle is not helpful at all, as they didn't announce any of these changes in their changelogs, let alone announcing the certs changes a few days ahead.

I would like to hear from anyone who's sharing the problems and possible workarounds.

Patric

Answer 2

Have you been able to solve this issue? Have you had a reaction from Oracle?

UPDATE START

• I've tried everything I can think of and haven't managed to solve the issue, so I posted my own question on this issue .

• A similar bug report can be found here and is backported to at least Java 8u51 which I tested. Yet again they managed to increase startup time for our application.

END UPDATE

We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed. Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:

• 7u?? (<60): +2s (10s)
• 7u60: +5s (13s)
• 7u75: +15s (23s)
• 8u31: +12s (20s)
• 8u40: +21s (29s)
• 8u51: +23s (31s)

Answer 3

Have you tried your jnlp without versioning? In my experience Java jnlp is very buggy specially if you change the jnlp default values. Versioning support is disabled by support, so try it without versioning and see if it still slow?

For me, I noticed some bugs when I used update="background" value, so I no longer change the default update method. My theory is that Oracle only tests jnlp against default values before they release new Java versions.