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