Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Java-апплет, созданный как дополнительный демонстрационный материал для научной публикации.
Аплет Java, использующий аппаратное ускорение 3D для визуализации файлов 3D в формате .pdb, загруженных с сервера [1]
Использование апплета для нетривиальной анимации, иллюстрирующей биофизическую тему (беспорядочно движущиеся ионы проходят через вентили напряжения) [2]
Использование Java-апплета для вычислений - интенсивная визуализация множества Мандельброта [3]
Скорость бега апплетов достаточна для создания, например, нетривиальных компьютерных игр с шахматами . [4]
NASA World Wind (открытый исходный код) - это приложение второго поколения [5], которое интенсивно использует OpenGL и загрузку данных по требованию для создания подробной трехмерной карты мира.
Веб- доступ к серверной консоли на аппаратном уровне с помощью Java-апплета
Демонстрация обработки изображений с использованием двумерного преобразования Фурье.

Аплеты Java - это небольшие приложения, написанные на языке программирования Java или другом языке программирования, который компилируется в байт-код Java и доставляется пользователям в виде байт-кода Java . Пользователь запускал Java-апплет с веб-страницы , а затем апплет выполнялся на виртуальной машине Java (JVM) в процессе, отдельном от самого веб-браузера . Java , апплет может появиться в кадре веб - страницы, новое окно приложения, Sun «s AppletViewer или автономный инструмент для тестирования апплетов.

Аплеты Java были представлены в первой версии языка Java, которая была выпущена в 1995 году. Начиная с 2013 года, основные веб-браузеры начали постепенно отказываться от поддержки базовых технологических апплетов, используемых для работы , и к 2015 году апплеты перестали работать. –2017. Java-апплеты устарели с Java 9 в 2017 году и удалены из Java SE 11 (18.9), выпущенного в сентябре 2018 года. [6] [7] [8] [9] [10]

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

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

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

Обзор [ править ]

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

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

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

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

Техническая информация [ править ]

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

Java , апплет расширяет класс java.applet.Applet, или в случае Swing - апплета javax.swing.JApplet. Класс, который должен переопределять методы из класса апплета для настройки пользовательского интерфейса внутри себя ( Applet), является потомком, Panelкоторый является потомком Container. Поскольку апплет наследуется от контейнера, он имеет в основном те же возможности пользовательского интерфейса, что и обычное приложение Java, включая области с пользовательской визуализацией.

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

Домен , откуда был загружен апплет исполняемый единственный домен , к которому обычно (без знака) апплета разрешено общаться. Этот домен может отличаться от домена, в котором размещен окружающий HTML-документ.

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

Подобные технологии [ править ]

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

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

Встраивание в веб-страницу [ править ]

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

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

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

Пример [ править ]

В следующем примере показано использование Java-апплетов через пакет java.applet. В примере также используются классы из Java Abstract Window Toolkit (AWT) для вывода сообщения « Hello, world! ».

import  java.applet. * ; import  java.awt. * ;// Код апплета для "Hello, world!" пример. // Это должно быть сохранено в файле с именем "HelloWorld.java". public  class  HelloWorld  extends  Applet  {  // Распечатайте сообщение на экране (x = 20, y = 10).  public  void  paint ( Графика  g )  {  g . drawString ( «Привет, мир!» ,  20 ,  10 ); // Рисуем круг на экране (x = 40, y = 30).  г . drawArc ( 40 ,  30 ,  20 ,  20 ,  0 ,  360 ); // Рисует прямоугольник на экране (x1 = 100, y1 = 100, x2 = 300, y2 = 300).  г . drawRect ( 100 ,  100 ,  300 ,  300 ); // Рисует квадрат на экране (x1 = 100, y1 = 100, x2 = 200, y2 = 200).  г . drawRect ( 100 ,  100 ,  200 ,  200 );  } }

Простые апплеты свободно распространяются в Интернете для настройки приложений, поддерживающих плагины .

После компиляции полученный файл .class можно разместить на веб-сервере и вызвать на HTML- странице с помощью тега <applet> или <object> . Например:

<! DOCTYPE html> < html > < head >  < title > HelloWorld_example.html </ title > </ head > < body >  < h1 > Пример Java-апплета </ h1 >  < p > Вот: < applet  code = "HelloWorld.class"  height = "40"  width = "200" > Здесь запускается HelloWorld.class. </ апплет >  </ p > </ body > </ html >

Когда страница будет открыта, она будет выглядеть следующим образом:

Пример Java-апплета
Вот оно: Привет, мир!

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

< р > Вот: < applet  archive = "example.jar"  code = "HelloWorld"  height = "40"  width = "200" > Здесь запускается HelloWorld.class. </ апплет > </ p >

Включение апплета подробно описано на официальной странице Sun о теге APPLET. [22]

