Привилегированный FAQ Проекта API

FAQ проекта

Следующее является набором часто задаваемых вопросов относительно проекта Привилегированного API.

Как этот Привилегированный API касается API Свойств?
Это предназначается, чтобы заменить наиболее популярные способы использования Свойств, исправляя многие из его недостатков, сохраняя его легкий вес. При использовании Свойств программист должен явно определить путь для каждого файла свойств, но нет никакого стандартного расположения или соглашения о присвоении имен. Файлы свойств являются "хрупкими", поскольку они являются ручными доступными для редактирования, но легко поврежденные небрежным редактированием. Поддержка нестроковых типов данных в свойствах является несуществующей. Свойства не могут легко использоваться с механизмом персистентности кроме файловой системы. В сумме не масштабируется средство Свойств.
Как Привилегированный API касается JNDI?
Как JNDI, это обеспечивает бэкэнд нейтральный доступ к персистентным данным значения ключа. JNDI, однако, намного более мощен, и соответственно тяжел. JNDI является подходящим для приложений для предприятия, которые нуждаются в его питании. Привилегированный API предназначается как простое, вездесущее, бэкэнд нейтральное средство привилегированного управления, позволяя любому приложению Java легко адаптировать его поведение в соответствии с пользовательскими настройками и поддержать небольшие количества состояния от выполненного, чтобы работать.
Почему делают весь из get методы требуют, чтобы вызывающая сторона передала в значении по умолчанию?
Это вынуждает авторов приложения обеспечить разумные значения по умолчанию, так, чтобы у приложений был разумный шанс выполнения, даже если репозитарий недоступен.
То, как было это, решило, который должны бросить методы BackingStoreException?
Только методы, семантика которых абсолютно требует возможности связаться с внешней памятью, выдают это исключение. У типичных приложений не будет никакой потребности вызвать эти методы. Пока этих методов избегают, приложения будут в состоянии работать, даже если внешняя память будет недоступна, который был явной целью проекта.
Почему этот API не обеспечивает более сильные гарантии относительно параллельного доступа многократным VMs? Точно так же, почему API не позволяет многократным Привилегированным обновлениям быть объединенными в единственную "транзакцию" со все или ничего семантикой?
В то время как API действительно обеспечивает элементарное персистентное хранение данных, он не предназначается вместо базы данных. Является критическим, что возможно реализовать этот API на стандартных репозитариях предпочтения/конфигурации, большинство которых не обеспечивает подобные базе данных гарантии и функциональность. Такие репозитарии оказались соответствующими в целях, в которых предназначается этот API.
Почему у этого API есть чувствительные к регистру ключи и имена узла, в то время как другие API, играющие в подобном пространстве (такие как Microsoft Windows Registry и LDAP), не делают?
Во вселенной программирования Java чувствительные к регистру ключи String являются вездесущими. В частности им обеспечивает класс Свойств, который этот API предназначается, чтобы заменить. Людям весьма свойственно использовать Свойства способом, который требует чувствительность к регистру. Например, имена пакета Java (которые являются чувствительными к регистру) иногда используются в качестве ключей. Это распознается, что это проектное решение усложняет жизнь системного программиста, который реализует Предпочтение на внешней памяти с нечувствительными к регистру ключами, но это считают приемлемой ценой, чтобы заплатить, поскольку гораздо больше программистов будет использовать Привилегированный API, чем реализует это.
Почему этот API не использует Java 2 Платформы Наборов?
Этот API разрабатывается для очень конкретной цели, и оптимизируется с этой целью. В отсутствие универсальных типов (см. JSR-14), API был бы менее удобным для типичных пользователей. Это испытало бы недостаток в безопасности типов времени компиляции, если вызвано, чтобы соответствовать API Map. Кроме того, не ожидается, что функциональная совместимость с другими реализациями Карты будет требоваться (хотя это было бы прямо, чтобы реализовать класс адаптера если это предположение, выпущенное, чтобы быть неправильным). Привилегированный API, проектом, столь подобным Карте, что у программистов, знакомых с последним, не должно быть никаких трудностей, используя прежнего.
Почему не делают помещенного и удаляют возврат методов старые значения?
Это является требуемым, что оба из этих методов являются исполнимой программой, даже если внешняя память недоступна. Это не было бы возможно, если бы они были обязаны возвращать старое значение. Далее, это оказало бы отрицательное влияние производительности, если бы API был реализован на некоторых общих хранилищах данных бэкэнда.
Почему API разрешает, но не требует, сохраненные значения по умолчанию?
Эта функциональность требуется в настройках предприятия для масштабируемого, рентабельного администрирования предпочтения через предприятие, но была бы массовым убийством в самостоятельно назначенной однопользовательской установке.
Почему этот API не содержит методы, чтобы считать и записать произвольные сериализуемые объекты?
Сериализированные объекты несколько хрупки: если версия программы, которая читает такое свойство, отличается от версии, которая записала это, объект, возможно, не десериализовывает должным образом (или вообще). Не невозможно хранить сериализированные объекты, используя этот API, но мы не поощряем это, и не обеспечили метод удобства.
Почему Preferences абстрактный класс, а не интерфейс?
Было решено, что возможность добавить новые методы совместимым снизу вверх способом, перевешиваемым недостаток, что Предпочтение не может использоваться в качестве "mixin" (То есть произвольные классы не могут также быть сделаны служить Привилегированными объектами.) Кроме того, это устраняет потребность в отдельном классе для статических методов. (Интерфейсы не могут содержать статические методы.)

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