Java-апплеты - это неправильный выбор сегодня?

У меня есть нетривиальный вычислительный код, который необходимо применять к данным, уже загруженным в DOM браузера и захваченным из пользовательских взаимодействий. Я не хочу раскрывать этот код. Мне интересно, если:

  • напишите веб-сервис и общайтесь с браузером через websocket или http. Компромисс - это скорость взаимодействия (от скользкой до бедной) и более высокие транспортные издержки.
  • напишите Java-апплет (подписанный, чтобы скрыть код), который инкапсулирует логику на странице и позволяет JavaScript взаимодействовать с Java api. Я читал в другом месте, что Java и JS-движок могут затормозить в определенных сценариях. Однако, поскольку я только вычисляю, это не проблема. Возможно, на многоядерных машинах я мог бы разделить мою работу, используя еще несколько потоков.
  • пишите в JavaScript. Но JavaScript трудно проверить, и все это в глазах общественности.

Q & A, такие как удобство использования Java-апплетов в Интернете, а также некоторые другие также обескураживают.

Мой вопрос: Java-апплеты - это мертвая технология. В наши дни нет даже Q & A! Кроме того, Java не всегда может быть объединена со всеми браузерами (рабочий стол, планшет или мобильный)?

Есть ли лучшие способы сделать то же самое, что и скрытый код, использовать клиентский cpu/ram, минимизировать трафик данных?

Веб-страницы находятся на Javascript/html5/css. Сервер использует только JSON/XML. Пакеты данных 10-20 КБ и часто обновляются. Вычисления являются дорогостоящими и специфичными для клиента, поэтому я бы очень хотел, чтобы клиент сделал все это.

Большое спасибо.

ОТВЕТЫ

Ответ 1

Я считаю, что самым большим недостатком апплета является то, что он предполагает, что на клиентской машине установлен JRE. Действительно ли это реальное предположение? Конечно, вы можете предложить загрузить и установить JRE, но зачем делать все это только для некоторых вычислений? Еще один вопрос, который я задал себе, могут ли ваши клиенты быть мобильными телефонами, планшетами и так далее? Если да, возможно, Java Script - лучший вариант.

И еще 5 центов:) Вы упомянули "открытые глаза java script" Вы должны понимать, что единственным реальным способом защиты вашего вычислительного кода является вычисление на сервере. Я имею в виду, что даже если у вас есть скомпилированный двоичный код, сборка java легко понять для опытного злоумышленника. И обфускация, о которой вы говорили (ее обфускация, а не подпись), делает ее немного сложнее, но все же не невозможно.

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

Просто мои мысли, надеюсь, это поможет вам выбрать лучшее направление здесь...

Ответ 2

По состоянию на сентябрь 2015 года они мертвы для меня. Есть плюсы и минусы использования апплетов. Но Chrome перестает их поддерживать, поэтому, используя их, вы просто не поддерживаете Chrome для рабочего стола, а когда речь идет о мобильных браузерах, какие из них поддерживают NPAPI?

Официальное объявление оракула:

Chrome больше не поддерживает NPAPI (технология, требуемая для апплетов Java) Плагин Java для веб-браузеров полагается на плагин для кросс-платформенных платформ архитектура NPAPI, которая поддерживается всеми основными веб-браузерами на протяжении более десятилетия. Google Chrome версии 45 (планируется выпуск в сентябре 2015 года) снижает поддержку NPAPI, влияя на плагины для Silverlight, Java, Facebook и другие аналогичные NPAPI плагинов.

Java-приложения предлагаются через веб-браузеры как в Интернете (которые не взаимодействуют с браузером, когда они запускаются) или как апплет Java (который может взаимодействовать с браузер). Это изменение не влияет на приложения Web Start, это только влияет на апплеты.

Если у вас есть проблемы с доступом к приложениям Java с помощью Chrome, Oracle рекомендует использовать Internet Explorer (Windows) или Safari (Mac OS X) вместо этого.

EDIT

Microsoft Edge также не поддерживает их. Итак, еще один удар по уже умирающим Java-апплетам.

РЕДАКТИРОВАТЬ 2

Объявление от Mozilla

Важно: новая 64-разрядная версия Firefox для Windows не узнайте или поддержите этот плагин. Смотрите это сообщение в блоге Mozilla для подробности.

Так что да. Java-апплеты мертвы.

