java 8u31 plugin causes signed applets to load much slower

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 (e.g. 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

Vida

have you fixed your issue yet? I tried with Java 8u51 which supposedly had a backport of Oracle's bugfix, but it still seems the jar verification takes about 20 seconds (on a very fast developer pc). – Kuibyshev

We went we getitdown instead of jnlp. Yet, in some internal tests we did, it seems that the new version does fix the problem. Yet the damage has already been done.... – Vida

I've tried everything I can think of and still haven't solved the issue, so I posted this question: #31569127 In the meantime I am also abandoning Java Web Start. I will create my own update script that works over our company's LAN which does a simple version check and simply copyies the files from a network share. – Kuibyshev

The good thing with getitdown is that you don't need to sign the jar files and you don't need to verify them on startup. You only need to sign the getdown applet which is very small. – Vida

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

Shedevil

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)

Kuibyshev

We will be switching to getdown (github.com/threerings/getdown). I have been working with it and it seems like a great alternative. Although it bootstraps with JWS, the rest of it is really fast – Vida

Thank you, I tried it out and starts up pretty fast after downloading. I will probably wait until July/August and check if this issue is fixed but will definitely consider getdown. Hopefully it allows installing a desktop/task bar icon with autoupdate functionality. – Kuibyshev

getdown does support what you are looking form. I am really impressed with it, and it is open-source - so no longer you are stuck with proprietary bugs. – Vida

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.

Guilbert

I didn't and I can't. Without versioning it will be checking for each jar with an http call, which will cause the exact same delay i am trying to avoid. – Vida

I understand, but with Java you never know. It may end up being faster to forego versioning. I also wanted to avoid http call when I was using background update option. But it turned out the http call to see if the file has change is very quick anyways and didn't help much to do in background. Try with and without versioning and time it, see which one loads faster. – Guilbert

Thanks for your idea; we have already spent several hours/days/weeks to measure and optimize these delays. Versioning is a must for applets to load decently fast (at least for our case). The point though here is that there is something broken and I hope that either i am mistaken or that Oracle will fix it (or that a workaround exists that i have missed it) – Vida