Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Этот документ описывает механизм, обеспеченный платформой Java™ для обработки дополнительных пакетов. Дополнительный пакет является группой пакетов, помещенных в корпус в одном или более файлах JAR, которые реализуют API, который расширяет платформу Java. Дополнительные классы пакета расширяют платформу в том смысле, что виртуальная машина может найти и загрузить их без того, что они были на пути class, очень как будто они были классами в базовом API платформы.
Так как дополнительные пакеты расширяют базовый API платформы, их использование должно быть рассудительно применено. Обычно они используются для хорошо стандартизированных интерфейсов, таких как определенные Сообществом Java ProcessSM, хотя это может также быть подходяще для сайта широкие интерфейсы. Дополнительные пакеты являются редко подходящими для интерфейсов, используемых единственным, или маленьким набором приложений.
Кроме того, так как символы, определенные установленными дополнительными пакетами, будут видимы во всех процессах Java, забота должна быть проявлена, чтобы гарантировать, что все видимые символы следуют за соответствующим "обратным доменным именем" и "соглашениями" иерархии class. Например, com.mycompany. MyClass.
Реализация дополнительного пакета может состоять из кода, записанного в языке программирования Java и, реже, специфичный для платформы собственный код. Кроме того, это может включать свойства, каталоги локализации, изображения, сериализированные данные, и другие ресурсы, определенные для дополнительного пакета.
Поддержка дополнительных пакетов в браузерах, таких как Internet Explorer и Навигатор Netscape доступна через Плагин Java. См. Руководство разработчика Апплета для получения дополнительной информации.
Дополнительный пакет является реализацией открытого, стандартного API (примерами дополнительных пакетов от Sun является , , ). Большинство дополнительных пакетов базируется в пространстве имен javax.*, хотя могут быть исключения.
Эта архитектура, так как это позволяет приложениям, апплетам и сервлетам расширять свой собственный путь class, также разрешает упаковывать и развертывать их как многократные файлы JAR.
Каждый дополнительный пакет или приложение состоят по крайней мере из одного файла JAR, содержащего дополнительную декларацию, код и различные ресурсы. Как описано ниже, этот основной файл JAR может также включать дополнительную информацию в свою декларацию, чтобы описать зависимости от других файлов JAR. Инструмент командной строки jar, включенный с JDK, обеспечивает удобное средство упаковки дополнительных пакетов. (См. ссылочные страницы для инструмента jar: Microsoft Windows[] Операционная система Solaris™ (Солярис ОС), Linux[])
Дополнительный пакет или приложение могут обратиться к дополнительным файлам JAR, на которые сошлются от основного JAR, и они могут дополнительно содержать их собственную информацию о зависимостях также.
Пакеты, включающие дополнительные пакеты, нужно назвать на стандартные соглашения о присвоении имен пакета, реализовывая дополнительные пакеты. Эти соглашения обрисовываются в общих чертах в Спецификации языка Java, но требовании, чтобы префикс домена быть определенным во всех прописных буквах был удален. Например, имя пакета com.sun.server является принятой альтернативой COM.sun.server. Уникальное именование пакета рекомендуется, чтобы избежать конфликтов, потому что приложения и дополнительные пакеты могут совместно использовать тот же самый загрузчик class.
Упаковывая дополнительные пакеты, декларация файла JAR может использоваться, чтобы идентифицировать поставщика и информацию о версии (см. Идентификацию Версии Пакета).
Классы для установленных дополнительных пакетов совместно используются всем кодом в той же самой виртуальной машине. Таким образом установленные дополнительные пакеты подобны базовым классам платформы (в rt.jar), но со связанным загрузчиком class и предварительно сконфигурированной политикой безопасности как описано ниже.
Классы для связанных дополнительных пакетов являются частными к загрузчику class приложения, апплета или сервлета. В случае сетевых приложений, таких как апплеты, эти дополнительные пакеты будут автоматически загружены как необходимый. Так как загрузчики class в настоящий момент связываются с кодовой базой, это разрешает многократным апплетам, происходящим из той же самой кодовой базы совместно использовать реализации (JAR). Однако, подписанный связывался, дополнительные пакеты с информацией о версии как описано выше устанавливаются в JRE, и их содержание является доступным всем приложениям, работающим на этом JRE, и является поэтому не частным.
Приложение (или, более широко, файл 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 не были фактически открыты пока не необходимый.
<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. Иначе, 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/security/java.policyПолитика значения по умолчанию для установленного дополнительного пакета, чтобы вести себя тот же самый способ, которым она была бы, если была часть базовой платформы. Это следует из общей потребности в установленном дополнительном пакете, чтобы загрузить собственный код.
Модель обеспечения безопасности Java обеспечивает некоторую безопасность когда установлено, дополнительный код пакета вызывают из недоверяемого кода. Однако дополнительный код пакета должен быть тщательно рассмотрен для потенциальных нарушений защиты везде, где он использует привилегированные блоки.
Удаленно загруженный дополнительный пакет, который должен использовать проверенные в доступе системные службы (такие как файловый ввод-вывод), чтобы функционировать правильно, должен или быть подписан доверяемым объектом или загружен из доверяемого источника.
Консультируйтесь с документацией безопасности Java для получения дальнейшей информации относительно того, как записать дополнительный пакет и код программы, чтобы использовать средства защиты Платформы Java.
*As, используемые на этом веб-сайте, сроки "виртуальная машина Java" или "JVM", означают виртуальную машину для платформы Java.
