Класс AbstractPreferences

public abstract class AbstractPreferences
extends Preferences

Этот класс предоставляет скелетную реализацию класса Preferences, значительно облегчая задачу его реализации.

Этот класс предназначен только для Preferences. Обычным пользователям Preferences средства не нужно изучать эту документацию. Достаточно документации Preferences.

Реализаторы должны переопределить девять абстрактных методов интерфейса поставщика услуг (SPI): getSpi(String), putSpi(String,String), removeSpi(String), childSpi(String), removeNodeSpi(), keysSpi(), childrenNamesSpi(), syncSpi() и flushSpi(). Все конкретные методы точно определяют, как они реализованы на основе этих методов SPI. Реализатор может по своему усмотрению переопределить один или несколько конкретных методов, если стандартная реализация не удовлетворяет по каким-либо причинам, например, по производительности.

Методы SPI делятся на три группы, касающиеся поведения исключений. Метод getSpi не должен выбрасывать исключения, но это не имеет большого значения, так как любое исключение, брошенное этим методом, будет перехвачено методом get(String,String), который вернёт указанное значение по умолчанию вызывающей стороне.

Методы removeNodeSpi, keysSpi, childrenNamesSpi, syncSpi и flushSpi предназначены для выбрасывания исключения BackingStoreException, и реализация должна бросить это проверяемое исключение, если не может выполнить операцию. Исключение распространяется наружу, вызывая сбой соответствующего метода API.

Остальные методы SPI putSpi(String,String), removeSpi(String) и childSpi(String) имеют более сложное поведение исключений. Они не предназначены для выбрасывания BackingStoreException, так как они, как правило, могут соблюдать свои контракты, даже если хранилище данных недоступно. Это верно, потому что они не возвращают никакой информации, и их эффекты не обязаны стать постоянными до последующего вызова Preferences.flush() или Preferences.sync(). Как правило, эти методы SPI не должны выбрасывать исключения. В некоторых реализациях могут быть обстоятельства, при которых эти вызовы не смогут даже поставить запрошенную операцию в очередь для обработки в будущем. Даже в этих обстоятельствах, как правило, лучше просто проигнорировать вызов и вернуть значение, а не выбрасывать исключение. Однако в этих обстоятельствах последующий вызов flush() или sync не подразумевает, что все предыдущие операции были успешно сделаны постоянными.

Существует одно обстоятельство, при котором putSpi, removeSpi and childSpi должен выбрасывать исключение: если вызывающей стороне не хватает достаточных привилегий в операционной системе для выполнения запрошенной операции. Это, например, произойдет на большинстве систем, если не обладающий привилегиями пользователь пытается изменить системные настройки. (Необходимые привилегии будут различаться в разных реализациях. В некоторых реализациях это право изменения содержимого некоторого каталога в файловой системе; в других — право изменения содержимого некоторого ключа в реестре). В любом из этих случаев было бы, как правило, нежелательно, чтобы программа продолжала выполнение, как если бы эти операции стали постоянными в более позднее время. Хотя реализации не обязаны выбрасывать исключение в этих обстоятельствах, им рекомендуется это делать. Соответствующим исключением было бы SecurityException.

Большинство методов SPI требуют, чтобы реализация читала или записывала информацию в узле настроек. Реализатор должен быть осторожен, так как другая виртуальная машина может одновременно удалить этот узел из хранилища данных. Ответственность реализации состоит в том, чтобы воссоздать узел, если он был удален.

Примечание для реализации: В стандартных реализациях Preferences от Sun идентичность пользователя наследуется от операционной системы и не меняется на протяжении всего срока службы виртуальной машины. Признается, что у Preferences реализаций на стороне сервера может меняться идентичность пользователя от запроса к запросу, неявно передаваемая методам Preferences с помощью статического экземпляра ThreadLocal. Авторы таких реализаций настоятельно рекомендуют определять пользователя в момент доступа к настройкам (например, методом get(String,String) или put(String,String)), а не постоянно связывать пользователя с каждым экземпляром Preferences. Такое поведение противоречит стандартному использованию Preferences и приведёт к значительной путанице.