Java Lancement échoue à la deuxième exécution: java.lang.NullPointerException

Question

J'ai téléchargé le fichier .jnlp et l'ai exécuté. Ça fonctionne bien. Je le ferme et recommence, ça marche bien. Cependant, au troisième essai, il lève toujours java.lang.NullPointerException et l'application ne sera pas lancée.

Si je redémarre l'ordinateur, cela fonctionne à nouveau. Comment puis-je réparer cela ?

java.lang.NullPointerException 
    at com.sun.javaws.security.SigningInfo.overlapSigners(Unknown Source) 
    at com.sun.javaws.security.SigningInfo.getCertificates(Unknown Source) 
    at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(Unknown Source) 
    at com.sun.javaws.LaunchDownload.checkSignedResources(Unknown Source) 
    at com.sun.javaws.Launcher.prepareResources(Unknown Source) 
    at com.sun.javaws.Launcher.prepareAllResources(Unknown Source) 
    at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) 
    at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) 
    at com.sun.javaws.Launcher.launch(Unknown Source) 
    at com.sun.javaws.Main.launchApp(Unknown Source) 
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source) 
    at com.sun.javaws.Main$1.run(Unknown Source) 
    at java.lang.Thread.run(Unknown Source) 

Answer 1

Le stacktrace est le même que dans Bug ID 6533653 et Bug ID 6850598. La cause première semble être un fichier JAR vide dans JNLP. Ils ont dit l'avoir corrigé dans Java 1.6 mise à jour 2 et Java 1.6 mise à jour 18 respectivement.

Cependant, il y a un commentaire dans le dernier bug qui se plaint que le correctif ne fonctionne toujours pas 1.6 mise à jour 18, ainsi qu'une description qui ressemblent beaucoup à votre situation:

Dans vm 6u18 cette Le bug n'est PAS fermé. Vous pouvez lancer votre application une fois, mais une fois que vous avez l'exception suivante:

java.lang.NullPointerException 
    at com.sun.javaws.security.SigningInfo.overlapSigners(Unknown Source) 
    at com.sun.javaws.security.SigningInfo.getCertificates(Unknown Source) 
    at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(Unknown Source) 
    at com.sun.javaws.LaunchDownload.checkSignedResources(Unknown Source) 
    at com.sun.javaws.Launcher.prepareResources(Unknown Source) 
    at com.sun.javaws.Launcher.prepareAllResources(Unknown Source) 
    at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) 
    at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) 
    at com.sun.javaws.Launcher.launch(Unknown Source) 
    at com.sun.javaws.Main.launchApp(Unknown Source) 
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source) 
    at com.sun.javaws.Main$1.run(Unknown Source) 
    at java.lang.Thread.run(Unknown Source) 

Si je retire le pot vide de jnlp, tout est ok. S'il vous plaît vérifier votre correction avant publication

Alors, essayez de supprimer le vide JAR du JNLP et le signaler aux auteurs JNLP ainsi.

Answer 2

Nous avons également rencontré ce problème pour les utilisateurs de la version 1.6.0_18. J'ai jeté un coup d'oeil aux bocaux listés dans mon fichier jnlp et ai trouvé un pot de licence qui a probablement sauté dans un pot sans classes. Je l'ai confirmé avec jar tf.

Comme un test rapide, j'ai supprimé le fichier jar du fichier jnlp et je n'ai pas eu l'erreur. Cependant, j'avais besoin du pot de licence pour une bibliothèque tierce.

Je mis à jour mon dossier de construction pour regrouper le pot de licence dans mon pot d'application

<jar jarfile="${dist}/lib/${application}.jar"> 
    <zipgroupfileset dir="${extLib}" includes="runtime.jar" /> 
... 
</jar> 

La bibliothèque 3ème partie pourrait trouver les informations de licence dans le classpath et pas plus d'erreurs!