Запуск Java завершается неудачно при втором запуске: java.lang.NullPointerException - PullRequest
Новая
       7

Запуск Java завершается неудачно при втором запуске: java.lang.NullPointerException

3 голосов
/ 08 декабря 2010

Я скачал файл .jnlp и запустил его. Работает нормально. Я закрываю и запускаю снова, все работает нормально.

Однако с третьей попытки всегда выдается java.lang.NullPointerException, и приложение не запускается.

Если я перезагружаю компьютер, он снова работает. Как я могу это исправить? 

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)

Ответы [ 2 ]

5 голосов
/ 08 декабря 2010

Трассировка стека такая же, как в Идентификатор ошибки 6533653 и Идентификатор ошибки 6850598 .Основной причиной является пустой JAR в JNLP.Они сказали, что исправили это в Java 1.6 update 2 и Java 1.6 update 18 соответственно.

Однако в последней ошибке есть комментарий, который жалуется на то, что исправление все еще не работает в 1.6 update 18, а такжес описанием, которое очень похоже на вашу ситуацию:

В vm 6u18 эта ошибка НЕ ​​закрыта. Вы можете запустить свое приложение один раз, но после того, как у вас возникнет следующее исключение : 

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)

Если я удалю пустую банку из jnlp, все в порядке. Пожалуйста, проверьтеВаше исправление перед публикацией

Итак, попробуйте удалить пустой JAR из JNLP и сообщить об этом и авторам JNLP.

1 голос
/ 18 сентября 2013

Мы видели эту проблему и для пользователей с версией 1.6.0_18.

Я посмотрел на банки, перечисленные в моем файле jnlp, и обнаружил, что лицензионная банка выпала как вероятный кандидат на банку без классов. Я подтвердил это с jar tf.

В качестве быстрого теста я удалил jar из файла jnlp и не получил ошибку. Однако мне понадобился лицензионный кувшин для сторонней библиотеки.

Я обновил файл сборки, чтобы связать jar лицензии с файлом jar приложения 

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

Сторонняя библиотека может найти информацию о лицензии в пути к классам и больше никаких ошибок!

...