Java-апплет

Java-апплет, созданный в качестве дополнительного демонстрационного материала для научной публикации.

Java-апплет, использующий аппаратное 3D-ускорение для визуализации 3D-файлов в формате .pdb, загруженных с сервера.

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

Использование Java-апплета для вычислений – интенсивная визуализация множества Мандельброта.

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

NASA World Wind (с открытым исходным кодом) — апплет второго поколения. это интенсивно использует OpenGL и загрузку данных по требованию для создания подробной трехмерной карты мира.

Веб- доступ к консоли сервера на аппаратном уровне с помощью Java-апплета

Демонстрация обработки изображений с использованием двумерного преобразования Фурье

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

На момент их появления предполагалось, что пользователь сможет запустить апплет с веб-страницы , а затем выполнить апплет на виртуальной машине Java (JVM) в процессе, отдельном от самого веб-браузера . Java-апплет может появиться в рамке веб-страницы, в новом окне приложения, в программе Sun под названием appletviewer, или автономный инструмент для тестирования апплетов.

Java-апплеты были представлены в первой версии языка Java, выпущенной в 1995 году. Начиная с 2013 года основные веб-браузеры начали постепенно отказываться от поддержки NPAPI , базовой технологии, используемой для запуска. к 2015–2017 годам апплеты станут полностью невозможными для запуска. Java-апплеты устарели в Java 9 в 2017 году.

Java-апплеты обычно писались на Java, но и на других языках, таких как Jython , JRuby , Pascal , Scala , NetRexx или Eiffel (через SmartEiffel Также можно использовать ).

Java-апплеты работают на очень высокой скорости. и до 2011 года они были во много раз быстрее JavaScript . В отличие от JavaScript, апплеты Java имели доступ к аппаратному 3D-ускорению , что делало их хорошо подходящими для нетривиальных визуализаций с интенсивными вычислениями. Поскольку браузеры получили поддержку графики с аппаратным ускорением благодаря технологии Canvas (или, в частности, WebGL в случае 3D-графики), а также своевременно скомпилированный JavaScript, разница в скорости стала менее заметной.

Поскольку байт-код Java является кросс-платформенным (или платформо-независимым), Java-апплеты могут выполняться клиентами для многих платформ, включая Microsoft Windows , FreeBSD , Unix , macOS и Linux . Их нельзя было запустить на мобильных устройствах, которые не поддерживают выполнение стандартного байт-кода Oracle JVM. Устройства Android могут запускать код, написанный на Java, скомпилированный для среды выполнения Android .

Обзор

Аплеты используются для предоставления веб-приложениям интерактивных функций, которые не могут быть реализованы только с помощью HTML . Они могут захватывать ввод данных с помощью мыши , а также имеют элементы управления, такие как кнопки или флажки . В ответ на действия пользователя апплет может изменить предоставленное графическое содержимое. Это делает апплеты хорошо подходящими для демонстрации, визуализации и обучения. Существуют онлайн-коллекции апплетов для изучения различных предметов: от физики до физиологии сердца.

Апплет также может представлять собой только текстовую область; предоставление, например, кросс-платформенного интерфейса командной строки для какой-либо удаленной системы. При необходимости апплет может покинуть выделенную область и запуститься в отдельном окне. Однако апплеты имеют очень мало контроля над содержимым веб-страницы за пределами выделенной области апплета, поэтому они менее полезны для улучшения внешнего вида сайта в целом, в отличие от других типов расширений браузера апплеты, такие как тикеры новостей или редакторы WYSIWYG (хотя также известны ). Аплеты также могут воспроизводить мультимедиа в форматах, которые изначально не поддерживаются браузером.

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

Поскольку апплеты были доступны до HTML5 , современный CSS и JavaScript интерфейс DOM был стандартным, они также широко использовались для тривиальных эффектов, таких как наведение курсора мыши и кнопки навигации. Этот подход, который создавал серьезные проблемы с доступностью и неправильным использованием системных ресурсов, больше не используется и даже в то время категорически не одобрялся.

Техническая информация

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

Первые реализации включали загрузку апплета по классам. Хотя классы представляют собой небольшие файлы, их часто бывает много, поэтому апплеты получили репутацию медленно загружающихся компонентов. Однако, поскольку .jar файлы были представлены, апплет обычно поставляется как один файл, размер которого аналогичен размеру файла изображения (от сотен килобайт до нескольких мегабайт).

