Доброго времени суток.

В данной статье я расскажу о «модернизации» в компании, в которой я работаю, такого инструмента как Java Web Start, а точнее об его замене альтернативным opensource решением.

О себе

Меня зовут Ильдар и работаю я в одной немецкой компании, которая как и многие немецкие компании использует старый стек технологий и пытается мигрировать на стек поновее.

Проблема

Начну с описания проблемы. В нашей компании есть важнейшая часть системы, которая представляет из себя legacy-приложение, написанное на java 6 и частично на java 8. Запускалось оно на java 8. Чтобы использовать это приложение на production пользователи скачивают с сайта jnlp-файл и запускают его у себя на компьютерах.

Так компания долго и счастливо существовала, пока Oracle не объявила о прекращении поддержки 8й версии java, не пометила технологию Java Web Start как deprecated и вовсе решила выпилить ее начиная с java 11. Это значило, что JWS-приложения, коих все еще немало, больше не будут получать в том числе обновлений безопасности. С этим, конечно же, мало кто может смириться. Так же подумали энтузиасты из компании Karakun решили написать свою замену для JWS.

В нашей же компании некоторое время назад начали переписывать приложение, используя Spring boot для бекэнда и React для фронтэнда, но процесс не быстрый, а обновлений нет уже сейчас.

Поиск решения

Итак перед командой разработки встал вопрос о поиске альтернативных решений. Вообще стоит признать, что решение проблемы есть и не одно. Изначально архитекторы отобрали два решения GetDown и тот самый OpenWebStart. На момент принятия первоначального решения выбор пал на первый вариант, так как OpenWebStart еще даже не был зарелизен под первой версией (были только какие-то наработки и планы).

У каждого из решений были свои плюсы и минусы, но компания решила не ждать релиза OpenWebStart и начать реализовывать proof of concept на базе GetDown.

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

Тем временем прилетели другие срочные задачи и команда разработки отвлеклась от перехода со стадии PoC к полноценной реализации замены Java Web Start.

Сроки поджали

Все жили счастливо, пока менеджмент не осознал, что пришло время уже заканчивать и с заменой Java Web Start. До этого момента я не занимался этим проектом, но тут меня тоже подключили.
Сначала я решил поискать информацию о вариантах решения нашей проблемы еще раз. Так скажем вникнуть в решение с нуля. Таким образом я для себя открыл существование OpenWebStart. Протестировал у себя локально, столкнулся с некоторыми проблемами (потом мы столкнулись еще и с другими) и решил их. В итоге решение понравилось всем. Нужно ли говорить о том, что особенно оно понравилось менеджменту тем, что не нужно будет тратить времени на разработку как в случае с GetDown. Но в итоге время мы потратили на то, чтобы заставить работать нашу систему с OpenWebStart.

Краткая информация об OpenWebStart

OpenWebStart основан на другой реализации Java Web Start — IcedTea-Web и JNLP-спецификации JSR-56. На момент написания статьи проект существует в версии 1.1.4 и планирует реализовать в себе основные фичи Java Web Start (за прогрессом можно наблюдать тут).
Перечислять все возможные настройки не вижу смысла, это может занять очень долго.

Вот лишь некоторые из них:

• управление кэшем (размерами, местоположением...),
• настройки безопасности (разрешение пользователям запускать не подписанное сертификатами приложение, показывать или нет предупреждающие попапы...),
• добавлять адреса серверов в белый список,
• настройки удаленного дебага,
• управление сертификатами безопасности,
• управление версиями JRE/JDK,
• и другие

Особенности использования OpenWebStart и проблемы, с которыми мы столкнулись

Установка OpenWebStart

Установить OpenWebStart довольно просто. Достаточно на сайте скачать установочный файл для вашей платформы и следовать инструкциям установщика.

Но вот незадача. В нашем случае пользователями являются около 10000 клиентов, на каждый из которых служба поддержки нашей компании должна установить этот инструмент. Решение нашлось довольно быстро: доступна так называемая фоновая установка.

Нужно закинуть установочный файл на каждый из компьютеров и запустить специальную команду(а для этого у компании уже есть инструмент):

OpenWebStart_windows_Setup.exe -q -varfile response.varfile

, где response.varfile — файл с некоторыми настройками, которые заранее можно задать установщику. Например, папка, в которую установить OpenWebStart, и некоторые другие.

Хорошо, с этой проблемой справились. Дальше нужно бы как-то всем клиентам установить определенную версию AdoptOpenJDK и связать их с OpenWebStart, что легко делается через пользовательский интерфейс, но это не наш случай.



Мы же в настройках обнаружили, что можно указать URL, с которого OpenWebStart будет брать файл настроек, в котором можно указать URL на нужную нам JRE. А сам URL с файлом настроек можно указать в упомянутом выше response.varfile (вот так все сложно).

Сам JSON-файл настроек с разными версиями JRE выглядит следующим образом.

В настройках так же можно задать версию и вендора JRE, на случай если в JSON файле указано несколько JRE. Мы же указали только один и залили JSON файл и архив с нужным нам JRE на Amazon S3 bucket.

Протестировав мы обнаружили, что с версией JRE, загруженной нами, приложение не стартует… Оказалось, что у нашей джавы немного другая структура в архиве. Мы на скорую руку написали batch-скрипт, который перестраивал структуру JRE архива.

«Ну вот теперь все прекрасно заработает», — подумали мы.

При первом запуске приложения автоматически загружается JRE, который и используется в дальнейшем. Но, нас ждал следующий сюрприз.

Беда не приходит одна

Но как это обычно бывает одной проблемой мы не ограничились.

У нашего приложения есть, скажем так, одна особенность. На самом деле их два. Одно приложение (один jnlp файл) запускает из себя второе приложение (второй jnlp). И вот в этом случае второе приложение не стартовало. В логах можно было увидеть, что приложения застревают в дедлоке. Из стектрейса стало понятно, что причиной служит внутренний механизм логгирования OpenWebStart.

Проблема решилась отключением внутреннего логгирования OpenWebStart. Логи наших приложений разумеется остались включенными.



Эти настройки так же получилось отключить в response.varfile файле, который используется при фоновой установке.

И вот после преодоления этих и немного других препятствий (всех уже и не упомнить), нам удалось запустить наше приложение, которое сейчас проходит тестирование перед релизом в прод. По мере нашего тестирования версия OpenWebStart обновилась с 1.1.1 до 1.1.4. Из заметных изменений была добавлена возможность дебажить удаленно.



Возможно, моя статья будет кому-то полезна в таком нелегком труде как поддержка legacy-приложений. Если будут вопросы — спрашивайте, постараюсь ответить.

P.S. все изображения взяты с официального сайта OpenWebStart.