Java web start linux

README
Java TM Web Start Technology

Version 1.2

Table of Contents

Introduction

Java TM Web Start is a deployment solution for Java-technology-based applications. It is the plumbing between the computer and the Internet that allows the user to launch and manage applications right off the Web. Java Web Start provides easy, one-click activation of applications, and guarantees that you are always running the latest version of the application, eliminating complicated installation or upgrade procedures.

Distributing software across the Web in the tradition manner requires the user to find the installer on the Web, download the installer, locate the installer on the system, and then execute the installer. Once the installer is executed, it prompts for installation directories and installation options such as full, typical, or minimum. This is a time-consuming and complicated task, and one that must be repeated for each new version of the software.

By contrast, Web-deployed applications, such as your favorite HTML-based email client and calendar, auction sites, and so on, are a breeze to install and use. The Web browser has automated the entire process. There is no complicated download, setup, and configuration steps, and you are guaranteed to always be running the latest version.

Java Web Start technology provides the same benefits to full-featured applications as described above for HTML-based applications. Java Web Start technology is an application deployment solution for the Web. Using a full-featured application instead of an HTML-based client can have many benefits:

• A highly-interactive user interface, comparable to traditional applications, such as word processors and spreadsheets.
• Lower bandwidth requirements. An application does not necessarily have to connect back to the Web server on each click, and it can cache already-downloaded information. Thus, it can provide better interactivity on slow connections.
• Support for off-line use.

Or course, you still have to download the application the first time you use it. An HTML-based application, thus has a first-time activation cost. Typically, a Web page is brought up in a matter of seconds. A Java TM -technology-based application will require download times in the order of minutes on a typical modem connection. The Java Web Start caches all downloaded files locally on the computer. Thus, although the first-time activation cost is higher for applications than for HTML pages, subsequent launches will be almost instantaneous because all the required resources are already available locally.

On each launch, Java Web Start checks the Web server to see if a new version of the application is available, and if so, automatically downloads and launches it. Thus, applications are automatically brought up to date. There is no complicated upgrade procedure.

Security

Java Web Start is built on top of the Java 2 platform, which provides a comprehensive security architecture. Applications launched with Java Web Start will, by default, run in a restricted environment («sandbox») with limited access to files and network. Thus, launching applications using Java Web Start maintains system security and integrity.

An application can request unrestricted access to your system. In this case, Java Web Start will display a Security Warning dialog when the application is launched for the first time. The security warning will show information about the vendor who developed the application. If you choose to trust the vendor, then the application will be launched. The information about the origin of the application is based on digital code signing.

Installation Instructions

Using Java Web Start Software

Java Web Start allows you to launch Java-technology-based applications directly from the Web. An application can be launched in three different ways:

• From a Web browser by clicking on a link.
• From Java Web Start’s built-in Application Manager, which tracks recently used applications and provides quick access to your favorite applications.
• From desktop icons or the Start Menu (Microsoft Windows only).

Regardless of which way is used, Java Web Start will connect back to the Web server each time an application is launched to check whether an updated version of the application is available.

Launching from a Web browser

On the ( Java Web Start demos page), there are links to a number of applications that can be launched with a single click of a mouse. Try launching the different applications by clicking on the Launch buttons. The Web browser will launch Java Web Start, which will then download, cache, and execute the given application. You will notice that the second time you launch an application, it starts much more quickly since it is already present locally and does not need to be downloaded again.

Most of the demos on the page are just downloaded and executed without any user intervention. These applications run in a restricted environment in which they are prevented from accessing the local disk and network, and can be guaranteed not to install any viruses on your computer.

Some demos require extra privileges, such as access to your local hard disk. For these applications, a security dialog will pop up with information about the origin of the application based on who digitally signed the code. The application will run only if you decide to trust the vendor.

That is really all there is to using Java Web Start, but how does it work? The HTML links that launch the applications are, in fact, standard HTML links. However, instead of pointing to another Web page, they link to a special configuration file called a JNLP file. The Web browser examines the file extension and/or the MIME type of the file, and sees that it belongs to Java Web Start. It then launches Java Web Start with the downloaded JNLP file as an argument. Java Web Start proceeds with downloading, caching, and running the application as directed by the JNLP file.

Launching from the built-in Application Manager

The Application Manager is a built-in part of the Java Web Start product. It lets you quickly and easily launch applications that have previously been launched by Java Web Start. It is a combination of a History menu and a Start/Programs menu for your Web deployed Java-technology-based applications. The Application Manager also allows you to see additional information about the applications, with links the applications’ home pages.

You launch an application from the Application Manager by double clicking on the application icon or by clicking the launch button.

Another important feature of the Application Manager is the Preferences dialog which lets you examine and modify settings used by Java Web Start. For example, this includes tabs which allow you to:

• Specify an HTTP Proxy (or tell Java Web Start to use the default browser settings).
• Clear the cache of downloaded applications.
• Specify the location of the different versions of Java runtime environments.
• Select whether a Java console is to be displayed.
• View the set of root security certificates.

The Application Manager is launched by either clicking on the Java Web Start icon on the desktop or in the Start Menu on Microsoft Windows. On the Solaris TM Operating Environment and Linux, it is launched by invoking the javaws command in the Java Web Start installation directory. The Application Manager can also be launched from a Web browser; see, for example, the ( demos page).

Launching from desktop icons and the Start Menu (Microsoft Windows only)

Java Web Start technology can automatically create shortcuts on the Microsoft Windows desktop and in the Start Menu for Web deployed Java-technology-based applications. By default, Java Web Start asks the second time an application is launched, if a shortcut should be created. This can be changed using the Preference panel.

Shortcuts can also be added and removed by using the Application Manager, using the Application/Create Shortcut, and using Application/Remove Shortcut menu item.

Using Java Web Start Software Behind a Proxy Server/Firewall

Java Web Start software must be configured with the correct proxy settings in order to launch applications from outside your firewall. Java Web Start software will automatically try to detect the proxy settings from the default browser on your system (Internet Explorer or Netscape TM browsers on Microsoft Windows, and Netscape browsers on the Solaris Operating Environment and Linux). Java Web Start technology supports most web proxy auto-configuration scripts. It can detect proxy settings in almost all environments.

If the proxy setting cannot be automatically detected, then you will be prompted to specify the proxy settings the first time you use Java Web Start. Java Web Start will also prompt you for a user name and password required to access an authenticating proxy server. This user name and password will be stored for the current invocation of Java Web Start. However, at the time a newly invoked Java Virtual Machine, if accessing a secure web site, will prompt you for the user name and password since this information is stored within a Java Virtual Machine instance.

You can also use the Java Web Start Preferences panel to view or edit the proxy configuration. Launch the Application Manager, either by clicking on the icon on the desktop (Microsoft Windows), or type ./javaws in the Java Web Start installation directory (Solaris Operating Environment and Linux), and then select Edit/Preferences. If you are in an environment where access to the Web is through a proxy server, you are encouraged to use the Java Web Start Preferences panel to check that these are set-up correctly.

Release Notes

For a list of bug fixes and enhancements that were made for this release of the Java Web Start software, please refer to the release notes.

Источник

Как мы мигрировали с 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-приложений. Если будут вопросы — спрашивайте, постараюсь ответить.

Источник