Java Системные библиотеки и среды выполнения обратно совместимы, что позволяет писать код, который работает как на текущих, так и на будущих версиях виртуальной машины Java.

Похожие технологии

Многие разработчики Java, блоги и журналы рекомендовали использовать технологию Java Web Start вместо апплетов. Java Web Start позволял запускать немодифицированный код апплета, который затем запускался в отдельном окне (не внутри вызывающего браузера).

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

Встраивание в веб-страницу

Апплет будет отображаться на веб-странице с использованием устаревшего метода applet HTML-элемент, или рекомендуемый object элемент. embed элемент можно использовать с браузерами семейства Mozilla ( embed устарел в HTML 4, но включен в HTML 5). Это указывает источник и местоположение апплета. Оба object и embed теги также могут загрузить и установить виртуальную машину Java (при необходимости) или хотя бы вести на страницу плагина. applet и object теги также поддерживают загрузку сериализованных апплетов, которые запускаются в каком-то конкретном (а не начальном) состоянии. Теги также определяют сообщение, которое отображается вместо апплета, если браузер по какой-либо причине не может его запустить.

Однако, несмотря на object будучи официально рекомендуемым тегом в 2010 году, поддержка object Тег еще не был единообразен для всех браузеров, и Sun продолжала рекомендовать более старый applet тег для развертывания в мультибраузерных средах, поскольку он оставался единственным тегом, постоянно поддерживаемым наиболее популярными браузерами. Для поддержки нескольких браузеров используйте object для встраивания апплета потребуется JavaScript (который распознает браузер и настраивает тег), использование дополнительных тегов, специфичных для браузера, или предоставление адаптированного вывода со стороны сервера.

Плагин браузера Java основывался на NPAPI , поддержку которого почти все производители веб-браузеров удалили или не реализовали из-за его возраста и проблем с безопасностью. В январе 2016 года Oracle объявила, что среды выполнения Java на основе JDK 9 прекратят поддержку подключаемого модуля браузера.

Преимущества

Java-апплет может иметь любые или все из следующих преимуществ:

• Было просто заставить его работать на FreeBSD, Linux, Microsoft Windows и macOS, то есть сделать его кроссплатформенным. Апплеты поддерживались большинством веб-браузеров в первое десятилетие 21 века; однако с тех пор большинство браузеров отказались от поддержки апплетов по соображениям безопасности.
• Один и тот же апплет будет работать одновременно со «всеми» установленными версиями Java, а не только с последней версией плагина . Однако если апплету требуется более поздняя версия среды выполнения Java (JRE), клиент будет вынужден ждать во время большой загрузки.
• Большинство веб-браузеров кэшируют апплеты, поэтому они быстро загружаются при возвращении на веб-страницу. Апплеты также улучшились по мере использования: после запуска первого апплета JVM уже работала, а последующие апплеты запускались быстро (JVM необходимо будет перезапускать каждый раз, когда браузер запускается заново). JRE версии 1.5 и выше перезапускали JVM, когда браузер перемещался между страницами, в качестве меры безопасности, которая устраняла этот прирост производительности.
• Работа была перенесена с сервера на клиент , что сделало веб-решение более масштабируемым в зависимости от количества пользователей/клиентов.
• Если отдельная программа (например, Google Earth ) взаимодействует с веб-сервером, этот сервер обычно должен поддерживать все предыдущие версии для пользователей, которые не обновляли свое клиентское программное обеспечение. Напротив, браузер загружает (и кэширует) последнюю версию апплета, поэтому нет необходимости поддерживать устаревшие версии.
• Апплет, естественно, поддерживал изменение состояния пользователя, например положения фигур на шахматной доске.
• Разработчики могли разрабатывать и отлаживать апплет напрямую, просто создавая основную процедуру (либо в классе апплета, либо в отдельном классе) и вызывая init() и start() в апплете, что позволяет вести разработку в их любимой Java SE. среде разработки . Все, что нужно было сделать, — это повторно протестировать апплет в программе AppletViewer или веб-браузере, чтобы убедиться, что он соответствует ограничениям безопасности.
• апплет Недоверенный не имел доступа к локальному компьютеру и может получить доступ только к серверу, с которого он пришел. Это делает апплеты более безопасными для запуска, чем собственные исполняемые файлы, которые они могли бы заменить. Однако подписанный апплет может иметь полный доступ к машине, на которой он работает, если пользователь согласился.
• Java-апплеты были быстрыми и имели производительность, аналогичную изначально установленному программному обеспечению.

