Spec-Zone .ru
спецификации, руководства, описания, API
|
Java Богатое Руководство по Интернет-приложениям > Руководство разработчика апплета> Плагин Java и Архитектура Апплета
Этот документ описывает, как Плагин Java управляет выполнением апплетов и взаимодействий между апплетами и браузером.
Следующие темы затрагиваются:
С Плагином Java апплеты не выполняются в JVM в браузере. Вместо этого они выполняются в отдельном процессе. Тот же самый процесс JVM может быть совместно использован многократными апплетами, или апплеты могут быть помещены в различные процессы в зависимости от того, соответствуют ли существующие JVM требования апплета и имеют достаточно многие ресурсы, чтобы выполнить апплет. Апплет может запросить определенную версию JRE использоваться и может определить, какие опции нужно передать к JVM. Апплет может также запросить быть выполненным в отдельной JVM.
Браузер и апплет могут все еще связаться друг с другом, как бы то ни было. Существующие API были повторно спроектированы, чтобы использовать сокеты процесса, таким образом, вещи продолжают работать, как они сделали прежде, только лучше. Эта архитектура предоставляет много преимуществ:
С той архитектурой может быть запущен новый JRE всякий раз, когда это необходимо. Но апплет будет работать в существующем JRE пока:
Отметьте:
Если два апплета, каждый требует большого объема памяти, они могли бы оба работать в том же самом JRE, вызывая одного из них исчерпать память. Но это - только беспокойство, когда у Вас есть многократные апплеты, работающие одновременно.
Определенные версии JRE могут быть отмечены как недоступные к плагину, отключая их в Панели управления 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"):
Полагая, что запрос запускает апплет на определенном семействе, новый 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 короткими и избегите циклов обработки, если возможный.
Обычно, если у двух апплетов есть то же самое codebase
и archive
параметры, они будут загружены тем же самым экземпляром загрузчика class. Это поведение требуется для обратной совместимости, и полагается несколькими реальными приложениями. Результат состоит в том, что многократные апплеты на той же самой веб-странице могут получить доступ к статическим переменным друг друга на уровне языка Java, эффективно позволяя многократные апплеты быть записанными, как если бы они включали единственное приложение.
В то время как эта опция позволяет определенным видам приложений быть удобно записанными, у нее есть определенные недостатки. Это вмешивается в завершение апплетов, в особенности когда многократные экземпляры того же самого апплета являются активными. Это делает модель программирования для апплетов более сложной, так как это находится под указанным точно, когда статические поля апплета будут повторно инициализированы, и когда они будут сохраняться от выполненного до выполнения того же самого апплета. Это вызывает неточное поведение определенных операций пользовательского интерфейса в пределах Плагина Java из-за неспособности идентифицировать точно который апплет, инициируемый определенный запрос.
Поэтому Плагин Java обеспечивает способ выбрать из использования classloader кэша на апплете основанием апплета.
Сборка "мусора" сразу происходит на экземпляре апплета после destroy
концы метода. Сборка "мусора" применяется ко всей памяти, полученной апплетом, за исключением статических переменных. Статики сохраняются в classloader кэше, наряду с классами непосредственно, столько, сколько загрузчик class присутствует.
Так, когда загрузчик class уходит? То поведение не определяется. Это до реализации виртуальной машины Java и ее взаимодействий с операционной системой. Можно ожидать это быть сохраненными максимально долго, но быть отброшенными, когда память будет необходима в других целях.
Апплет работает в безопасной песочнице, которая препятствует тому, чтобы он взаимодействовал с пользовательской системой, если не авторизовано. Чтобы получить ту авторизацию, апплет может обеспечить сертификат безопасности, который должен принять пользователь. Сертификат безопасности необходим к:
Основная модель обеспечения безопасности апплета все или ничего суждение. Если Вы получаете сертификат безопасности, можно предоставить полный доступ апплета к системе пользователя. Без этого у апплета нет фактически никакого доступа вообще.
Развертывание апплетов, используя JNLP позволяет им помогать более мелкомодульной модели обеспечения безопасности (подобный Сети Java, Запускают приложения), который предоставляет им управляемый доступ к системе пользователя под управлением пользователя. (Например, возможность сохранить или открыть файл, выбранный пользователем и возможностью напечатать.)
См. Конфигурацию Прокси для деталей.
См. Безопасность для деталей.