Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

Плагин Java™ и Архитектура Апплета

Руководство разработчика апплета> Плагин Java и Архитектура Апплета

Содержание

• Архитектура
  • Среда выполнения Java
  • Выбор Версии Среды выполнения Java
  • Соображения потока
  • Кэш Classloader и Взаимодействие между Апплетами
  • Сборка "мусора" апплета
  • Полномочия апплета
  • Конфигурация прокси
  • Безопасность
• Лучшие Методы для Разработки Апплета

Этот документ описывает, как Плагин Java следующего поколения, представленный в Java SE 6 обновлений 10 выпусков, управляет выполнением апплетов и взаимодействий между апплетами и браузером.

Архитектура

Среда выполнения Java

С плагином Java апплеты не выполняются в JVM в браузере. Вместо этого они выполняются в отдельном процессе. Тот же самый процесс JVM может быть совместно использован многократными апплетами, или апплеты могут быть помещены в различные процессы в зависимости от того, соответствуют ли существующие JVM требования апплета и имеют достаточно многие ресурсы, чтобы выполнить апплет. Апплет может запросить определенную версию JRE использоваться и может определить, какие опции нужно передать к JVM. Апплет может также запросить быть выполненным в отдельной JVM.

Браузер и апплет могут все еще связаться друг с другом, как бы то ни было. Существующие API были повторно спроектированы, чтобы использовать сокеты процесса, таким образом, вещи продолжают работать, как они сделали прежде - только лучше. Эта архитектура предоставляет много преимуществ:

• Апплеты, которые требуют различных версий JRE, могут работать одновременно. 
• Апплеты могут определить параметры запуска JRE, такие как размер "кучи". (Новый апплет использует существующий JRE, если это - требования, подмножество существующего JRE, иначе, новый экземпляр JRE запускается.) 
• Интерфейсы передачи сообщений пишутся в Java, таким образом, они работают на всех поддерживаемых платформах, таким же образом, таким образом, совместимость перекрестного браузера улучшается.

С той архитектурой может быть запущен новый JRE всякий раз, когда это необходимо. Но апплет будет работать в существующем JRE пока:

1. Версия JRE, требуемая апплетом, соответствует существующий JRE, и
2. Параметры запуска JRE удовлетворяют требования апплета

Отметьте:

• Если два апплета, каждый требует большого объема памяти, они могли бы оба работать в том же самом JRE, вызывая одного из них исчерпать память. Но это - только беспокойство, когда у Вас есть многократные апплеты, работающие одновременно.
   
• Определенные версии JRE могут быть отмечены как недоступные к плагину, отключая их в Панели управления Java.

Выбор Версии Среды выполнения Java

На всех платформах новый Плагин Java определяет местоположение JREs, чтобы использовать от записей, перечисленных в Панели управления Java (вкладка "Java", кнопка "View" при "Настройках Времени выполнения Апплета Java"). Доступные JREs в этом списке кодируются в deployment.properties файл, расположение которого зависимо от платформы. На платформе Windows это обычно располагается в C:\Documents and Settings\[username]\Application Data\Sun\Java\Deployment. На платформах Unix это обычно располагается в ~/.java/deployment/deployment.properties.

На платформах Windows и Панель управления Java и новый Плагин Java автоматически обнаружат установленный JREs и добавят их к доступному набору. На платформах Unix не поддерживается автоматическое обнаружение установленного JREs. Диалоговое окно Настроек Времени выполнения Апплета Java в Панели управления Java может использоваться, чтобы вручную добавить JREs к известному списку для нового Плагина Java.

По умолчанию новый Плагин Java выполнит все апплеты в последней версии JRE, названной в этом списке. Это только выполнит апплет на более ранней версии JRE если явно требующийся.

Полагая, что запрос запускает апплет на определенной версии JRE (например, определенный выпуск обновления как "1.5.0_11"):

1. Со списком доступного JREs консультируются. Если есть точное совпадение строки версии, что версия JRE выбирается. Иначе, если есть один или более установленный JREs в том же самом семействе, последняя версия выбирается. Иначе, последний доступный JRE на машине выбирается.
2. Выбранная версия JRE сравнивается с базовой линией безопасности для семейства. Если это равно или более свежо чем та версия, никакой дальнейший запрос не делается, и апплет запускается.
3. Иначе, код для апплета загружается в экземпляре JVM выбранной версии JRE. Если апплет подписывается, и пользователь принимает диалоговое окно безопасности для апплета (или источнику кода уже доверяли), никакой дальнейший запрос не делается, и апплет запускается.
4. Иначе, мы имеем дело с апплетом без знака на "более старой" версии JRE. Диалоговое окно представляется, указывая, что этот апплет запрашивает работать сверху более старого выпуска JRE, и спрашивает пользователя, хочет ли он или она позволить это. Если пользователь щелкает "по да", апплет запускается. Если пользователь щелкает "по нет", апплет повторно запускается сверху последней доступной версии JRE.

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

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

Соображения потока

Механизм интерпретатора JavaScript веб-браузера является единственным потоком. Плагин Java способен к управлению многократными потоками. Плагин Java создает отдельный рабочий поток для каждого апплета. Сами апплеты могут быть многопоточными. Апплеты, делающие JavaScript к вызовам Java и наоборот, должны быть разработаны с потоком связанные проблемы в памяти.

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

Когда интерпретатор JavaScript неактивен, Плагин Java выполняется, JavaScript к Java обращаются на рабочий поток апплета (Интерпретатор JavaScript Не Занятый сценарий).

Когда Java к вызову Javascript происходит, и JavaScript к вызову Java делается, последний выполняется на том же самом потоке, который сделал Java к вызову JavaScript (Сценарий цикла обработки).

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

Чтобы избежать потока связанные проблемы особенно, когда многократные апплеты работают одновременно, сохраните и Java к JavaScript и JavaScript к вызовам Java короткими и избегите циклов обработки, если возможный.

Кэш Classloader и Взаимодействие между Апплетами

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

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

Поэтому новый Плагин Java обеспечивает способ выбрать из использования classloader кэша на апплете основанием апплета.

Сборка "мусора" апплета

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

Так, когда загрузчик класса уходит? То поведение не определяется. Это до реализации виртуальной машины Java и ее взаимодействий с операционной системой. Можно ожидать это быть сохраненными максимально долго, но быть отброшенными, когда память будет необходима в других целях.

Полномочия апплета

Апплет работает в безопасной песочнице, которая препятствует тому, чтобы он взаимодействовал с пользовательской системой, если не авторизовано. Чтобы получить ту авторизацию, апплет может обеспечить сертификат безопасности, который должен принять пользователь. Сертификат безопасности необходим к:

• Печать
• Получите доступ к файловой системе
• Cookie браузера доступа
• Получите доступ к другим системным ресурсам

Основная модель обеспечения безопасности апплета все или ничего суждение. Если Вы получаете сертификат безопасности, можно предоставить полный доступ апплета к системе пользователя. Без этого у апплета нет фактически никакого доступа вообще.

Развертывание апплетов, используя JNLP позволяет им помогать более мелкомодульной модели обеспечения безопасности (подобный Java веб-приложения Запуска), который предоставляет им управляемый доступ к системе пользователя под управлением пользователя. (Например, возможность сохранить или открыть файл, выбранный пользователем и возможностью напечатать.)

Конфигурация прокси

См. Конфигурацию Прокси в Руководстве по Развертыванию Java для деталей.

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

См. Безопасность в Руководстве по Развертыванию Java для деталей.

---

Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.

Свяжитесь с Нами