Linux java web start
Что такое Java Web Start и как запустить это программное обеспечение?
Как получить программное обеспечение Java Web Start:
Java Web Start входит в состав среды исполнения Java (JRE) с момента выпуска версии Java 5.0. Это означает, что при установке Java автоматически устанавливается Java Web Start. При первой загрузке приложения Java, поддерживающего технологию Java Web Start, программное обеспечение Java Web Start запускается автоматически. Java Web Start полностью размещает загруженное приложение в локальном кэше вашего компьютера. Таким образом, приложение будет запускаться почти мгновенно, поскольку все необходимые для этого ресурсы доступны на локальном компьютере. При каждом запуске приложения Java Web Start проверяет наличие новой версии на сайте, и если таковая имеется, автоматически загружает и запускает ее.
Запуск приложения с помощью Java Web Start
С помощью браузера
Нажмите на ссылку на веб-странице.
С помощью значка на рабочем столе
Если приложение используется часто, можно создать ярлык на рабочем столе или в меню ‘Пуск’. В Java Web Start может отобразиться запрос на создание ярлыков или записи в меню ‘Пуск’. Если выбран вариант ‘Да’, все последующие запуски приложения можно будет выполнять без браузера.
С помощью средства просмотра кэша приложений Java
Java Web Start также предоставляет средство просмотра кэша приложений, которое можно запустить на панели управления Java. Средство просмотра кэша приложения позволяет напрямую запускать загруженные приложения.
Инструкции по запуску с помощью средства просмотра кэша приложений
- Откройте меню Start (Пуск) >Settings (Параметры) >Control Panel (Панель управления) > дважды щелкните на значке Java. На экране появится Панель управления Java.
- Перейдите на вкладку General (Общие)
- Нажмите кнопку View (Просмотр) в разделе Temporary Internet Files (Временные файлы Интернета)
- Выберите из списка приложение, которое предполагается запустить, и дважды щелкните на его имени
С помощью командной строки
Чтобы запустить приложение с помощью командной строки, введите команду javaws jnlp_url, где jnlp_url — URL-адрес jnlp-файла приложения.
- Выберите пункт меню Пуск >Выполнить >введите command
Отобразится интерфейс командной строки. - Введите javaws url_of_jnlp
ТЕХНИЧЕСКИЕ ПОДРОБНОСТИ
issue with starting java web start application on linux
Operating System: Linux version 2.6.18-308.1.1.el5 (mockbuild@x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)) #1 SMP Fri Feb 17 16:47:13 EST 2012
Tried with Mozilla Firefox.
Problem: Unable to start the java web start application for JRE 1.7.0, even though I am using the deployment toolkit.
- source for html for JRE 7.0: deployJava.createWebStartLaunchButton(url,’1.7.0′);
- source for html for JRE 6.0: deployJava.createWebStartLaunchButton(url,’1.6.0′);
Note: The application runs perfectly fine in a Windows environment, and Linux is running the 1.6 version just fine. I also noticed the default JRE of the machine is still 1.6.0, even though I have installed JRE 1.7.0 using RPM from here and when I am trying to install now it is saying that the JRE is already installed.
Update: I have updated the default JRE, now it shows JRE 1.7.0
2 Answers 2
You don’t say what distribution you are using. Try installing openjdk icedtea-web, the latter being a web start implementation and a browser plug-in.
You don’t have to be using the browser plug-in. You can open the file with the «javaws» program.
I have good solution from this
So after a good long time not being able to play this Facebook game we’re building for P2P-related research, which runs on Java Web Start, I finally got pissed today and sat down and finally got to the bottom of it.
Because Java isn’t free technology and all that, OpenSUSE actually comes preinstalled with OpenJDK instead of the common version of Java distributed by Sun. With this default configuration, Web Start (JNLP) files on the internet will open by default in an open implementation of Java Web Start called ‘IcedTea Web Start’, which I hear works reasonably well – but outright doesn’t work for some cases, like mine.
For people who, like me, need to run Sun’s version of Web Start from Firefox – first, you need to grab and install Sun’s version of the Java runtime using your software package manager (in OpenSUSE the package is called java-1_6_0-sun). Verify that you have a program called ‘javaws’ after this step. You can simply type ‘javaws’ into an open terminal and make sure it is recognized as Java(TM) Web Start.
Okay, next all we need to do is get Firefox to use javaws when opening JNLP files. For other distros you’d go to Edit > Preferences > Applications in Firefox, look for JNLP, and change the setting so it uses javaws. On OpenSUSE, Firefox is integrated so it takes its file-association settings directly from KDE. So you’ll have to instead go to KDE’s systemsettings (Configure Desktop) > Advanced Tab > File Associations. Here, run a search for JNLP, then add ‘/usr/bin/javaws’ to the top of the Application Preference Order.
We’re done! Next time you open a JNLP Web Start file in Firefox, it should offer to use Sun’s Java Web Start to open it 🙂
📟 Как выполнить / открыть файлы JNLP в Linux — Ubuntu / Debian / Fedora / Arch Linux
Java Network Launch Protocol (JNLP) — это протокол, который позволяет запускать приложение на клиентском рабочем столе с помощью ресурсов, размещенных на удаленном веб-сервере.
Плагин Java и программное обеспечение Java Web Start считаются клиентами JNLP, поскольку они могут запускать удаленно размещенные апплеты и приложения на клиентском рабочем столе.
Cтандартный способ доступа к Серверу iLO / IPMI — через файл JNLP, загруженный с консоли сервера.
Мне пришлось найти инструмент, который позволит мне запустить этот файл на моем рабочем столе Linux.
В этом руководстве мы установим IcedTea-Web, которая является бесплатной программной реализацией Java Web Start и плагина для веб-браузера Java.
Установка на Ubuntu / Debian
Установка на Fedora / CentOS
Установка на Arch / Manjaro
Выполнить файл JNLP в Linux
После установки вы можете выполнить файл JNLP с помощью командной строки:
Альтернативный способ выполнения файла JNLP двойным щелчком мыши.
Как мы мигрировали с Oracle JDK и Java Web Start на AdoptOpenJDK и OpenWebStart
Доброго времени суток.
В данной статье я расскажу о «модернизации» в компании, в которой я работаю, такого инструмента как 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 клиентов, на каждый из которых служба поддержки нашей компании должна установить этот инструмент. Решение нашлось довольно быстро: доступна так называемая фоновая установка.
Нужно закинуть установочный файл на каждый из компьютеров и запустить специальную команду(а для этого у компании уже есть инструмент):
, где 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-приложений. Если будут вопросы — спрашивайте, постараюсь ответить.