Java-апплеты-это неправильный выбор сегодня?
У меня есть нетривиальный вычислительный код, который необходимо применить к данным, уже загруженным в браузер DOM и захваченным из пользовательских взаимодействий. Я не хочу раскрывать этот код. Мне интересно, если:
- напишите веб-сервис и общайтесь с браузером через websocket или http. Компромисс-это скорость взаимодействия (от скользкого до плохого) и более высокие транспортные расходы.
- напишите апплет Java (подписанный, чтобы скрыть код), который инкапсулирует логику внутри страница и пусть JavaScript взаимодействуют с api Java. Я читал в другом месте, что Java и движок JavaScript может тупик в определенных scenarions. Однако, поскольку я только вычисляю, это не проблема. Возможно, на многоядерных машинах я мог бы разделить свою работу, используя несколько потоков.
- запись на JavaScript. Но JavaScript сложно протестировать,и все это на виду.
Q&A, такие как удобство использования Java-апплетов в web и ряд других обескураживающий.
мой вопрос is: являются ли Java-апплеты мертвой технологией. В наши дни даже нет вопросов и ответов на эту тему! Кроме того, Java не всегда может быть в комплекте со всеми браузерами (настольными, планшетными или мобильными)?
есть ли лучшие способы выполнить то же самое, как скрыть код, использовать клиентский процессор/ОЗУ, минимизировать трафик данных?
веб-страницы находятся на Javascript / html5 / css. Сервер только блюда из JSON / XML. Пакеты данных 10-20КБ и часто обновляется. Вычисления дороги и специфичны для клиента, поэтому я бы очень хотел использовать клиента для всего этого.
Спасибо большое.
6 ответов
Я думаю, что самый большой недостаток апплета заключается в том, что он предполагает, что у вас есть JRE, установленный на клиентской машине. Это действительно жизнеспособное предположение? Конечно, вы можете предложить загрузить и установить JRE, но зачем делать все это только для некоторых вычислений? Еще один вопрос, который я бы задал себе, могут ли ваши клиенты быть мобильными телефонами, планшетами и так далее? Если это так,возможно, Java-скрипт-лучший вариант.
и еще 5 центов :) вы упомянули " открыт для глаз Java-скрипт' Вы должны понимать, что единственным реальным способом защиты вашего вычислительного кода является размещение вычислений на сервере. Я имею в виду, что даже если у вас есть скомпилированный двоичный код, сборка java проста для понимания опытного злоумышленника. И обфускация, о которой Вы упомянули (ее обфускация, а не подпись jar) делает его немного сложнее, но все же не невозможно.
единственная проблема, которую я вижу здесь, заключается в том, что если у вас есть много клиентов, которые одновременно выполняют вычисления и вы кладете бремя вычислений на свой сервер, он может рухнуть в конечном итоге.
просто мои мысли, надеюсь, это поможет вам выбрать лучший направление...
по состоянию на сентябрь 2015 они мертвы для меня. Есть плюсы и минусы использования апплетов. Но Chrome перестал их поддерживать, поэтому, используя их, вы просто не поддерживаете Chrome для настольных компьютеров, а когда дело доходит до мобильных браузеров, кто из них поддерживает NPAPI?
официальное объявление oracle:
Chrome больше не поддерживает NPAPI (технология, необходимая для Java-апплетов) Плагин Java для веб-браузеров опирается на кросс-платформенный плагин архитектура NPAPI, который поддерживается всеми основными веб-браузерами больше десяти лет. Chrome от Google версии 45 (планируется к выпуску в сентябре 2015) снижает поддержку NPAPI, влияя на плагины для Silverlight, Java, Facebook видео и другие подобные NPAPI на основе подключаемый модуль.
Java-приложения предлагаются через веб-браузеры как веб - запустите приложение (которое не взаимодействует с браузером, как только они запускаются) или как Java-апплет (который может взаимодействовать с этот броузер.) Это изменение не влияет на приложения Web Start, оно только воздействует на апплеты.
Если у вас возникли проблемы с доступом к Java-приложениям с помощью Chrome, Oracle рекомендует использовать Internet Explorer (Windows) или Safari (Mac OS X) вместо.
редактировать
Microsoft Edge также не поддерживает их. Итак, еще один удар по уже умирающим Java-Апплетам.
изменить 2
объявление от Mozilla
важно: новая 64-разрядная версия Firefox для Windows не распознавать или поддерживать этот плагин. См. это сообщение в блоге Mozilla для подробности.
да. Java-апплеты мертвы.
EDIT 3 Компания Oracle официально убили их С Java 9
..напишите Java-апплет (подписанный, чтобы скрыть код)
подпись кода предназначена для защиты пользователя, а не для нашей (или для защиты кода). Он просто добавляет дополнительные файлы. Возможно, вы думаете об обфускации, что делает его немного более трудным для кражи кода. На самом деле, запутанный JS будет сложнее расшифровать, чем классы Java с цифровой подписью (но не запутанные).
единственное реальное решение здесь для защиты кода-оставить важные детали на сервере. JS, вероятно, может обрабатывать большинство, если не все взаимодействия пользователя/браузера/сервера, поэтому единственная часть Java-апплета может играть в этом для визуализации возвращаемых (вычисляемых) данных. Даже тогда я, вероятно, буду искать способы показать результат на холсте HTML 5.
поэтому ответ на ваш вопрос..
Java-апплеты-это неправильный выбор сегодня?
Да для этого случая использования. Апплет добавляет мало или ничего над тем, что может быть поставлено в чистом JS/Canvas с ворчливой работой, выполняемой на сервере.
Джон Деметриу представил очень хорошую информацию.
кроме того, теперь (июль 2017) только Firefox и Internet Explorer (и, возможно, Safari не уверен) позволяет использовать апплеты. Вы можете использовать их, если выполнены следующие 3 условия:
- вы разрешаете HTML-сайт, который обращается к .файл апплета класса как исключение в панели управления java
- Java обновляется до версии, поддерживаемой браузером (скорее всего, последней версия)
- The .файл класса находится в том же месте, что и ваш html-файл!
вы получаете доступ к апплету java, введя местоположение html в вашем браузере. Вы все еще можете получить приглашение, запрашивающее, запускать ли Java,поэтому просто примите.
Я представил эту информацию только для того, чтобы люди могли запускать апплеты. Однако апплеты были отключены по какой-то причине, они допускают много утечек безопасности. Используйте их только для того, чтобы изучить их технологию и получить некоторое понимание. Они не рекомендуются в других местах.
апплеты всегда будут хорошим выбором, когда вам нужно использовать клиентскую машину, т. е. использовать биометрические решения или аппаратные средства.
но если вам нужна только косметика или вычислительная мощность, я думаю, лучший способ-рефакторинг кода, сделать его легким и чистым, с меньшими условиями, насколько это возможно. Возможно, использование некоторых представлений или SPs должно помочь, если у вас есть отдельные серверные машины (например, DB и IIS).
Я заблокирован в проекте, единственным решением которого было апплет.,.. другим выбором был ActiveX, но он блокирует мой клиент в IE, и мы этого не хотим.
Ну, прежде всего, Java-апплеты-это растущая технология и далеко не мертвая. Во-вторых, установки браузера и пользователя снижаются. Некоторые используют снижающиеся установки, чтобы утверждать, что Java умирает, но это ложь, поскольку всегда было намного меньше фактического использования Java-апплетов, чем установленных плагинов.
но с вашим описанием я бы, вероятно, не выбрал апплеты. Это мощная технология, которую я бы использовал с базой пользователей, которая, как я знаю, установит все они нужны для того, чтобы использовать его. Это хорошо для игр, интранет-сайтов и т. д. В интрасети он может убедиться, что апплет работает на всех рабочих столах, которые должны его использовать.
но в вашем случае я бы использовал фреймворк Vaadin. Он преобразует приложение Java в веб-приложения с использованием JavaScript. Кроме того, он защищает ваш код, который является основной особенностью Vaadin. Большая часть вашего кода будет работать как Java-код на сервере, только интерфейс GUI запускается в браузере.
в результате Ваадин намного медленнее, чем апплеты (потому что JavaScript). Это также намного медленнее, чем большинство других веб-фреймворков, потому что он сильно полагался на выполнение кода на сервере. Это, конечно, также означает, что ваши вычисления не будут переведены на JavaScript и переданы на клиентский компьютер.
однако у вас не будет доступа к мощному API Swing. У Vaadin есть свой собственный Swing-подобный API, который охватывает только небольшую часть того, что может сделать Swing. Но с другой стороны так нет другой веб-фреймворк, который может делать то, что может Swing.
на самом деле нет никакого способа удовлетворить все ваши желания. Если вы используете клиент для вычислений, вы будете выставлять свои вычисления. Это невозможно обойти. Даже если вы пишете собственное приложение на C++, оно все равно может быть обратным и извлечь ваши вычисления. Поэтому я рекомендую вам запустить свои вычисления на сервере и найти способ выставить счет пользователю. Это именно то, что вы делаете, если используете Фреймворк Vaadin.
Если вы, с другой стороны, хотите делать вычисления на клиенте, вы действительно должны использовать Java-апплеты. Java намного быстрее, чем JavaScript, когда дело доходит до вычислений. Flash быстрее JavaScript, но Java по-прежнему намного быстрее.