Браузер не обрабатывает JNLP-файлы, а только сохраняет

Браузер не обрабатывает JNLP-файлы, а только сохраняет

Всемирная сеть сделала свои коррективы в жизнь обычных людей. Во многом это стало возможным благодаря технологии Java Script, которая сделала огромный скачок вперед. Еще каких-то 15 лет назад люди и не думали, что с помощью интернета они будут заказывать пиццу на дом или покупать билеты до Токио. Человек, который не имеет понятия, как настроить ноутбук, тем не менее управляет всеми современными благами можно через обычный браузер.

Протоколе Java Network Launching Protocol (JNLP) используется для запуска web-приложений технологии Java Web Start. Обычно обработка JS не вызывает проблем в современных браузерах, но с конкретно этим типом файлов бывает такая проблема, что браузер не открывает JNLP-файлы, а лишь предлагает их сохранить:

Чтобы исправить эту оплошность потребуется:

1. Скачать свежую версию Java

Зайдите на сайт https://www.java.com/ru/ и установите себе Java

2. Настройте безопасность Java-приложений.

После того, как вы установите Java на компьютер следует произвести настройку. Для этого зайдите в Пуск -> Все программы -> Java -> Configure Java

В настройках находим вкладку «Security». В ней будет специальное окно для сайтов, на которых разрешен запуск любых Java-приложений. Нажимаем «Edit site list» и добавляем туда сайт, который не дает запустить JNLP-файл:

Учитывайте, что при добавление сайта есть имеет значение префикс HTTP или HTTPS. После настройки — перезапустите браузер, если он был открыт.

3. Проверить ассоциацию (сопоставление) типов файлов к приложениям

Если предыдущий способ не помог, то следует проверить нужное ли приложение использует (с нужной ли программой ассоциируется) система для открытия JNLP-файлов.

Windows 98/ME/XP

«Пуск» -> «Панель управления» -> «Свойства папки» -> «Типы файлов». Ищем JNLP

Windows 7/8/10

«Пуск» -> «Панель управления» -> «Программы по умолчанию» -> «Сопоставление типов файлов или протоколов конкретным программам»

Свой вариант исправления этой ошибки пишите в комментарии.

Java Web Start Overview

Contents

Java Web Start Software and the JCP

Java Web Start software provides a flexible and robust deployment solution for Java technology-based applications based on the Java Community Process program (JCP). The technology is being developed through the JCP program as JSR-56: The Java Network Launching Protocol & API (JNLP), which provides a browser-independent architecture for deploying Java 2 technology-based applications to the client desktop.

Java Web Start technology works with any browser and any Web server. Each application developed for use with the Java Web Start software specifies which version of the Java 2 platform it requires, e.g., version 1.4 or 1.5, and each application runs on a dedicated Java Virtual Machine (JVM).

Auto-download of Software from Java

A main feature of the Java Network Launching Protocol and API technology is the ability to automatically download and install Java Runtime Environments onto the users machine.

For example, an application might depend APIs in Sun’s Java Runtime Environment 1.4.0 (or later). When a user first accesses this application, the Java Web Start software will download all the needed files for the application, as well as download the Java Runtime Environment (JRE) if the requested version is not available locally. The ability to automatically download a JRE is one of the key features to ensure robust deployments. It ensures that the JRE that your application is tested on will be available on the user’s machine, as well as make it possible to seamlessly upgrade to improved versions of the Java 2 platform over time.

The auto-download feature simplifies Java Web Start deployments because it makes commonly used software readily available for use with Java Web Start. Typically, only an extra line has to be added to a JNLP file to take advantage of this feature. In contrast, without the auto-download feature, developers would be forced to repackage and host the software themselves — adding a significant overhead to the deployment burden. As an added benefit to both developers and end-users, this minimizes the download time for an application since each JRE will be shared between multiple applications.

The packages currently available for auto-download are:

• Java 2 Runtime Environment 1.3.0_02 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.3.1_08 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.3.1_09 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.3.1_11 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.3.1_18 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.0 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.1_02 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.1_07 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_01 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_04 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_12 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_13 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_09 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_14 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java 2 Runtime Environment 1.4.2_16 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_02 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_06 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_07 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_08 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_09 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_10 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_11 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.5.0_14 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.6.0 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.6.0_04 for Windows/i586, Linux/i586, and Solaris/SPARC
• Java Runtime Environment 1.6.0_05 for Windows/i586, Linux/i586, and Solaris/SPARC

Because the Java Web Start Java Runtime Environment installer uses Verisign certificates, the autodownload from here works only if the client machine has version 1.3 or later of the Java Runtime Environment installed.

How to Request a Specific Version of the Java Runtime Environment

The «j2se . » element is used to specify the set of Java Runtime Environments that your application supports. They can be specified both as a vendor-independent platform-version and as a vendor-dependent product version.

Specifying a platform version: Currently, there are three different platforms supported: 1.2, 1.3, 1.4, and 1.5. For example:
j2se version=»1.4 1.3+»
j2se version=»1.4″

The order in which the platforms are specified matters. In the above example, the application prefers the 1.4 platform, but can run on a 1.3 platform and above. Java Web Start will automatically do a request to the auto-download site and download a JRE matching this request if none are found locally.

Specifying a product version: A product version is specified by including a vendor-specific URL from where to download the JRE.

Example 1

j2se version=»1.4.2*» href=»http://goo.gl/oWqMb»

In the above example, a product version that has 1.4.2 as a prefix is requested, e.g., 1.4.2, 1.4.2_02, 1.4.2_04 would match.

Example 2

j2se version=»1.4.0_01+» href=»http://goo.gl/oWqMb»

In the above example, a product version that is equal to or greater than 1.4.0_01 is requested.

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