Недостатки

Java-апплеты имели следующие недостатки по сравнению с другими клиентскими веб-технологиями:

• Аплеты Java будут зависеть от среды выполнения Java (JRE), сложного и тяжеловесного программного пакета. Им также обычно требуется плагин для веб-браузера. В некоторых организациях разрешено устанавливать только программное обеспечение, установленное администратором. В результате пользователи не могли просматривать апплеты, если только один из них не был достаточно важным, чтобы оправдать обращение к администратору с просьбой установить JRE и плагин.
• Если для апплета требуется более новая версия JRE, чем доступна в системе, пользователю, запускающему его в первый раз, придется дождаться завершения большой загрузки JRE.
• Мобильные браузеры на iOS или Android вообще никогда не запускают Java-апплеты. Еще до прекращения поддержки апплетов на всех платформах настольные браузеры прекратили поддержку Java-апплетов одновременно с появлением мобильных операционных систем.
• Не существовало стандарта, позволяющего сделать содержимое апплетов доступным для программ чтения с экрана. Таким образом, апплеты ухудшают доступность веб-сайта для пользователей с особыми потребностями.
• Как и в случае с любыми сценариями на стороне клиента, ограничения безопасности затрудняли или даже делали невозможным достижение желаемых целей некоторыми ненадежными апплетами. Только отредактировав файл java.policy в установке JAVA JRE, можно было предоставить доступ к локальной файловой системе или системному буферу обмена, а также к сетевым источникам, отличным от того, который обслуживал апплет в браузере.
• Большинству пользователей не важна разница между ненадежными и доверенными апплетами, поэтому это различие не сильно помогает с точки зрения безопасности. Чтобы исправить эту проблему, возможность запуска ненадежных апплетов в конечном итоге была полностью удалена, прежде чем были удалены все апплеты.

Иски, связанные с совместимостью

Компания Sun приложила значительные усилия для обеспечения совместимости между версиями Java по мере их развития, обеспечивая при необходимости переносимость Java по закону. Oracle, похоже, продолжает ту же стратегию.

1997: Sun против Microsoft

Иск 1997 года, было подано после того, как Microsoft создала собственную модифицированную виртуальную машину Java , которая поставлялась с Internet Explorer. Microsoft добавила около 50 методов и 50 полей в классы java.awt, java.lang и java.io. пакетов Другие модификации включали удаление возможности RMI и замену собственного интерфейса Java с JNI на RNI , другой стандарт. RMI был удален, поскольку он легко поддерживает связь Java с Java и конкурирует с технологией Microsoft DCOM . Апплеты, которые полагались на эти изменения или просто случайно использовали их, работали только в системе Java Microsoft. Sun подала в суд за нарушение прав на товарный знак , поскольку идея Java заключалась в том, что не должно быть проприетарных расширений и код должен работать везде. Microsoft согласилась выплатить Sun 20 миллионов долларов, а Sun согласилась предоставить Microsoft ограниченную лицензию на использование Java только без модификаций и в течение ограниченного времени.

2002: Сан против Microsoft

Microsoft продолжала поставлять собственную немодифицированную виртуальную машину Java. С годами он сильно устарел, но все еще используется в Internet Explorer по умолчанию. Более позднее исследование показало, что апплеты того времени часто содержат свои собственные классы, которые отражают Swing и другие новые функции. ограниченным образом В 2002 году Sun подала антимонопольный иск, утверждая, что попытки Microsoft незаконной монополизации нанесли ущерб платформе Java. Sun потребовала от Microsoft распространить текущую бинарную реализацию технологии Java от Sun как часть Windows, распространить ее в качестве рекомендуемого обновления для старых настольных операционных систем Microsoft и прекратить распространение виртуальной машины Microsoft (поскольку срок ее лицензирования, согласованный в предыдущем иске, истек истекший). Microsoft заплатила 700 миллионов долларов за нерешенные антимонопольные вопросы, еще 900 миллионов долларов за патентные проблемы и 350 миллионов долларов роялти за использование программного обеспечения Sun в будущем.

Безопасность

