L'application Java Web Start s'exécute sous jre8u40 mais pas jre8u51


Nous avons une application Web Java qui utilise javaws. Il fonctionnera correctement sous Java 8 update 40, mais sous Java 8 update 51 jp2launcher.exe s'arrête juste, sans lancer l'application.

J'ai trouvé les journaux dans C:\Users\me\AppData\LocalLow\Sun\Java\Deployment\log mais ils sont identiques entre j8u40 et j8u51 (sauf bien sûr pour la commande les pots sont chargés, la version jre et l'heure de lancement).

J'ai enregistré le lancement à l'aide de Process Monitor, pour les deux versions jre. Sous j8u51, jp2launcher.exe sort juste avec la resule "SUCCESS". En comparant les deux journaux procmon, je ne peux rien choisir d'inhabituel. Ils fouillent tous les deux à travers le C:\Users\me\AppData\LocalLow\Sun\Java\Deployment répertoire et leurs respectifs C:\Program Files \ Java \ jre1.8. 0_XX \ lib répertoires et tels comme, mais alors le j8u51 vient de sortir.

Les journaux d'événements Windows n'affichent rien de lié à Java.

Y a-t-il ailleurs où je peux rechercher des informations de diagnostic? Des suggestions sur quoi ça pourrait mal tourner ici?

Mise à jour: J'ai réussi à exécuter le jnlp avec set "JAVAWS_VM_ARGS=-Xcheck:jni -XX:-TraceClassLoadingPreorder -XX:+PrintCommandLineFlags -verbose:jni -verbose:class -verbose:gc -XX:+PrintGCDetails -Djava.util.logging.config.file=C:\misc\logging.properties" et à enregistrer le stdout/stderr. Il semble que javaws et jp2launcher se connectent à la sortie, puis les versions jre8u40 et jre8u51 se terminent. Vraisemblablement dans la version j8u40, il lance un autre jp2launcher.exe pour exécuter l'application.

La comparaison des deux journaux de sortie ne donne rien d'intéressant. Les classes sont chargées dans un ordre presque identique, la plupart du temps des classes identiques autres que quelques différences qui sont facilement expliqué en étant simplement des classes plus à jour utilisées.

Mise à jour supplémentaire: j'ai pu lancer l'application directement, en utilisant java.exe, en obtenant les fichiers clients de l'installation du serveur et en les décompressant. L'application elle-même fonctionne très bien sous jre8u51, donc le problème réside définitivement avec javaws lui-même.

Update3: effacer le cache ne résout pas le problème. Le problème se produit sur des machines séparées, même avec des installations Java entièrement fraîches.

Update4: Comme une expérience, je viens d'essayer sous Ubuntu Linux. Notre produit ne supporte pas techniquement Linux, mais je pensais essayer quand même. En fait, le comportement est identique! Sous jre8u40, l'application se lance, et sous jre8u51, elle ne le fait pas!

5: il s'avère que le problème se produit également sous u45, qui est la mise à jour immédiatement après u40. Donc, la cause semble être quelque chose qui a changé dans u45, plutôt que dans u51.

Author: Len, 2015-07-22

1 answers

Compris!

Il y a quelques éléments en interaction ici:

  • Le jnlp contient un élément j2se pour Java 6 et pour Java 7. S'exécutant sur Java 8, il semble qu'il utilise l'entrée Java 6.
  • L'entrée Java 6 spécifie les arguments de la machine virtuelle, alors que celle de Java 7 ne le fait pas.
  • Après essais et erreurs, j'ai déterminé que l'argument-XX:+CMSIncrementalMode VM est ce qui le fait échouer. Je ne sais pas ce que fait cet arg, mais apparemment JRE8u45+ n'aime pas il.
  • J'ai téléchargé et modifié le jnlp pour tester ce qui précède. Pour que javaws utilise réellement mes modifications, j'ai dû supprimer l'attribut href de l'élément jnlp racine. Sinon, javaws a ignoré mes modifications et utilisé la copie du jnlp sur le serveur.

Mon hypothèse actuelle est que JRE8u45+ a un bogue où il utilise les arguments de la machine virtuelle de la mauvaise version.

Je viens de tester un jnlp personnalisé avec des entrées 1.6, 1.7 et 1.8, où celui de 1.6 a les arguments vm et le 1.7 et 1.8 ne le font pas.

  • Javaws ne demande pas "L'application veut utiliser Java 7, mais vous devriez plutôt utiliser le plus à jour sur votre système, est-ce ok?". Par conséquent, à ce stade, l'is a reconnu qu'il existe une entrée 1.8.
  • Cependant, il ne parvient pas à lancer l'application. Par conséquent, à ce stade, il a dû être confus quant à l'élément jnlp sur lequel il se trouvait.

Donc, il semble que la solution de contournement consiste à supprimer le-XX:+CMSIncrementalMode VM arg à partir de la jnlp sur le côté serveur.

 0
Author: Len, 2015-08-07 10:24:12