Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Всем методам, которые изменяют привилегированные данные, разрешают работать асинхронно. Они могут сразу возвратиться, и изменения в конечном счете распространят к персистентному запоминающему устройству. Метод сброса может использоваться, чтобы вызвать обновления к запоминающему устройству.
Методы в Предпочтении, class может быть вызван одновременно многократными потоками в единственной JVM без потребности во внешней синхронизации, и результатами, будут эквивалентны некоторому последовательному выполнению. Если этот class будет использоваться одновременно многократными JVM, которые хранят их привилегированные данные в том же самом запоминающем устройстве, то хранилище данных не будет повреждено, но никакие другие гарантии не делаются относительно непротиворечивости привилегированных данных.
Для получения дополнительной информации выберите из ссылок:
До введения Привилегированного API разработчики могли хотеть управлять предпочтением и данными конфигурации оперативным способом, при использовании API Свойств или API JNDI как описано ниже.
Часто, предпочтение и данные конфигурации были сохранены в файлах свойств, к которым получают доступ через java.util. API свойств. Однако, нет никаких стандартов как, туда, где такие файлы должны находиться на диске, или что их нужно вызвать. Используя этот механизм, чрезвычайно трудно сделать копию привилегированных данных пользователя, или передать это от одной машины до другого. Как число увеличений приложений, возможность имени файла конфликтует увеличения. Кроме того, этот механизм не имеет справки на платформах, которые испытывают недостаток в локальном диске, или где это является требуемым, что данные хранятся во внешнем хранилище данных (таком как служба каталогов LDAP всего предприятия).
Менее часто, разработчики сохраненная пользовательская настройка и данные конфигурации в службе каталогов, к которой получают доступ через Интерфейс Именования и Каталога Java (JNDI) API. В отличие от API Свойств, JNDI позволяет использование произвольных хранилищ данных (нейтралитет бэкэнда). В то время как JNDI чрезвычайно мощен, это является также довольно большим, состоя из 5 пакетов и 83 классов. JNDI не обеспечивает политики как, туда, где в пространстве имени каталога привилегированные данные должны храниться, или в который пространство имен.
Ни Свойства, ни JNDI не обеспечивают простое, вездесущее, бэкэнд нейтральное привилегированное средство управления. Привилегированный API действительно предоставляет такую услугу, комбинируя простоту Свойств с нейтралитетом бэкэнда JNDI. Это обеспечивает достаточную встроенную политику предотвратить столкновения имени, приемную непротиворечивость, и поощрить устойчивость перед лицом недоступности отступающего хранилища данных.
Материал, содержавшийся в этом разделе, не является частью Привилегированной спецификации API, вместо этого это предназначается, чтобы обеспечить некоторые примеры того, как Привилегированный API мог бы использоваться.
Следующие примеры иллюстрируют, как Вы могли бы получить Привилегированные объекты (система и пользователь) имение отношение к включению class. Эти примеры работали бы только в методах экземпляра.
Отметьте, что статические заключительные поля, вместо того, чтобы встроить Строковые литералы, используются для ключевых имен (NUM_ROWS и NUM_COLS). Это уменьшает вероятность ошибок времени выполнения от типографских ошибок на ключевые имена.
Отметьте также, что разумные значения по умолчанию обеспечиваются для каждого из привилегированных полученных значений. Эти значения по умолчанию будут возвращены, если никакое привилегированное значение не было установлено, или если запоминающее устройство недоступно.
package com.acme.widget;
import java.util.prefs.*;
public class Gadget {
// Preference keys for this package
private static final String NUM_ROWS = "num_rows";
private static final String NUM_COLS = "num_cols";
void foo() {
Preferences prefs = Preferences.userNodeForPackage(Gadget.class);
int numRows = prefs.getInt(NUM_ROWS, 40);
int numCols = prefs.getInt(NUM_COLS, 80);
...
}
}
Вышеупомянутый пример получает предпочтение в расчёте на пользователя. Если единственное, значение на систему требовалось, первая строка в foo был бы заменен:
Preferences prefs = Preferences.systemNodeForPackage(Gadget.class);
Примеры в предшествующем разделе иллюстрируют Привилегированные объекты получения, имеющие отношение к включению class, и работа в методах экземпляра. В статическом методе (или статический инициализатор), Вы должны явно обеспечить имя пакета:
Static String ourNodeName = "/com/acme/widget";
static void foo() {
Preferences prefs = Preferences.userRoot().node(ourNodeName);
...
}
Всегда приемлемо получить объект установок системы однажды в статическом инициализаторе, и использовать это всякий раз, когда установки системы требуются:
static Preferences prefs = Preferences.systemRoot().node(ourNodeName);
Вообще, приемлемо сделать ту же самую вещь для объекта пользовательских настроек, но не, если рассматриваемый код должен использоваться в сервере, в чем многочисленные пользователи будут работать одновременно или последовательно. В такой системе, userNodeForPackage и userRoot возвратит соответствующий узел для пользователя вызова, таким образом является критическим что звонки userNodeForPackage или userRoot будьте сделаны из соответствующего потока в подходящее время. Если часть кода может в конечном счете использоваться в такой серверной среде, это - хорошая, консервативная практика, чтобы сразу получить объекты пользовательских настроек прежде, чем они будут использоваться, как в предшествующем примере.
Привилегированный API не обеспечивает базу данных как "транзакции" в чем, многократное предпочтение изменяется атомарно. Иногда, необходимо изменить два или больше предпочтения как модуль. Например, предположите, что Вы храните x и координаты y, куда окно должно быть помещено. Единственный способ достигнуть атомарности состоит в том, чтобы сохранить оба значения в единственном предпочтении. Много кодировок возможны. Вот простой:
int x, y;
...
prefs.put(POSITION, x + "," + y);
Когда такое "составное предпочтение" читается, оно должно декодироваться. Для устойчивости допуски должны быть сделаны для поврежденного (unparseable) значением:
static int X_DEFAULT = 50, Y_DEFAULT = 25;
void baz() {
String position = prefs.get(POSITION, X_DEFAULT + "," + Y_DEFAULT);
int x, y;
try {
int i = position.indexOf(',');
x = Integer.parseInt(coordinates.substring(0, i));
y = Integer.parseInt(position.substring(i + 1));
} catch(Exception e) {
// Value was corrupt, just use defaults
x = X_DEFAULT;
y = Y_DEFAULT;
}
...
}
У типичного кода программы нет никакой потребности знать, доступно ли запоминающее устройство. Это должно почти всегда быть доступно, но если это не, код должен продолжать выполнять значения по умолчанию использования вместо привилегированных значений от запоминающего устройства. Очень редко некоторая усовершенствованная программа могла бы хотеть изменить свое поведение (или просто отказаться работать), если бы запоминающее устройство было недоступно. Следующее является методом, который определяет, доступно ли запоминающее устройство, пытаясь изменить привилегированное значение и сбросить результат к запоминающему устройству.
private static final String BACKING_STORE_AVAIL = "BackingStoreAvail";
private static boolean backingStoreAvailable() {
Preferences prefs = Preferences.userRoot().node("<temporary>");
try {
boolean oldValue = prefs.getBoolean(BACKING_STORE_AVAIL, false);
prefs.putBoolean(BACKING_STORE_AVAIL, !oldValue);
prefs.flush();
} catch(BackingStoreException e) {
return false;
}
return true;
}
