Вопрос

Недавно я использовал приложение Java Web Start.Я запустил его из своего веб-браузера, используя встроенную ссылку jnlp на просматриваемой странице.Приложение скачалось, запустилось и работало нормально.Он имел доступ к моей локальной файловой системе и запоминал мои предпочтения перед ее перезапуском.

Я хочу знать, почему приложения Java Web Start не являются более популярным форматом доставки сложных приложений в Интернете?Почему разработчики часто тратят много времени и энергии на копирование функциональности рабочего стола с помощью html/javascript, тогда как мощь настольного приложения можно было бы проще реализовать с помощью Java и Java Web Start?

Я знаю, что в некоторых корпоративных средах, например в банковской сфере, они являются относительно популярным способом доставки клиентам сложных торговых приложений, но почему они не распространены в сети в целом?

(Для обсуждения давайте предположим, что существует мир, в котором:Источники загрузки являются «доверенными», а приложения «подписаны» (т.е.никаких проблем с безопасностью), скорость загрузки высокая (время загрузки быстрое), и разработчики знают Java (в цифрах они знают html/js/php)).

Это было полезно?

Решение

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

Панель управления Java имеет настройки, которые позволяют пользователям использовать настройки прокси-сервера браузера по умолчанию или переопределять их.Другими словами, инфраструктурные группы могут настроить установочные образы Windows или ОС так, чтобы в них была предварительно установлена ​​JVM с настройками корпоративного прокси.Поэтому я считаю, что это вообще не проблема.

Java Web Start фактически кэширует все приложения с настраиваемыми настройками в панели управления Java.После кэширования приложения оно «устанавливается», как и другие приложения.Хотя первое выполнение может быть медленным, второй раз будет быстрым благодаря технологии интеллектуального распределения памяти JVM.Таким образом, время запуска может быть проблемой, но многие веб-сайты (даже внутренние) теперь перенесены на портал.Веб-портал обычно содержит множество неиспользуемых библиотек для целей разработки, поскольку сам портал не предвидит, какие типы портлетов создаются и развертываются на конкретной странице.Таким образом, загрузка одной страницы портала может занимать до МБ, а загрузка страницы может занять более 5 секунд;это всего лишь одна страница, и кеширование помогает до 30%, но все равно остается множество компонентов HTML/Javascript/CSS, которые необходимо загружать каждый раз.При этом я уверен, что Java Web Start будет здесь преимуществом.

Java Web Start не загружается повторно, если он кэшируется, пока копия сервера НЕ обновлена.Поэтому, если, напр.программное обеспечение для управления проектами, такое как MS Project, выполняется с использованием SmartClient (аналогично JWS), обмен информацией между клиентом и сервером будет представлять собой чисто данные без представления, такого как полное обновление страницы браузера.Даже с помощью Ajax он не исключает полной загрузки страницы полностью.Кроме того, многие компании считают Ajax еще незрелым и незащищенным.Вот почему Ajax является горячей темой в кругах разработчиков, но еще не в сфере корпоративного программного обеспечения.Имея это в виду, приложения JWS определенно имеют больше преимуществ, таких как то, как приложения JWS развертываются и выполняются в изолированных программных средах, подписываются и имеют гораздо более интерактивный графический интерфейс.

Другие преимущества включают более быструю разработку (облегчает отладку кода и производительность), отзывчивый пользовательский интерфейс (не требует, чтобы серверы Comet обеспечивали функциональность PUSH) и более быстрое выполнение (наверняка, потому что клиентские компьютеры отображают графический интерфейс без перевода, как HTML/Javascript/CSS, и меньше обработки данных).

После всего этого я еще не затронул вопрос, почему JWS не так известен?

Мое мнение таково, что это то же самое, что и комментарий Брайана Ноблауха, но без осознания.

ИТ-специалистов слишком привлекает шумиха вокруг веб-технологий, Ajax PUSH, GWT, и все эти модные словечки заставляют их склоняться к получению удовольствия от использования различных технологий или к решению технических проблем, а не к тому, что действительно работает для клиентов.

Взгляните на Цитрикс.Я думаю, что Citrix на самом деле — отличная идея.Citrix позволяет вам незаметно создавать собственные фермы приложений.Существует множество стратегий обновления и внедрения, которые вы можете использовать без ущерба для качества обслуживания клиентов.Развертывание Citrix чрезвычайно просто, стабильно и безопасно.Предприятия до сих пор используют его.Однако я думаю, что JWS даже лучше, чем Citrix.Идея JWS заключается в том, чтобы запускать приложения на клиентских машинах вместо размещения множества серверных ферм, где клиентские машины могут сами запускать эти приложения.Это экономит компании много денег!!!С помощью JWS команда разработчиков по-прежнему может создавать бизнес-логику и данные на стороне сервера.Однако без блока веб-обработки и предоставления возможности клиентским компьютерам выполнять процесс рендеринга, это значительно снижает потребление сети и вычислительную мощность сервера.

