Апплеты Java — это небольшие приложения, написанные на языке программирования Java или другом языке программирования , которые компилируются в байт-код Java и предоставляются пользователям в виде байт-кода Java .
На момент их появления, предполагаемое использование состояло в том, чтобы пользователь запускал апплет с веб-страницы , а затем апплет выполнялся в виртуальной машине Java (JVM) в процессе , отдельном от самого веб-браузера . Апплет Java мог появляться в фрейме веб-страницы, новом окне приложения, программе от Sun под названием appletviewer [6] или в качестве автономного инструмента для тестирования апплетов. [ требуется пояснение ]
Java-апплеты были введены в первой версии языка Java, которая была выпущена в 1995 году. Начиная с 2013 года основные веб-браузеры начали постепенно отказываться от поддержки NPAPI , базовой технологии, используемой для запуска апплетов. апплеты стали полностью неработоспособными к 2015–2017 годам. Java-апплеты были объявлены устаревшими в Java 9 в 2017 году. [7] [8] [9] [10] [11]
Апплеты Java обычно писались на Java, но также могли использоваться и другие языки, такие как Jython , JRuby , Pascal , [12] Scala , NetRexx или Eiffel (через SmartEiffel ).
Java-апплеты работают на очень высоких скоростях [ требуется цитата ] и до 2011 года они были во много раз быстрее JavaScript . [ требуется цитата ] В отличие от JavaScript, Java-апплеты имели доступ к 3D- аппаратному ускорению , что делало их хорошо подходящими для нетривиальных, ресурсоемких визуализаций. Поскольку браузеры получили поддержку аппаратно-ускоренной графики благодаря технологии холста (или, в частности, WebGL в случае 3D-графики), [13] [14], а также JavaScript, скомпилированному «на лету» , [15] разница в скорости стала менее заметной. [ требуется цитата ]
Поскольку байт-код Java является кроссплатформенным (или платформенно-независимым), апплеты Java могут выполняться клиентами для многих платформ, включая Microsoft Windows , FreeBSD , Unix , macOS и Linux . Их нельзя запустить на мобильных устройствах, которые не поддерживают запуск стандартного байт-кода Oracle JVM. Устройства Android могут запускать код, написанный на Java, скомпилированный для Android Runtime .
Апплеты используются для предоставления интерактивных функций веб-приложениям, которые не могут быть предоставлены только HTML . Они могут захватывать ввод с мыши , а также иметь элементы управления, такие как кнопки или флажки . В ответ на действия пользователя апплет может изменять предоставленный графический контент. Это делает апплеты хорошо подходящими для демонстрации, визуализации и обучения. Существуют онлайн-коллекции апплетов для изучения различных предметов, от физики до физиологии сердца.
Апплет также может быть только текстовой областью; предоставляя, например, кроссплатформенный интерфейс командной строки для некоторой удаленной системы. При необходимости апплет может покинуть выделенную область и запуститься как отдельное окно. Однако апплеты имеют очень небольшой контроль над содержимым веб-страницы за пределами выделенной области апплета, поэтому они менее полезны для улучшения внешнего вида сайта в целом, в отличие от других типов расширений браузера (хотя известны также апплеты, такие как новостные ленты или редакторы WYSIWYG ). Апплеты также могут воспроизводить медиа в форматах, которые изначально не поддерживаются браузером.
Страницы, закодированные в HTML, могут встраивать в себя параметры, которые передаются апплету. Из-за этого один и тот же апплет может иметь разный вид в зависимости от переданных параметров.
Поскольку апплеты были доступны до HTML5 , современные CSS и JavaScript интерфейс DOM были стандартными, они также широко использовались для тривиальных эффектов, таких как наведение мыши и кнопки навигации. Этот подход, который создавал серьезные проблемы для доступности и неправильного использования системных ресурсов, больше не используется и настоятельно не рекомендовался даже в то время.
Большинство браузеров запускали Java-апплеты в изолированной среде , не позволяя апплетам получать доступ к локальным данным, таким как файловая система . [16] Код апплета загружался с веб-сервера , после чего браузер либо встраивал апплет в веб-страницу, либо открывал новое окно, отображающее пользовательский интерфейс апплета .
Первые реализации включали загрузку класса апплета за классом. Хотя классы представляют собой небольшие файлы, их часто бывает много, поэтому апплеты получили репутацию медленно загружаемых компонентов. Однако с тех пор, как .jarпоявились файлы, апплет обычно поставляется как один файл, имеющий размер, аналогичный файлу изображения (сотни килобайт до нескольких мегабайт).
Системные библиотеки и среды выполнения Java имеют обратную совместимость, что позволяет писать код, который будет работать как в текущих, так и в будущих версиях виртуальной машины Java.
Многие разработчики Java, блоги и журналы рекомендовали использовать технологию Java Web Start вместо апплетов. [17] Java Web Start позволял запускать немодифицированный код апплета, который затем запускался в отдельном окне (не внутри вызывающего браузера).
Иногда сервлет Java неформально сравнивают с серверным апплетом, но он отличается языком, функциями и каждой из описанных здесь характеристик апплетов.
Апплет будет отображаться на веб-странице с использованием устаревшего appletэлемента HTML [18] или рекомендуемого objectэлемента. [19] Элемент embedможет использоваться [20] с браузерами семейства Mozilla ( embedбыл устаревшим в HTML 4, но включен в HTML 5). Он указывает источник и местоположение апплета. Оба тега objectи embedмогут также загружать и устанавливать виртуальную машину Java (если требуется) или, по крайней мере, вести на страницу плагина. Теги appletи objectтакже поддерживают загрузку сериализованных апплетов, которые запускаются в некотором определенном (а не начальном) состоянии. Теги также указывают сообщение, которое отображается вместо апплета, если браузер не может запустить его по какой-либо причине.
Однако, несмотря на то, objectчто в 2010 году он был официально рекомендован, поддержка тега objectеще не была согласованной среди браузеров, и Sun продолжала рекомендовать старый appletтег для развертывания в многобраузерных средах, [21] поскольку он оставался единственным тегом, постоянно поддерживаемым наиболее популярными браузерами. Для поддержки нескольких браузеров использование objectтега для встраивания апплета потребовало бы JavaScript (который распознает браузер и настраивает тег), использование дополнительных тегов, специфичных для браузера, или доставку адаптированного вывода со стороны сервера.
Плагин браузера Java полагался на NPAPI , который почти все поставщики веб-браузеров прекратили поддерживать или не реализуют из-за его возраста и проблем безопасности. В январе 2016 года Oracle объявила, что среды выполнения Java на основе JDK 9 прекратят поддержку плагина браузера. [22]
Апплет Java может иметь любое или все из следующих преимуществ: [23]
Java-апплеты имели следующие недостатки по сравнению с другими клиентскими веб-технологиями:
Sun приложила значительные усилия для обеспечения совместимости между версиями Java по мере их развития, при необходимости законодательно устанавливая переносимость Java. Oracle, похоже, продолжает ту же стратегию.
Иск 1997 года [25] был подан после того, как Microsoft создала собственную модифицированную виртуальную машину Java , которая поставлялась с Internet Explorer. Microsoft добавила около 50 методов и 50 полей [25] в классы в пакетах java.awt, java.lang и java.io. Другие изменения включали удаление возможности RMI и замену Java Native Interface с JNI на RNI , другой стандарт. RMI был удален, потому что он легко поддерживает только коммуникации Java-Java и конкурирует с технологией Microsoft DCOM . Апплеты, которые полагались на эти изменения или просто непреднамеренно использовали их, работали только в системе Java от Microsoft. Sun подала в суд за нарушение товарного знака , поскольку смысл Java заключался в том, что не должно быть никаких фирменных расширений, а код должен работать везде. Microsoft согласилась выплатить Sun 20 миллионов долларов, а Sun согласилась предоставить Microsoft ограниченную лицензию на использование Java без модификаций только в течение ограниченного времени. [26]
Microsoft продолжала поставлять свою собственную немодифицированную виртуальную машину Java. С течением лет она сильно устарела, но все еще использовалась по умолчанию для Internet Explorer. Более позднее исследование показало, что апплеты того времени часто содержат собственные классы, которые в ограниченной степени отражают Swing и другие новые функции. [27] В 2002 году Sun подала антимонопольный иск, утверждая, что попытки Microsoft незаконной монополизации нанесли ущерб платформе Java. Sun потребовала от Microsoft распространить текущую двоичную реализацию технологии Java от Sun как часть Windows, распространить ее как рекомендуемое обновление для старых настольных операционных систем Microsoft и прекратить распространение виртуальной машины Microsoft (поскольку срок ее лицензирования, согласованный в предыдущем иске, истек). [26] Microsoft заплатила 700 миллионов долларов за нерешенные антимонопольные вопросы, еще 900 миллионов долларов за патентные вопросы и 350 миллионов долларов роялти за использование программного обеспечения Sun в будущем. [28] [ необходим неосновной источник ]
Существовало два типа апплетов с очень разными моделями безопасности: подписанные апплеты и неподписанные апплеты. [29] Начиная с Java SE 7 Update 21 (апрель 2013 г.) апплеты и приложения Web-Start рекомендуется подписывать с помощью доверенного сертификата, а при запуске неподписанных апплетов появляются предупреждающие сообщения. [30] Кроме того, начиная с Java 7 Update 51 неподписанные апплеты блокировались по умолчанию; их можно было запустить, создав исключение в панели управления Java. [31]
Ограничения на неподписанные апплеты были поняты как «драконовские»: у них нет доступа к локальной файловой системе, а веб-доступ ограничен сайтом загрузки апплета; также есть много других важных ограничений. Например, они не могут получить доступ ко всем системным свойствам, использовать собственный загрузчик классов , вызывать собственный код , выполнять внешние команды в локальной системе или переопределять классы, принадлежащие основным пакетам, включенным как часть выпуска Java. Хотя они могут работать в автономном фрейме, такой фрейм содержит заголовок, указывающий на то, что это ненадежный апплет. Успешный начальный вызов запрещенного метода автоматически не создает дыру в безопасности, поскольку контроллер доступа проверяет весь стек вызывающего кода, чтобы убедиться, что вызов не исходит из ненадлежащего места.
Как и в случае с любой сложной системой, с момента первого выпуска Java было обнаружено и исправлено множество проблем безопасности. Некоторые из них (например, ошибка безопасности сериализации календаря) существовали много лет, и никто не знал об этом. Другие были обнаружены в использовании вредоносным ПО в дикой природе. [ необходима цитата ]
В некоторых исследованиях упоминаются апплеты, вызывающие сбой браузера или чрезмерное использование ресурсов ЦП , но они классифицируются как неприятности, а не как настоящие недостатки безопасности. Однако неподписанные апплеты могут быть вовлечены в комбинированные атаки, которые используют комбинацию нескольких серьезных ошибок конфигурации в других частях системы. Неподписанный апплет также может быть более опасным для запуска непосредственно на сервере, где он размещен, поскольку, хотя кодовая база позволяет ему общаться с сервером, запуск внутри него может обойти брандмауэр. Апплет также может попытаться провести DoS-атаки на сервер, где он размещен, но обычно люди, управляющие веб-сайтом, также управляют апплетом, что делает это неразумным. Сообщества могут решить эту проблему путем проверки исходного кода или запуска апплетов на выделенном домене.
Неподписанный апплет также может попытаться загрузить вредоносное ПО, размещенное на исходном сервере. Однако он может только сохранить такой файл во временной папке (так как это временные данные) и не имеет средств для завершения атаки путем его выполнения. Были попытки использовать апплеты для распространения эксплойтов Phoenix и Siberia таким образом, [ требуется цитата ], но эти эксплойты не используют Java внутри и также распространялись несколькими другими способами.
Подписанный апплет [32] содержит подпись, которую браузер должен проверить через удаленно работающий независимый сервер центра сертификации . Создание этой подписи требует специализированных инструментов и взаимодействия с обслуживающим сервером центра сертификации. После проверки подписи и одобрения пользователем текущей машины подписанный апплет может получить больше прав, становясь эквивалентным обычной автономной программе. Обоснование заключается в том, что автор апплета теперь известен и будет нести ответственность за любой преднамеренный ущерб. [ неопределенно ] Такой подход позволяет использовать апплеты для многих задач, которые в противном случае были бы невозможны с помощью клиентских скриптов. Однако этот подход требует от пользователя большей ответственности, решая, кому он или она доверяет. Связанные с этим проблемы включают неотзывчивый сервер центра сертификации, неправильную оценку личности подписчика при выдаче сертификатов и известных издателей апплетов, которые все еще делают что-то, что пользователь не одобрил бы. Следовательно, подписанные апплеты, которые появились из Java 1.1, на самом деле могут иметь больше проблем с безопасностью.
Самоподписанные апплеты, которые являются апплетами, подписанными самим разработчиком, могут потенциально представлять угрозу безопасности; плагины Java выдают предупреждение при запросе авторизации для самоподписанного апплета, поскольку функциональность и безопасность апплета гарантируется только самим разработчиком и не была независимо подтверждена. Такие самоподписанные сертификаты обычно используются только во время разработки перед выпуском, когда стороннее подтверждение безопасности неважно, но большинство разработчиков апплетов будут искать стороннюю подпись, чтобы убедиться, что пользователи доверяют безопасности апплета.
Проблемы безопасности Java принципиально не отличаются от аналогичных проблем любой клиентской платформы сценариев [33] [ требуется ссылка ] . В частности, все проблемы, связанные с подписанными апплетами, также применимы к компонентам Microsoft ActiveX .
Начиная с 2014 года самоподписанные и неподписанные апплеты больше не принимаются общедоступными плагинами Java или Java Web Start. Следовательно, у разработчиков, желающих развернуть апплеты Java, нет иного выбора, кроме как приобретать доверенные сертификаты из коммерческих источников.
Существуют альтернативные технологии (например, WebAssembly [34] и JavaScript ), которые удовлетворяют всем или большей части возможностей апплета. JavaScript может сосуществовать с апплетами на одной странице, помогать в запуске апплетов (например, в отдельном фрейме или предоставлять обходные пути платформы) и позже вызываться из кода апплета. По мере того, как JavaScript набирал возможности и производительность, поддержка и использование апплетов снижались, вплоть до их окончательного удаления.
