as Plugin @java 8u31 führt dazu, dass signierte Applets viel langsamer geladen werden.

Ich habe bemerkt, dass signierte Applets mit dem neuesten Plugin (in Java 8u31 und 7u75 enthalten) viel langsamer geladen werden. Ich habe die Situation ziemlich oft getestet und festgestellt, dass das Problem direkt mit der Größe der JAR-Dateien zusammenhängt, auf die in der JNLP-Datei verwiesen wird. Das Problem ist, dass jedes Mal, wenn das Applet gestartet wird, die zwischengespeicherten JAR-Dateien neu indiziert werden, was einige Zeit in Anspruch nimmt.

Um das Problem zu reproduzieren, habe ich Folgendes getan: Ich habe ein minimales Applet erstellt und in der JNLP-Datei, mit der ich es bereitgestellt habe, mehrere irrelevante JAR-Dateien (die nicht einmal referenziert werden, sodass der Classloader sie nicht lädt) von beträchtlicher Größe hinzugefügt (zB 30MB). Natürlich verwende ich die Versionierung im jnlp und erfasse den gesamten http-Verkehr, um sicherzustellen, dass die Verzögerungen nicht auf den Verkehr zurückzuführen sind (entweder erneutes Herunterladen oder Überprüfung der Zertifikatsperrung usw.). Ich habe das Applet mit aktiviertem Trace ausgeführt und dann die XML-Trace-Protokolldatei durchsucht und herausgefunden, wo die Verzögerungen liegen: Sie stammen immer aus dem JarSigningVerifier ....

Hat noch jemand so etwas gesehen?

s ist sehr einfach, dieses Verhalten zu sehen und zu reproduzieren, und ich frage mich, ob ich etwas übersehen habe. Nachdem ich in den letzten Jahren intensiv an Applets gearbeitet habe, bin ich total verloren, was passieren kann. Ich kann überprüfen, ob das Zurücksetzen auf die vorherige Version des Plugins (und auf alle vorherigen Versionen) wie erwartet funktioniert.

Ich habe einen Fehlerbericht bei Oracle eingereicht, aber ich habe noch nichts davon gehört. Jede Info oder Idee wird helfen, TIA

Antworten auf die Frage(6)

Ihre Antwort auf die Frage