РЕДАКТИРОВАТЬ 3 Oracle официально убил их с Java 9

Ответ 3

.. напишите Java-апплет (подписанный, чтобы скрыть код)

Подписание кода - это защита пользователя, а не наша (или защита кода). Он просто добавляет дополнительные файлы. Возможно, вы думаете об обфускации, что затрудняет кражу кода. Фактически, запутанному JS было бы сложнее расшифровать, чем цифровые подписи (но не запутанные) Java-классы.

Единственное реальное решение для защиты кода - оставить важные части на сервере. Вероятно, JS может справиться с большинством, если не для взаимодействия с пользователем/браузером/сервером, поэтому единственная часть, которую может играть Java-апплет, - это визуализация возвращенных (рассчитанных) данных. Даже тогда я, вероятно, буду искать способы показать результат в холсте HTML 5.

Итак, ответ на ваш вопрос..

Java-апплеты - это неправильный выбор сегодня?

Да для этого прецедента. Апплет добавляет немного или ничего по сравнению с тем, что может быть поставлено в чистом JS/Canvas, с помощью grunt, выполняемой на сервере.

Ответ 4

Джон Деметриу представил очень хорошую информацию.

Дополнительно теперь (июль 2017) только Firefox и Internet Explorer (и, возможно, Safari не уверены) позволяют использовать апплеты. Вы можете использовать их, если отвечаете следующим трем требованиям:

  • Вы разрешаете сайту html, который получает доступ к файлу апплета .class как исключение в панели управления java
  • Java обновляется до версии, поддерживаемой браузером (скорее всего, последней версии).
  • Файл .class находится в том же месте, что и ваш html файл!

Вы получаете доступ к java-аплету, введя местоположение html в своем браузере. Вы все еще можете получить приглашение, запрашивающее, запускать ли Java, поэтому просто принимайте.

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

Ответ 5

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

Но если вам нужна только косметика или вычислительная мощность, я думаю, что лучший способ - рефакторинг кода, сделать его легким и чистым, с меньшими условиями, насколько это возможно. Возможно, использование некоторых представлений или SP должно помочь, если у вас есть отдельные серверные машины (например, DB и IIS).

Я заблокирован в проекте, единственным решением которого был апплет,... другим вариантом был ActiveX, но он блокирует мой клиент для IE, и мы не хотим его.

Ответ 6

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

Но с вашим описанием я бы, вероятно, не выбрал апплетов. Это мощная технология, которую я буду использовать с пользовательской базой, которую, как я знаю, установит все, что им нужно, чтобы ее использовать. Это хорошо для игр, сайтов интрасети и т.д. В интранете ИТ-центр может убедиться, что апплет работает на всех настольных компьютерах, которые должны его использовать.

Но в вашем случае я бы использовал Ваадина. Он преобразует Java-приложение в веб-приложения с использованием JavaScript. Кроме того, он защищает ваш код, который является главной особенностью Vaadin. Большая часть вашего кода будет работать как Java-код на сервере, только интерфейс GUI запускается в браузере.

В результате Vaadin намного медленнее, чем Applets (потому что JavaScript). Он также намного медленнее, чем большинство других веб-фреймворков, поскольку он в значительной степени полагался на запуск кода на сервере. Это, конечно, также означает, что ваши вычисления не будут переведены на JavaScript и переданы на клиентский компьютер.

Однако у вас не будет доступа к мощному Swing API. У Vaadin есть свой собственный Swing-подобный API, который охватывает только небольшую часть того, что может сделать Swing. Но, с другой стороны, нет других веб-фреймворков, которые могут делать то, что может сделать Swing.

Невозможно удовлетворить все ваши пожелания. Если вы используете клиент для вычисления, вы будете подвергать свои расчеты. Об этом нет. Даже если вы пишете собственное приложение на С++, оно все равно может быть обращено в обратном порядке и извлечь ваши расчеты. Поэтому я рекомендую вам выполнить ваши расчеты на сервере и найти способ выставления счета пользователю. Это именно то, что вы делаете, если используете Ваадин.

Если вы, с другой стороны, хотите делать расчеты на клиенте, вы ДЕЙСТВИТЕЛЬНО должны использовать Java-апплеты. Java работает быстрее JavaScript, когда дело доходит до расчета. Flash быстрее JavaScript, но Java все еще быстрее.