Java-Start schlägt beim zweiten Lauf fehl: java.lang.NullPointerException

Question

Ich habe die .jnlp-Datei heruntergeladen und ausgeführt. Es läuft gut. Ich schließe es und starte es wieder, es läuft gut.

Bei dem dritten Versuch wird jedoch immer java.lang.NullPointerException ausgelöst und die Anwendung wird nicht gestartet.

Wenn ich den Computer neu starte, funktioniert es wieder. Wie kann ich das beheben?

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

Die Stacktrace ist der gleiche wie in Bug ID 6533653 und Bug ID 6850598. Die Ursache scheint eine leere JAR in JNLP zu sein. Sie sagten, sie hätten es in Java 1.6 Update 2 bzw. Java 1.6 Update 18 behoben.

Allerdings gibt es einen Kommentar in den letzten Fehlern, der beklagt, dass das Update noch nicht in 1.6-Update funktioniert 18, zusammen mit einer Beschreibung, die wie Ihre Situation viel aussehen:

In vm 6u18 diesem Fehler ist NICHT geschlossen. Sie Ihre Anwendung einmal starten kann, aber nachdem Sie die folgende Ausnahme haben:

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) 

Wenn ich das leere Glas aus jnlp entfernen, alles ist in Ordnung. Bitte überprüfen Sie Ihre Korrektur vor der Veröffentlichung

Also, versuchen Sie die leere JAR aus der JNLP entfernen und die JNLP Autoren als auch melden.

Answer 2

Wir haben dieses Problem auch für Benutzer mit der Version 1.6.0_18 gesehen.

Ich habe mir die in meiner jnlp-Datei aufgelisteten Gläser angesehen und festgestellt, dass ein Lizenzglas als wahrscheinlicher Kandidat für ein Glas ohne Klassen heraussprang. Ich habe dies mit jar tf bestätigt.

Als einen schnellen Test habe ich das Glas aus der Jnlp-Datei entfernt und ich habe den Fehler nicht erhalten. Ich benötigte jedoch das Lizenzglas für eine 3rd-Party-Bibliothek.

ich meine Build-Datei aktualisiert

die Lizenz Glas in meine Anwendung jar zu bündeln

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

Die 3rd-Party-Bibliothek kann die Lizenzinformationen in dem Classpath finden und keine Fehler mehr!