Плагин java 8u31 заставляет подписанные апплеты загружать гораздо медленнее

Я заметил, что подписанные апплеты загружаются намного медленнее с последним плагином (включенным в java 8u31 и 7u75). Я довольно много отлаживал ситуацию, и выяснил, что проблема напрямую связана с размером файлов jar, на которые ссылаются в файле jnlp. Проблема в том, что каждый раз, когда запускается апплет, происходит некоторая "переиндексация" файлов кэшированных jar, требующих времени.

Чтобы воспроизвести проблему, я сделал следующее: Я создал минимальный апплет и в jnlp файле, который я использовал для его развертывания, я добавил несколько нерелевантных .jar файлов (которые даже не упоминаются, поэтому загрузчик классов не загружает их) значительного размера (например, 30 МБ). Конечно, я использую управление версиями в jnlp и фиксирую весь трафик http, чтобы убедиться, что задержки не связаны с трафиком (либо повторная загрузка, либо проверка отзыва сертификатов и т.д.). Я запустил апплет с включенной трассировкой, а затем просмотрел файл журнала трассировки xml и выяснил, где происходят задержки: они всегда из JarSigningVerifier....

Кто-нибудь еще видел что-то подобное?

Очень легко увидеть и воспроизвести это поведение, и я задаюсь вопросом, есть ли что-то, что я пропускаю. Работая над апплетами в последние годы, я полностью потерял то, что может произойти. Я могу проверить, что возврат к предыдущей версии плагина (и любой другой версии раньше) работает так, как ожидалось.

Я отправил отчет об ошибке с помощью oracle, но я еще не слышал назад. Любая информация или идея помогут, ТИА

Ответы

Ответ 1

То же самое здесь. Я думал, что уже сошел с ума. Спасибо, что поделились этим.

Мы используем Java Web Start, но он использует одну и ту же проблему переиндексации всех файлов jar (в нашем случае это приложение с довольно небольшими баночками, поэтому запуск занимает много времени).

Помимо того факта, что Oracle внезапно решила проверить сертификат развертывания TLS, что вызвало некоторый hickup на Linux и Mac (мы использовали там сертификат StartSSL, который не включен в хранилище ключей Java - в Windows он работает так как он использует корневые сертификаты платформ тоже).

И, что еще хуже, на Windows x86 8u31 тихо умирает, если в аргументах JVM присутствует -XX: + DoEscapeAnalysis или -XX: + OptimizeStringConcat, хотя оба параметра являются стандартными в Java 8 (но не в 7, почему они были включены, все еще). 64-битный двигатель не имеет этой проблемы.

Следующее, что они изменили это они теперь перезаписать значки начала, если они были изменены (мы изменили их, чтобы положить путь 64bit двигателя в там), так упорно изменяет путь назад к 32-битным двигатель каждый раз.

Поведение Oracle не совсем полезно, так как они не объявили ни одно из этих изменений в своих списках изменений, не говоря уже об объявлении изменений сертификатов на несколько дней вперед.

Я хотел бы услышать от всех, кто разделяет проблемы и возможные обходные пути.

Патрик

Ответ 2

Вы смогли решить эту проблему? У вас была реакция от Oracle?

ДОПОЛНИТЕЛЬНЫЙ СТАРТ

Я пробовал все, что мог придумать, и мне не удалось решить проблему вопрос, поэтому я разместил свой собственный вопрос по этой проблеме.
Подобный отчет об ошибках можно найти здесь, и его наименее Java 8u51, который я тестировал. И снова им удалось увеличить время запуска для нашего приложения.

END UPDATE

Мы используем Java Web Start для приложения Eclipse RCP с банками, которые все подписаны. Время запуска составляет 8 с в среде IDE, версия Java здесь, похоже, не имеет значения. С веб-началом история отличается. С каждым обновлением Java он становится намного хуже:

7u?? (< 60): + 2 с (10 с)
7u60: + 5s (13s)
7u75: + 15s (23s)
8u31: + 12s (20s)
8u40: + 21s (29s)
8u51: + 23s (31s)

Ответ 3

Вы пробовали свой jnlp без управления версиями? По моему опыту Java jnlp очень затруднительно, если вы измените значения по умолчанию jnlp. Поддержка версий поддерживается с помощью поддержки, поэтому попробуйте ее без проверки версий и посмотрите, все еще медленнее?

Для меня я заметил некоторые ошибки, когда я использовал update = "background", поэтому я больше не изменяю метод обновления по умолчанию. Моя теория заключается в том, что Oracle только проверяет jnlp на значения по умолчанию, прежде чем выпускает новые версии Java.