Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Всем методам, которые изменяют привилегированные данные, разрешают работать асинхронно. Они могут сразу возвратиться, и изменения в конечном счете распространят к персистентной внешней памяти. Метод сброса может использоваться, чтобы вызвать обновления к внешней памяти.
Методы в Привилегированном классе могут быть вызваны одновременно многократными потоками в единственной JVM без потребности во внешней синхронизации, и результаты будут эквивалентны некоторому последовательному выполнению. Если этот класс будет использоваться одновременно многократными JVM, которые хранят их привилегированные данные в той же самой внешней памяти, то хранилище данных не будет повреждено, но никакие другие гарантии не делаются относительно непротиворечивости привилегированных данных.
Для получения дополнительной информации выберите из ссылок:
До введения Привилегированного API разработчики могли хотеть управлять предпочтением и данными конфигурации оперативным способом, при использовании API Свойств или API JNDI как описано ниже.
Часто, предпочтение и данные конфигурации были сохранены в файлах свойств, к которым получают доступ через java.util. API свойств. Однако, нет никаких стандартов как, туда, где такие файлы должны находиться на диске, или что их нужно вызвать. Используя этот механизм, чрезвычайно трудно сделать копию привилегированных данных пользователя, или передать это от одной машины до другого. Как число увеличений приложений, возможность имени файла конфликтует увеличения. Кроме того, этот механизм не имеет справки на платформах, которые испытывают недостаток в локальном диске, или где это является требуемым, что данные хранятся во внешнем хранилище данных (таком как служба каталогов LDAP всего предприятия).
Менее часто, разработчики сохраненная пользовательская настройка и данные конфигурации в службе каталогов, к которой получают доступ через Интерфейс Именования и Каталога Java (JNDI) API. В отличие от API Свойств, JNDI позволяет использование произвольных хранилищ данных (нейтралитет бэкэнда). В то время как JNDI чрезвычайно мощен, это является также довольно большим, состоя из 5 пакетов и 83 классов. JNDI не обеспечивает политики как, туда, где в пространстве имени каталога привилегированные данные должны храниться, или в который пространство имен.
Ни Свойства, ни JNDI не обеспечивают простое, вездесущее, бэкэнд нейтральное привилегированное средство управления. Привилегированный API действительно предоставляет такую услугу, комбинируя простоту Свойств с нейтралитетом бэкэнда JNDI. Это обеспечивает достаточную встроенную политику предотвратить столкновения имени, приемную непротиворечивость, и поощрить устойчивость перед лицом недоступности отступающего хранилища данных.
Материал, содержавшийся в этом разделе, не является частью Привилегированной спецификации API, вместо этого это предназначается, чтобы обеспечить некоторые примеры того, как Привилегированный API мог бы использоваться.
Следующие примеры иллюстрируют, как Вы могли бы получить Привилегированные объекты (система и пользователь) имение отношение к классу включения. Эти примеры работали бы только в методах экземпляра.
Отметьте, что статические заключительные поля, вместо того, чтобы встроить Строковые литералы, используются для ключевых имен (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);
Примеры в предшествующем разделе иллюстрируют Привилегированные объекты получения, имеющие отношение к классу включения, и работе в методах экземпляра. В статическом методе (или статический инициализатор), Вы должны явно обеспечить имя пакета:
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;
}
