J'ai remarqué que les applets signés sont chargés beaucoup plus lentement avec le dernier plugin (inclus dans Java 8U31 et 7U75). J'ai beaucoup débuté la situation et j'ai découvert que le problème est directement lié à la taille des fichiers JAR qui sont référencés dans le fichier JNLP. Le problème est que chaque fois que l'applet commence, il existe une "ré-indexation" des fichiers jar mis en cache qui prend du temps.
Pour reproduire le problème que j'ai fait ceci: J'ai créé une applet minimale et dans le fichier JnLP que j'ai utilisé pour le déploier, j'ai ajouté plusieurs fichiers de .jar non pertinents (qui ne sont même pas référencés, le chargeur de classe ne les charge pas) de taille considérable (par ex. 30 Mo). Bien sûr, j'utilise des versions dans le JNLP et capturez tout le trafic HTTP afin de vous assurer que les retards ne sont pas à cause de la circulation (vérification de la réinitialisation ou des vérifications de révocation de certificat, etc.). J'exécute l'applet avec la trace activée, puis passa via le fichier journal de trace XML et découvert où les retards viennent: ils sont toujours du jarsigningverificateur ....
Quelqu'un d'autre a-t-il vu quelque chose comme ça?
Il est très facile de voir et de reproduire ce comportement et je me demande s'il y a quelque chose que je suis négligé. Après avoir travaillé sur des applets depuis beaucoup d'années, je suis totalement perdu à ce qui peut se passer. Je peux vérifier que la renvération de la version précédente du plugin (et de toute autre version avant) fonctionne comme prévu.
J'ai soumis un rapport de bogue avec Oracle, mais je n'ai pas encore entendu. Toute information ou une idée aidera, TIA
3 Réponses :
même ici. Je pensais déjà que je deviens fou. Merci de partager cela.
Nous utilisons Java Web Start, mais il partage le même problème de ré-indexation de tous les fichiers JAR (dans notre cas, il s'agit d'une application avec des bocaux toutaux, donc de démarrage prend des âges).
Mis à part le fait que Oracle a soudainement décidé de vérifier le certificat du déploiement TLS, qui a provoqué une hickup sur Linux et Mac (nous avons utilisé un certificat StartsSl, ce qui n'est pas inclus dans le keyStore Java - sur Windows, il fonctionne Comme il utilise aussi les plates-formes certes racine, aussi).
et, pour le rendre encore pire, sur Windows X86, le 8U31 meurt silencieusement si -xx: + fasse de cypaanalyse ou -xx: + optimistringconcat est présent dans les arguments JVM, bien que les deux paramètres soient standard dans Java 8 (mais pas dans 7 , c'est pourquoi ils ont été inclus, toujours). Le moteur 64 bits n'a pas ce problème.
La prochaine chose à laquelle ils ont changé, c'est qu'ils écrivent maintenant les icônes de démarrage s'ils ont été changés (nous les avons changés pour mettre le chemin du moteur 64 bits à y avoir), donc cela change obstinément le chemin de retour sur le moteur 32 bits à chaque fois. < / p>
Le comportement de Oracle n'est pas utile du tout, car ils n'ont annoncé aucun de ces changements dans leurs changelsgs, sans parler de l'annonce des changements de certificats quelques jours à venir.
J'aimerais entendre à quiconque partage des problèmes et des solutions de contournement possibles.
Patric
Avez-vous essayé votre JNLP sans versez-vous? Dans mon expérience, Java JnLP est très buggy spécialement si vous modifiez les valeurs par défaut JNLP. La prise en charge des versions est désactivée par support, alors essayez-la sans la version et de voir si elle est toujours lente?
Pour moi, j'ai remarqué des bugs lorsque j'ai utilisé la valeur de mise à jour = "fond", donc je ne modifie plus la méthode de mise à jour par défaut. Ma théorie est que Oracle ne teste que JNLP contre les valeurs par défaut avant de publier de nouvelles versions Java.
Je n'ai pas et je ne peux pas. Sans le versement, il vérifiera chaque pot avec un appel HTTP, ce qui entraînera le même retard que j'essaie d'éviter.
Je comprends, mais avec Java, vous ne savez jamais. Cela peut finir par être plus rapide pour renoncer aux versions. J'ai également voulu éviter l'appel HTTP lorsque j'utilisais l'option de mise à jour de fond. Mais il a révélé l'appel HTTP pour voir si le fichier a changé est très rapide de toute façon et n'a pas aidé beaucoup à faire en arrière-plan. Essayez avec et sans la version et le temps, voyez lequel on charge plus rapidement.
Merci pour votre idée; Nous avons déjà passé plusieurs heures / jours / semaines pour mesurer et optimiser ces retards. La versioning est un must pour les applets de chargement décemment rapidement (au moins pour notre cas). Le point bien que voici qu'il y a quelque chose de cassé et j'espère que soit je me trompe soit que je me trompe, soit que Oracle le réparera (ou qu'une solution de contournement existe que je l'ai manquée)
Avez-vous été capable de résoudre ce problème? Avez-vous eu une réaction d'Oracle?
Mise à jour Démarrer
J'ai essayé tout ce que je peux penser et je n'ai pas réussi à résoudre le
Problème, alors je Posté ma propre question sur ce numéro < / a>.
Un rapport de bogue similaire peut être trouvé ici et est backporté à à
moins Java 8U51 que j'ai testé. Encore une fois, ils ont réussi à augmenter
Temps de démarrage pour notre application.
Mise à jour fine
Nous utilisons Java Web Start pour une application Eclipse RCP avec des pots qui sont tous signés.
Le temps de démarrage est de 8s dans l'IDE, la version Java ne semble pas compter ici. Avec Web Start, l'histoire est différente. Il devient (beaucoup) pire avec chaque mise à jour Java:
Nous allons passer à GoDown ( Github.com/threerings/getdown ). J'ai travaillé avec cela et cela semble être une excellente alternative. Bien qu'il soit bootstraps avec JWS, le reste est vraiment rapide
Merci, je l'ai essayé et commence assez vite après le téléchargement. J'attendrai probablement juillet / août et vérifiez si ce problème est corrigé mais envisagera certainement de prendre la décision. J'espère que cela permet d'installer une icône de barreaux / barre de travail avec la fonctionnalité AutoPDate.
GestionD supporte ce que vous cherchez. Je suis vraiment impressionné par cela et c'est une source open-source - donc plus vous êtes coincé avec des bugs exclusifs.
Avez-vous déjà réparé votre problème? J'ai essayé avec Java 8U51, qui supposément eu une backport de Bugfix d'Oracle, mais il semble toujours que la vérification du JAR prend environ 20 secondes (sur un PC de développeur très rapide).
Nous sommes allés nous getitdown au lieu de JNLP. Pourtant, dans certains tests internes, nous l'avons fait, il semble que la nouvelle version corrige le problème. Pourtant, les dégâts ont déjà été faits ....
J'ai essayé tout ce que je peux penser et je n'ai toujours pas résolu la question, alors j'ai posté cette question: Stackoverflow.com/questions/31568627/... En attendant, je suis également abandonnant Java Web Start. Je vais créer mon propre script de mise à jour qui fonctionne sur le réseau local de notre société qui effectue une vérification de version simple et copie simplement les fichiers d'une part de réseau.
La bonne chose avec GetItDown est que vous n'avez pas besoin de signer les fichiers JAR et que vous n'avez pas besoin de les vérifier au démarrage. Vous n'avez besoin que de signer l'applet de goulage qui est très petit.