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

Архитектура Механизма расширения

Содержание

Введение

Отметьте: Дополнительные пакеты являются новым именем для того, что имело обыкновение быть известным как стандартные расширения. "Механизм расширения" то, что функциональность JDK™ и JRE™, который поддерживает использование дополнительных пакетов.

Этот документ описывает механизм, обеспеченный платформой Java™ для обработки дополнительных пакетов. Дополнительный пакет является группой пакетов, помещенных в корпус в одном или более файлах JAR, которые реализуют API, который расширяет платформу Java. Дополнительные классы пакета расширяют платформу в том смысле, что виртуальная машина может найти и загрузить их без того, что они были на пути class, очень как будто они были классами в базовом API платформы.

Так как дополнительные пакеты расширяют базовый API платформы, их использование должно быть рассудительно применено. Обычно они используются для хорошо стандартизированных интерфейсов, таких как определенные Сообществом Java ProcessSM, хотя это может также быть подходяще для сайта широкие интерфейсы. Дополнительные пакеты являются редко подходящими для интерфейсов, используемых единственным, или маленьким набором приложений.

Кроме того, так как символы, определенные установленными дополнительными пакетами, будут видимы во всех процессах Java, забота должна быть проявлена, чтобы гарантировать, что все видимые символы следуют за соответствующим "обратным доменным именем" и "соглашениями" иерархии class. Например, com.mycompany. MyClass.

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

Поддержка дополнительных пакетов в браузерах, таких как Internet Explorer и Навигатор Netscape доступна через Плагин Java. См. Руководство разработчика Апплета для получения дополнительной информации.

Дополнительный пакет является реализацией открытого, стандартного API (примерами дополнительных пакетов от Sun является JavaServlet, Java3D, JavaManagement). Большинство дополнительных пакетов базируется в пространстве имен javax.*, хотя могут быть исключения.

Механизм Расширения

Архитектура

Механизм расширения разрабатывается, чтобы содержать следующие элементы: Приложения должны поэтому, вообще, быть подготовлены определить и предоставить дополнительные пакеты (и, более широко, библиотеки), что это нуждается. Система предпочтет установленные копии дополнительных пакетов (и библиотеки), если они будут существовать; иначе, это делегирует к загрузчику class приложения, чтобы найти и загрузить дополнительный пакет, на который ссылаются (и библиотека) классы.

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

Каждый дополнительный пакет или приложение состоят по крайней мере из одного файла JAR, содержащего дополнительную декларацию, код и различные ресурсы. Как описано ниже, этот основной файл JAR может также включать дополнительную информацию в свою декларацию, чтобы описать зависимости от других файлов JAR. Инструмент командной строки jar, включенный с JDK, обеспечивает удобное средство упаковки дополнительных пакетов. (См. ссылочные страницы для инструмента jar: Microsoft Windows[] Операционная система Solaris™ (Солярис ОС), Linux[])

Дополнительный пакет или приложение могут обратиться к дополнительным файлам JAR, на которые сошлются от основного JAR, и они могут дополнительно содержать их собственную информацию о зависимостях также.

Пакеты, включающие дополнительные пакеты, нужно назвать на стандартные соглашения о присвоении имен пакета, реализовывая дополнительные пакеты. Эти соглашения обрисовываются в общих чертах в Спецификации языка Java, но требовании, чтобы префикс домена быть определенным во всех прописных буквах был удален. Например, имя пакета com.sun.server является принятой альтернативой COM.sun.server. Уникальное именование пакета рекомендуется, чтобы избежать конфликтов, потому что приложения и дополнительные пакеты могут совместно использовать тот же самый загрузчик class.

Дополнительное Развертывание Пакета

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

Упаковывая дополнительные пакеты, декларация файла JAR может использоваться, чтобы идентифицировать поставщика и информацию о версии (см. Идентификацию Версии Пакета).

