Как выполнить обновление до jlink (JDK 9+) из Java Web Start (JDK 8) для приложения с автоматическим обновлением?
Java 8 и более ранние версии имеют Java Web Start, который автоматически обновляет приложение, когда мы его изменяем. Oracle рекомендует пользователям перейти на jlink, поскольку это новая технология Oracle. Пока это звучит хорошо. Это дает множество преимуществ:
- Нативный код на Windows, Mac и Linux
- Модуляризация кода (хотя это делает и Proguard)
- Использование новых, поддерживаемых технологий.
Проблема: я не могу найти каноническое решение Java для автоматического обновления с помощью jlink.
Можно подумать, что Java Web Start можно продолжать использовать, особенно если кто-то случайно прочитает этот документ. Обратите внимание на тот факт, что Java Web Start продолжает занимать видное место в списке. Но есть ложка дегтя: Oracle осуждает Java Web Start. Его планируется удалить в JDK 11. Итак, каков официальный путь вперед? В противном случае, есть ли стандартный путь, по которому люди поступают?
Для целей этого вопроса следующее выходит за рамки:
- Ежегодно выплачивать огромные суммы денег кому-то с помощью многофункционального корпоративного решения. Распространяемое приложение уже упаковано в одну банку размером менее 50 МБ.
- Заставить пользователей запускать приложение в стиле InstallShield для переустановки новой версии, а затем вручную удалять старую версию при каждом нажатии на обновление. Это ооочень 1990-е годы.
- Портирование всего приложения в веб-приложение, переписывание пользовательского интерфейса и клиентской логики в браузер и устранение всех возможных несовместимостей. Авторы приложения работали над GWT и точно знают, на что способны веб-браузеры. К сожалению, они также знают уровень необходимых усилий.
- Разрешение пользователям продолжать запускать старые версии приложения. Это тоже ооочень 1980-е годы. Современные приложения быстро обновляются, и поддержка каждой версии приложения, когда-либо выпущенной, недостижима. Это то, с чем пришлось столкнуться с заявлением моего отца на COBOL, и ему это не понравилось. Я надеюсь, что технология прогрессировала.
- Продолжая использовать Java Web Start. До тех пор, пока Oracle не изменит свое решение, Java Web Start является обреченной технологией.
0 ответов
В мае 2019 года прокомментировал просмотр проекта OpenWebStart.
Теперь (октябрь 2019 г.) пора серьезно подумать об OpenWebStart. Хотя функция еще не завершена, альфа- бета- версия OpenWebStart теперь доступна для загрузки по лицензии "GPL с исключением пути к классам ".
На странице технических подробностей OpenWebStart указано:
OpenWebStart основан на Iced-Tea-Web и спецификации JNLP, определенной в JSR-56. Он будет реализовывать наиболее часто используемые функции Java Web Start и сможет обрабатывать любое типичное приложение на основе JWS. Мы планируем поддерживать все будущие версии Java, начиная с Java 11. Помимо Java 11, первый выпуск OpenWebStart также будет поддерживать Java 8.
Далее на странице указано, что OpenWebStart будет поддерживать интерактивные установщики с автоматическим обновлением и неинтерактивные установщики. Некоторые функции JNLP будут поддерживаться, и он будет включать замену панели управления Java. Более полный список запланированных функций 1 и статус их реализации представлен в таблице функций.
1. Если у вас есть требование, которого нет в их списке функций (например, поддержка jlink), вы можете связаться с командой OpenWebStart и предложить подходящий стимул (например, деньги на оплату разработчикам) для реализации этой функции за вас. Они также предлагают коммерческие версии программного обеспечения для платежеспособных клиентов.
Отказ от ответственности: я не имею отношения к проекту OpenWebStart, компании (Каракун) или спонсорам проекта. Это не рекомендация.
У меня была похожая проблема в прошлом проекте. Нам нужно было перейти с Webstart на другую технологию.
Первым подходом была установка IcedTea. Он напрямую связан с проектом AdoptOpenJDK.
Но насколько я понял проблему, Java больше не предназначалась для такой установки на стороне Клиента, и мы не хотели проблем со всеми нашими клиентами.
Тогда нашим решением было создание собственного конкретного исполняемого файла, который подключается к серверу, запрашивает параметры среды со стороны сервера, а затем загружает и извлекает JLink Java. Таким образом, мы могли бы использовать старые технологии и просто обернуть их в исполняемый файл.
Последнее, что было сделано, - это перенаправление к месту загрузки исполняемого файла при вызове jnlp-URL.
Вы используете Maven?
Я решил мою похожую проблему с Maven (мне нужно обновить EAR).
Мое основное приложение (пакет ear) содержит файл pom.xml со списком зависимостей и репозиториев.
Зависимости имеют <version> тег с диапазоном ( документация), как в этом примере
<version>[1.0.0,)</version>
Это значит: получить версию 1.0.0 или новее зависимости. (Вы также можете установить верхнюю границу для версии, [1.0.0, 2.0.0), поэтому, если вы разрабатываете новую версию, она не используется в старом приложении)
В разделе репозитория я добавил свой личный репозиторий.
Теперь на удаленной машине мне нужно только пересобрать мой пакет ear с помощью maven: компилятор скачал более новую версию моего jar и соединил ее.
Вам нужна система, чтобы проверить, есть ли более новая версия зависимостей, и предупредить пользователя об обновлении приложения, а также заблокировать его работу (вы не можете работать, если вы не обновляете). Возможно, вам нужно небольшое приложение, чтобы пользователи могли легко выполнить процесс восстановления. Это 1990-е, но многие настольные приложения работают таким образом
PRO
- Эта схема может быть использована во многих различных проектах.
CONTRO
Вам необходимо собрать приложение на удаленной машине, поэтому у клиента должен быть JDK и доступ к вашему хранилищу (например, к артефакту);
Вы должны написать код в разных банках и добавить их как зависимости в основной архив.
Вы должны каждый раз менять версию JAR и публиковать в репозитории (это может быть хорошей практикой)