Преимущества [ править ]

Java-апплет может иметь одно или все из следующих преимуществ: [23]

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

Недостатки [ править ]

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

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

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

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

1997: Sun против Microsoft [ править ]

Иск 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]

2002: Sun против Microsoft [ править ]

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 может сосуществовать с апплетами на одной странице, помогать запускать апплеты (например, в отдельном фрейме или предоставлять обходные пути платформы) и позже вызываться из кода апплета. JavaFX - это расширение платформы Java, которое также можно рассматривать как альтернативу.

См. Также [ править ]

  • ActiveX
  • Curl (язык программирования)
  • Сервлет Джакарта
  • Запуск Java Web
  • JavaFX
  • Богатое Интернет-приложение  - несколько платформ для создания интерактивных и / или мультимедийных веб-сайтов
  • WebGL

Ссылки [ править ]

  1. ^ «Домашний сайт программы просмотра белков 3D (Openastexviewer) под LGPL» . Архивировано из оригинала на 1 августа 2009 года . Проверено 21 сентября 2009 года .
  2. ^ "Виртуальный очаг" .
  3. ^ "Домашний сайт апплета множества Мандельброта под GPL" . Архивировано из оригинала 8 мая 2013 года . Проверено 29 июля 2013 года .
  4. ^ "Домашний сайт шахматного апплета под BSD" . Архивировано из оригинала 7 сентября 2009 года.
  5. ^ "Java.Sun.com" .
  6. ^ «Примечания к выпуску Java 9» .
  7. ^ «JEP 289: отказ от API апплета» .
  8. ^ «Блог JPG: переход на Интернет без плагинов» .
  9. ^ «Блог JPG: Дальнейшие обновления« Переход на Интернет без плагинов » » .
  10. ^ http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
  11. ^ "Free Pascal Compiler for JVM" .
  12. ^ "холст - HTML" . Сеть разработчиков Mozilla . Проверено 15 августа 2015 года .
  13. ^ «WebGL - Интерфейсы веб-API» . Сеть разработчиков Mozilla . Проверено 15 августа 2015 года .
  14. ^ «Элементы дизайна - Chrome V8» . Проверено 15 августа 2015 года .
  15. ↑ Шринивас, Рагхаван Н. (6 июля 2001 г.). «Java Web Start приходит на помощь» . JavaWorld . Проверено 13 июля 2020 .
  16. ^ "W3.org" .
  17. ^ "W3.org" .
  18. ^ «Загрузки Java для всех операционных систем» . Java.com. 14 августа 2012 . Проверено 14 июня 2013 года .
  19. ^ "Положение Солнца в тегах апплета и объекта" . Архивировано из оригинала 9 июня 2010 года . Проверено 14 января 2010 года .
  20. ^ Программа запуска Java-апплетов от Oracle - Ссылка сломана! [ постоянная мертвая ссылка ]
  21. ^ «Oracle осуждает плагин для браузера Java, готовится к его прекращению» . Ars Technica . Проверено 15 апреля 2016 года .
  22. ^ Java.Sun.com Страница тегов APPLET от Sun. Архивировано 5 января 2010 г. на Wayback Machine.
  23. ^ Официальный обзор Oracle технологии Java-апплетов
  24. ^ "Как получить Java для мобильного устройства?" . 30 июля 2014 г.
  25. ^ a b Зуковски, Джон (1 октября 1997 г.). «Что иск Sun против Microsoft означает для разработчиков Java?» . JavaWorld . Проверено 13 июля 2020 .
  26. ^ a b «Страница Sun, посвященная судебным искам против Microsoft» .
  27. ^ Kenai.com (2011). Архивировано 23 августа 2011 г. на Wayback Machine. Наиболее частые проблемы, обнаруженные в коде проверенных апплетов.
  28. ^ Страница Microsoft, посвященная Sun - иск Microsoft 2002 г. Архивировано 25 февраля 2010 г. на Wayback Machine
  29. ^ "Объяснение Sun о безопасности апплета" .
  30. ^ "Java Applet & Web Start - подпись кода" . Oracle . Проверено 28 февраля 2014 .
  31. ^ "Что мне делать, когда я вижу запрос безопасности от Java?" . Oracle . Проверено 28 февраля 2014 .
  32. ^ "Informit.com" .
  33. ^ «Честно говоря, сегодня продукт Netscape используют значительно больше пользователей World Wide Web, чем продукт Microsoft, хотя этот разрыв, похоже, сокращается» . www.wiley.com . Проверено 17 марта 2017 года .
  34. ^ «Mozilla пытается сделать Java так, как она должна быть - со спецификацией WASI для всех устройств, компьютеров, операционных систем» . www.theregister.com . Дата обращения 6 октября 2020 .

Внешние ссылки [ править ]

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