Еще одним примером того, почему JWS является потрясающей идеей, является Blackberry MDS.Приложения Blackberry на самом деле представляют собой приложения Java, переведенные с Javascript.В студии MDS BB вы используете инструмент с графическим интерфейсом для создания графического интерфейса приложения BB, кодируя логику графического интерфейса на Javascript.Затем приложения переводятся и развертываются на сервере BES.Затем сервер BES распространит эти приложения на BB.На каждом BB оно запускает тонкое Java-приложение только с графическим интерфейсом и возможностью работы в сети.Всякий раз, когда приложению требуются данные, оно связывается с BES через веб-службы, чтобы использовать услуги других серверов.Разве это не просто версия JWS BB?Это было чрезвычайно успешно.

Наконец, я думаю, что JWS не популярен из-за того, как его рекламирует Sun.BB никогда не рекламирует, насколько хороши их Java-приложения BB, они полагают, что клиентов даже не волнует, что это такое.BB рекламирует преимущества использования MDS для разработки приложений:Быстрый, экономичный, деловой возврат.

Просто мои, немного длинные, 2 цента...:)

Другие советы

Основным препятствием для Java Webstart, вероятно, является то, что вам все еще необходимо установить JVM, прежде чем она сможет даже попытаться загрузить и запустить ваше приложение.Браузер есть у каждого.Не у всех есть JVM.

Редактировать:С тех пор я приобрел некоторый практический опыт веб-старта и теперь могу добавить эти два момента:

  • А Сценарий набора средств развертывания а модульная JVM, выпущенная где-то около Java 1.6u10, делает требования к JVM менее проблематичными, поскольку она может автоматически загружать JVM и ядро ​​API и запускать программу, загружая остальное.
  • Web Start серьезно глючит.Даже среди выпусков Java 1.6 был один, который загружал все приложение каждый раз, а другой загружал его, а затем выдавал непонятное сообщение об ошибке.В общем, я не могу рекомендовать полагаться на столь хрупкую систему.

Я думаю, что это в основном из-за недостаточной осведомленности.Это работает очень хорошо.Вполне бесшовно.Приложение загружается только в том случае, если это происходит впервые, было выполнено обновление или если конечный пользователь очистил кеш.Отличный способ развернуть полноценные настольные приложения, которые пользователю не придется обновлять вручную!

Проблема с Webstart заключается в том, что вам на самом деле нужно «запустить» что-то, что не так уж и быстро, даже при быстром соединении, тогда как в веб-приложении вы вводите URL-адрес, и приложение уже там.

Кроме того, с веб-стартом многое может пойти не так.Возможно, у предполагаемого пользователя нет необходимых привилегий, или прокси-сервер webstart настроен неправильно, или что-то пошло не так с зависимостями jre, или Java просто не установлена.Так что среднестатистическому Джону в инете это совсем не приятно.

В контролируемых средах, таких как компании, во многих случаях это хорошее и простое решение.

Я работал над приложением, развернутым с помощью JWS, в течение нескольких лет с базой пользователей в несколько тысяч человек, и его автоматические обновления на самом деле являются огромной проблемой.

При каждом обновлении по какой-то причине десятки пользователей «застревают посередине».Все, что вы получаете, это исключение «класс не найден» (если вам повезет) или неинформативное «невозможно запустить» из JWS еще до того, как оно дойдет до вашего кода.Похоже, обновление загружено наполовину.Или, другими словами, оно не загружает и не применяет обновление атомарно И имеет плохое кеширование, поэтому перезапуск приложения с того же URL-адреса ничего не исправляет.

Нет другого способа решить эту проблему, кроме как очистить кеш JWS или указать другой URL-адрес (например.добавить ?dummyparam=jwssucks в конце).Даже я, как разработчик, иногда сталкиваюсь с этим и не вижу выхода.

Когда это работает, это работает.Но слишком часто этого не происходит, и тогда это причиняет огромную боль вам и вашей службе поддержки.Я бы не рекомендовал его для корпоративного или критически важного использования.

Существует очень большая проблема, а именно то, что он не позволяет развертывать «мгновенно запускать программу, а затем проверять и загружать любые обновления в фоновом режиме», к чему де-факто сводится поведение приложений.

Лично я считаю это настолько большим раздражением, что мы активно ищем другую технологию, обеспечивающую это.

Судя по этим постам, при использовании Web start важно хорошо позаботиться о сервере.«Огромная боль» при загрузке приложения при каждом запуске может быть вызвана неправильной отметкой времени, доставленной с сервера.Здесь не приложение, а сервер надо настроить на правильное использование кеширования, а не просто на его отключение.Насчет глючного запуска я не очень уверен, но мне кажется, что это тоже может быть вызвано ненадежным соединением.

Важным преимуществом Web start является то, что он прекрасно работает с OpenJDK под Linux.Клиенты некоторых счастливых разработчиков используют только Windows, а мои клиенты — нет.

HTML и JavaScript, упомянутые в первом вопросе, — это более простые подходы, которые отлично работают с небольшими задачами, такими как анимированные кнопки или даже интерактивные таблицы.Ниша Java ориентирована на гораздо более сложные задачи.

Java Web Start является своего рода преемником Java-апплетов, а в новом тысячелетии апплеты исчезли.Но я все еще считаю, что Java-апплеты намного лучше, чем GWT или ад Javascript.

Java Web Start против встроенного Java-апплета

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top