Существовало два типа апплетов с совершенно разными моделями безопасности: подписанные апплеты и неподписанные апплеты. Начиная с версии Java SE 7, обновление 21 (апрель 2013 г.), апплеты и приложения Web-Start рекомендуется подписывать доверенным сертификатом, а при запуске неподписанных апплетов появляются предупреждающие сообщения. Кроме того, начиная с Java 7 Update 51 неподписанные апплеты по умолчанию блокировались; их можно запустить, создав исключение на панели управления Java.

Без подписи

Ограничения на неподписанные апплеты воспринимались как «драконовские»: они не имели доступа к локальной файловой системе, а доступ в Интернет ограничивался сайтом загрузки апплетов; есть также много других важных ограничений. Например, они не могут получить доступ ко всем свойствам системы, использовать собственный загрузчик классов , вызывать собственный код , выполнять внешние команды в локальной системе или переопределять классы, принадлежащие базовым пакетам, включенным в состав выпуска Java. Хотя они могут работать в отдельном фрейме, такой фрейм содержит заголовок, указывающий, что это ненадежный апплет. Успешный первоначальный вызов запрещенного метода не создает автоматически дыру в безопасности, поскольку контроллер доступа проверяет весь стек вызывающего кода, чтобы убедиться, что вызов не поступает из неправильного места.

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

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

Неподписанный апплет также может попытаться загрузить вредоносное ПО, размещенное на исходном сервере. Однако он может хранить такой файл только во временной папке (поскольку это временные данные) и не имеет возможности завершить атаку, выполнив его. Были попытки использовать апплеты для распространения эксплойтов Феникса и Сибири таким образом. но эти эксплойты не используют Java внутри себя, а также распространялись несколькими другими способами.

Подписано

Подписанный апплет содержит подпись, которую браузер должен проверить через удаленно работающий независимый сервер центра сертификации . Создание этой подписи включает в себя специализированные инструменты и взаимодействие с обслуживающим сервером. Как только подпись проверена и пользователь текущей машины также ее одобряет, подписанный апплет может получить больше прав, становясь эквивалентом обычной автономной программы. Причина в том, что автор апплета теперь известен и будет нести ответственность за любой умышленный ущерб. Этот подход позволяет использовать апплеты для многих задач, которые в противном случае были бы невозможны с помощью сценариев на стороне клиента. Однако такой подход требует от пользователя большей ответственности при принятии решения, кому он или она доверяет. Связанные с этим проблемы включают в себя не отвечающий на запросы авторитетный сервер, неправильную оценку личности подписывающего лица при выдаче сертификатов, а также известные издатели апплетов, которые все еще делают что-то, что пользователь не одобрит. Следовательно, подписанные апплеты, появившиеся в Java 1.1, на самом деле могут иметь больше проблем с безопасностью.

Самоподписанный

Самоподписанные апплеты, то есть апплеты, подписанные самим разработчиком, потенциально могут представлять угрозу безопасности; Плагины Java выдают предупреждение при запросе авторизации для самоподписанного апплета, поскольку функциональность и безопасность апплета гарантируются только самим разработчиком и не были подтверждены независимо. Такие самозаверяющие сертификаты обычно используются только во время разработки перед выпуском, когда стороннее подтверждение безопасности не имеет значения, но большинство разработчиков апплетов будут искать стороннюю подпись, чтобы гарантировать, что пользователи доверяют безопасности апплета.

Проблемы безопасности Java принципиально не отличаются от аналогичных проблем любой клиентской скриптовой платформы. . В частности, все проблемы, связанные с подписанными апплетами, также относятся и к Microsoft ActiveX компонентам .

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

Альтернативы

Существуют альтернативные технологии (например, WebAssembly и JavaScript ), которые удовлетворяют всем или более возможностям апплета. JavaScript может сосуществовать с апплетами на одной странице, помогать запускать апплеты (например, в отдельном фрейме или предоставлять обходные пути платформы), а затем вызываться из кода апплета. По мере расширения возможностей и производительности JavaScript поддержка и использование апплетов сокращались вплоть до их окончательного удаления.

См. также

• ActiveX
• Curl (язык программирования)
• Джакартский сервлет
• Веб-старт Java
• JavaFX
• Богатое веб-приложение
• ВебГЛ

Внешние ссылки

• Последняя версия виртуальной машины Java от Sun Microsystems (включает плагины для браузера для запуска Java-апплетов в большинстве веб-браузеров).
• Информация о написании апплетов от Oracle
• Демонстрационные апплеты от Sun Microsystems ( JDK 1.4 – включая исходный код)