Java-апплеты представляли собой небольшие приложения , написанные на языке программирования Java или другом языке программирования , который компилируется в байт-код Java и доставляется пользователям в виде байт-кода Java . Пользователь запускал Java-апплет с веб-страницы , а затем апплет выполнялся на виртуальной машине Java (JVM) в процессе , отдельном от самого веб-браузера . Java-апплет может появиться во фрейме веб-страницы, в новом окне приложения, в программе Sun под названием appletviewer [6] или в автономном инструменте для тестирования апплетов. [ нужны разъяснения ]
Java-апплеты были представлены в первой версии языка Java, выпущенной в 1995 году. Начиная с 2013 года основные веб-браузеры начали постепенно отказываться от поддержки базовых технологических апплетов, используемых для запуска , и к 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 , что делало их хорошо подходящими для нетривиальных визуализаций с интенсивными вычислениями. Поскольку браузеры получили поддержку графики с аппаратным ускорением благодаря технологии Canvas (или, в частности, WebGL в случае 3D-графики), [13] [14] , а также JIT-компилируемому JavaScript, [15] разница в скорости стало менее заметно. [ нужна цитата ]
Поскольку байт-код Java является кросс-платформенным (или платформо-независимым), Java-апплеты могут выполняться клиентами для многих платформ, включая Microsoft Windows , FreeBSD , Unix , macOS и Linux . Их нельзя было запустить на мобильных устройствах, которые не поддерживают выполнение стандартного байт-кода Oracle JVM. Устройства Android могут запускать код, написанный на Java, скомпилированный для среды выполнения Android .
Аплеты используются для предоставления веб-приложениям интерактивных функций, которые не могут быть реализованы только с помощью HTML . Они могут захватывать ввод данных с помощью мыши , а также имеют элементы управления, такие как кнопки или флажки . В ответ на действия пользователя апплет может изменить предоставленное графическое содержимое. Это делает апплеты хорошо подходящими для демонстрации, визуализации и обучения. Существуют онлайн-коллекции апплетов для изучения различных предметов: от физики до физиологии сердца.
Апплет также может представлять собой только текстовую область; предоставление, например, кросс-платформенного интерфейса командной строки для какой-либо удаленной системы. При необходимости апплет может покинуть выделенную область и запуститься в отдельном окне. Однако апплеты имеют очень мало контроля над содержимым веб-страницы за пределами выделенной области апплета, поэтому они менее полезны для улучшения внешнего вида сайта в целом, в отличие от других типов расширений браузера (хотя также известны апплеты, такие как тикеры новостей или редакторы WYSIWYG ). Апплеты также могут воспроизводить мультимедиа в форматах, которые изначально не поддерживаются браузером.
Страницы, закодированные в HTML, могут включать в себя параметры, передаваемые в апплет. Из-за этого один и тот же апплет может иметь разный внешний вид в зависимости от переданных параметров.
Поскольку апплеты были доступны до HTML5 , современный интерфейс DOM CSS и JavaScript был стандартным, они также широко использовались для тривиальных эффектов, таких как наведение курсора мыши и кнопки навигации. Этот подход, который создавал серьезные проблемы с доступностью и неправильным использованием системных ресурсов, больше не используется и даже в то время категорически не одобрялся.
Большинство браузеров запускали 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 с 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, обновление 21 (апрель 2013 г.), апплеты и приложения Web-Start рекомендуется подписывать доверенным сертификатом, а при запуске неподписанных апплетов появляются предупреждающие сообщения. [30] Кроме того, начиная с Java 7 Update 51 неподписанные апплеты по умолчанию блокировались; их можно запустить, создав исключение на панели управления Java. [31]
Ограничения на неподписанные апплеты воспринимались как «драконовские»: они не имели доступа к локальной файловой системе, а доступ в Интернет ограничивался сайтом загрузки апплетов; есть также много других важных ограничений. Например, они не могут получить доступ ко всем свойствам системы, использовать собственный загрузчик классов , вызывать собственный код , выполнять внешние команды в локальной системе или переопределять классы, принадлежащие базовым пакетам, включенным в состав выпуска Java. Хотя они могут работать в отдельном фрейме, такой фрейм содержит заголовок, указывающий, что это ненадежный апплет. Успешный первоначальный вызов запрещенного метода не создает автоматически дыру в безопасности, поскольку контроллер доступа проверяет весь стек вызывающего кода, чтобы убедиться, что вызов не поступает из неправильного места.
Как и в любой сложной системе, с момента первого выпуска Java было обнаружено и исправлено множество проблем безопасности. Некоторые из них (например, ошибка безопасности сериализации календаря) сохранялись в течение многих лет, и никто об этом не знал. Другие были обнаружены при использовании вредоносных программ в дикой природе. [ нужна цитата ]
В некоторых исследованиях упоминается, что апплеты приводят к сбою браузера или чрезмерному использованию ресурсов ЦП , но это классифицируется как помеха, а не как настоящая угроза безопасности. Однако неподписанные апплеты могут быть вовлечены в комбинированные атаки, использующие комбинацию нескольких серьезных ошибок конфигурации в других частях системы. Неподписанный апплет также может быть более опасным при запуске непосредственно на сервере, на котором он размещен, поскольку, хотя база кода позволяет ему взаимодействовать с сервером, запуск внутри него может обойти брандмауэр. Апплет также может попытаться осуществить DoS-атаку на сервер, на котором он размещен, но обычно люди, управляющие веб-сайтом, также управляют апплетом, что делает это неразумным. Сообщества могут решить эту проблему путем проверки исходного кода или запуска апплетов на выделенном домене.
Неподписанный апплет также может попытаться загрузить вредоносное ПО, размещенное на исходном сервере. Однако он может хранить такой файл только во временной папке (поскольку это временные данные) и не имеет возможности завершить атаку, выполнив его. Были попытки использовать апплеты для распространения эксплойтов Phoenix и Сибири таким образом, [ нужна ссылка ] , но эти эксплойты не используют Java внутри себя, а также распространялись несколькими другими способами.
Подписанный апплет [32] содержит подпись, которую браузер должен проверить через удаленно работающий независимый сервер центра сертификации . Создание этой подписи включает в себя специализированные инструменты и взаимодействие с обслуживающим сервером. Как только подпись проверена и пользователь текущей машины также ее одобряет, подписанный апплет может получить больше прав, становясь эквивалентом обычной автономной программы. Причина в том, что автор апплета теперь известен и будет нести ответственность за любой умышленный ущерб. [ расплывчато ] Этот подход позволяет использовать апплеты для многих задач, которые в противном случае были бы невозможны с помощью сценариев на стороне клиента. Однако такой подход требует большей ответственности от пользователя, решающего, кому он доверяет. Связанные с этим проблемы включают в себя не отвечающий на запросы авторитетный сервер, неправильную оценку личности подписывающего лица при выдаче сертификатов, а также известные издатели апплетов, которые все еще делают что-то, что пользователь не одобрит. Следовательно, подписанные апплеты, появившиеся в Java 1.1, на самом деле могут иметь больше проблем с безопасностью.
Самоподписанные апплеты, то есть апплеты, подписанные самим разработчиком, потенциально могут представлять угрозу безопасности; Плагины Java выдают предупреждение при запросе авторизации для самоподписанного апплета, поскольку функциональность и безопасность апплета гарантируются только самим разработчиком и не были подтверждены независимо. Такие самозаверяющие сертификаты обычно используются только во время разработки перед выпуском, когда стороннее подтверждение безопасности не имеет значения, но большинство разработчиков апплетов будут искать стороннюю подпись, чтобы гарантировать, что пользователи доверяют безопасности апплета.
Проблемы безопасности Java принципиально не отличаются от аналогичных проблем любой клиентской платформы сценариев [33] [ нужна цитация ] . В частности, все проблемы, связанные с подписанными апплетами, также относятся и к компонентам Microsoft ActiveX .
С 2014 года самоподписанные и неподписанные апплеты больше не принимаются общедоступными плагинами Java или Java Web Start. Следовательно, у разработчиков, желающих развернуть Java-апплеты, нет альтернативы, кроме как получить доверенные сертификаты из коммерческих источников.
Существуют альтернативные технологии (например, WebAssembly [34] и JavaScript ), которые полностью или в большей степени удовлетворяют возможностям апплета. JavaScript может сосуществовать с апплетами на одной странице, помогать запускать апплеты (например, в отдельном фрейме или предоставлять обходные пути платформы), а затем вызываться из кода апплета. По мере расширения возможностей и производительности JavaScript поддержка и использование апплетов сокращались вплоть до их окончательного удаления.