Классы для установленных дополнительных пакетов совместно используются всем кодом в той же самой виртуальной машине. Таким образом установленные дополнительные пакеты подобны базовым классам платформы (в rt.jar), но со связанным загрузчиком class и предварительно сконфигурированной политикой безопасности как описано ниже.

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

Связанные Дополнительные Пакеты

Декларация для приложения или дополнительного пакета может определить один или более относительных URL, обращающихся к файлам JAR и каталогам для дополнительных пакетов (и другие библиотеки), что это нуждается. Эти относительные URL будут обработаны относительно кодовой базы, из которой было загружено содержание приложения или дополнительного файла JAR пакета.

Приложение (или, более широко, файл JAR) определяет относительные URL дополнительных пакетов (и библиотеки), что это нуждается через явный атрибут в Class-Path. Это списки атрибутов URL, чтобы искать реализации дополнительных пакетов (или другие библиотеки), если они не могут быть найдены как дополнительные пакеты, установленные на Java узла виртуальный machine*. Эти относительные URL могут включать файлы JAR и каталоги для любых библиотек или ресурсов, необходимых приложению или дополнительному пакету. Относительные URL, не заканчивающиеся '/', как предполагается, обращаются к файлам JAR. Например,

Class-Path: servlet.jar infobus.jar acme/beans.jar images/
Самое большее один заголовок Class-Path может быть определен в декларации файла JAR..

В настоящий момент URL должны быть относительно кодовой базы файла JAR для соображений безопасности. Таким образом отдалите дополнительные пакеты, произойдет из той же самой кодовой базы как приложение.

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

Получающиеся URL используются, чтобы расширить путь class для приложения, апплета, или сервлета, вставляя URL в путь class сразу после URL содержания файла JAR. Опускаются любые двойные URL. Например, учитывая следующий путь class:

a.jar b.jar
Если дополнительный пакет b.jar, содержавший следующий Class-Path, проявляет атрибут:
Class-Path: x.jar a.jar
Затем получающееся приложение путь class было бы следующим:
a.jar b.jar x.jar
Конечно, если бы у x.jar были собственные зависимости тогда, то они были бы добавлены согласно тем же самым правилам и так далее для каждого последующего URL. В фактической реализации зависимости от файла JAR обрабатываются лениво так, чтобы файлы JAR не были фактически открыты пока не необходимый.

Установленные Дополнительные Пакеты

Начинаясь с реализации Sun Java 2 Платформы, файлы JAR установленного дополнительного пакета помещаются в стандартный источник локального кода:
<java-home>\lib\ext                    [Microsoft Windows]
<java-home>/lib/ext                    [Solaris OS, Linux]

Здесь <java-home> ссылается на каталог, где программное обеспечение времени выполнения устанавливается (который является высокоуровневым каталогом JRE или каталогом jre в JDK).

Расположения для установленных дополнительных пакетов могут быть определены через системное свойство java.ext.dirs. Это свойство определяет один или более каталогов, чтобы искать установленные дополнительные пакеты, каждый разделенный File.pathSeparatorChar. Настройка по умолчанию для java.ext.dirs является стандартным каталогом для установленных дополнительных пакетов, как обозначено выше. Для Java 6 и позже, улучшается значение по умолчанию: это снабжается суффиксом путь к специфичному для платформы каталогу, который совместно используется всем JREs (Java 6 или позже) установленный на системе:

%SystemRoot%\Sun\Java\lib\ext          [Microsoft Windows]
/usr/java/packages/lib/ext            [Linux]
/usr/jdk/packages/lib/ext              [Solaris OS]

Установленный дополнительный пакет может также содержать один или более совместно используемые библиотеки (такие как файлы.dll) и исполнимые программы. В дальнейшем <дугу> покажут, но практически должна быть именем архитектуры системы команд, например sparc, sparcv9, i386, и amd64. Они могут быть установлены в одном из двух мест. Первое, которое будет искаться:

<java-home>\bin                        [Microsoft Windows]
<java-home>/lib/<arch>                 [Solaris OS, Linux]

Второй каталог расширения, который будет искаться, применяется только к Java 6 и позже. Как с пакетами Java, собственные библиотеки могут быть установлены в каталогах, которые будут совместно использованы всем Java 6 и позже JREs:

%SystemRoot%\Sun\Java\bin              [Microsoft Windows]
/usr/java/packages/lib/<arch>         [Linux]
/usr/jdk/packages/lib/<arch>           [Solaris OS]

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

По умолчанию установленным дополнительным пакетам в этом стандартном каталоге доверяют. Таким образом, им предоставляют те же самые полномочия, как будто они были базовыми классами платформы (те в rt.jar). Это полномочие значения по умолчанию определяется в системном файле политики (в <java-home>/jre/lib/security/java.policy), но может быть переопределено для определенного дополнительного пакета, добавляя соответствующую запись файла политики (см. Полномочия в JDK).

Отметьте также что, если установленный дополнительный JAR пакета будет подписан доверяемым объектом, то ему предоставят полномочия, связанные с доверяемым подписывающим лицом.

Дополнительная Изоляция Пакета

Файлы JAR и пакеты могут быть дополнительно изолированы, так, чтобы дополнительный пакет или пакет могли осуществить непротиворечивость в пределах версии.

Пакет, изолированный в пределах JAR, определяет, что все классы, определенные в том пакете, должны произойти из того же самого JAR. Иначе, SecurityException бросается.

Изолированный JAR определяет, что все пакеты, определенные тем JAR, изолируются если не переопределено определенно для пакета.

Изолированный пакет определяется через явный атрибут, Sealed, значением которого является true или false (не важный случай). Например,

Name: javax/servlet/internal/
Sealed: true
определяет, что пакет javax.servlet.internal изолируется, и что все классы в том пакете должны быть загружены из того же самого файла JAR.

Если этот атрибут отсутствует, атрибут изоляции пакета является атрибутом содержания файла JAR.

Изолированный JAR определяется через тот же самый явный заголовок, Sealed, со значением снова или true или false. Например,

Sealed: true
определяет, что все пакеты в этом архиве изолируются если явно не переопределено для определенного пакета с атрибутом Sealed в явной записи.

Если этот атрибут отсутствует, файл JAR, как предполагается, не изолируется для назад совместимости. Система тогда значения по умолчанию к исследованию заголовков пакета для того, чтобы изолировать информацию.

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

Изоляция пакета проверяется на установленный так же как загружала дополнительные пакеты, и приведет к SecurityException если нарушено. Кроме того, нулевой пакет не является sealable, таким образом, классы, которые должны быть изолированы, должны быть помещены в их собственные пакеты. 

Дополнительная Безопасность Пакета

Источнику кода для установленного дополнительного пакета (а именно, <java-home>/lib/ext) связали предварительно сконфигурированную политику безопасности с этим. В реализации Sun точный уровень доверия, предоставленный JAR в этом каталоге, определяется стандартным конфигурационным файлом политики безопасности
<java-home>/lib/security/java.policy
Политика значения по умолчанию для установленного дополнительного пакета, чтобы вести себя тот же самый способ, которым она была бы, если была часть базовой платформы. Это следует из общей потребности в установленном дополнительном пакете, чтобы загрузить собственный код.

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

Удаленно загруженный дополнительный пакет, который должен использовать проверенные в доступе системные службы (такие как файловый ввод-вывод), чтобы функционировать правильно, должен или быть подписан доверяемым объектом или загружен из доверяемого источника.

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

Связанные API

Несколько классов в платформе Java поддерживают механизм расширения, включая:

*As, используемые на этом веб-сайте, сроки "виртуальная машина Java" или "JVM", означают виртуальную машину для платформы Java.


Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами