Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

Объектные Улучшения Сериализации
в Предыдущих Выпусках

Следующее является улучшениями к сериализации до Java™ SE Комплект разработчика 6 (JDK). Для улучшений в текущем выпуске см. Изменения Сериализации и Улучшения в Java Комплект разработчика 6 SE.

Поддержка сериализации экземпляров перечислимого типа (начиная с 5.0)

Поддержка была добавлена к сериализации, чтобы обработать перечислимые типы, которые новы в версии 5.0. Правила для того, чтобы сериализировать перечислимый экземпляр отличаются от тех для того, чтобы сериализировать "обычный" сериализуемый объект: сериализированная форма перечислимого экземпляра состоит только из его перечислимого постоянного имени, наряду с информацией, идентифицирующей его основной перечислимый тип. Поведение десериализации отличается также - информация о class используется, чтобы найти соответствующий перечислимый class, и Enum.valueOf метод вызывают с тем, что class и полученное постоянное имя, чтобы получить перечислимую константу, чтобы возвратиться.

Исправление ошибки: java.io. StreamCorruptedException, брошенный из-за java.lang. ClassNotFoundException (начиная с 5.0)

В предыдущих выпусках, запускающихся с версии 1.4.0, a ClassNotFoundException брошенный ObjectInputStream.readClassDescriptor метод был бы отражен к высокоуровневой вызывающей стороне ObjectInputStream.readObject как a StreamCorruptedException с пустой причиной. Это теперь отражается к высокоуровневой вызывающей стороне как InvalidClassException с оригиналом ClassNotFoundException как причина.

Исправление ошибки: поток, ожидающий на java.io. ObjectStreamClass$EntryFuture для уведомления от [так] (начиная с 5.0)

В предыдущих выпусках, запускающихся с версии 1.4.0, ObjectStreamClass.lookup метод мог мертвая блокировка если вызвано изнутри статического инициализатора class, представленного методом Class параметр. Мертвая блокировка больше не должна произойти в этом случае.

Исправление ошибки: никакая спецификация для serialVersionUID (начиная с 5.0)

javadoc для Serializable интерфейс был расширен, чтобы более полностью определить роль и использование serialVersionUIDs, и подчеркнуть потребность определить явный serialVersionUIDs для сериализуемых классов.

Поддержка десериализации неразделенных объектов (начиная с 1.4)

Сериализация теперь оказывает дополнительную поддержку для десериализации объектов, которые, как известно, неразделены в потоке сериализации данных. Новая поддержка оказывается следующими дополнениями API в пакете java.io:

• ObjectInputStream.readUnshared()
• ObjectOutputStream.writeUnshared(Object obj)
• ObjectStreamField(String name, Class type, boolean unshared)

Эти API могут использоваться, чтобы более эффективно считать содержавшие объекты массива безопасным способом.

Права доступа, теперь требуемые переопределять putFields, readFields (начиная с 1.4)

Начиная с J2SE 1.4.0, общедоступный конструктор ObjectOutputStream с одним параметром требует "enableSubclassImplementation" SerializablePermission когда вызвано (любой прямо или косвенно) подклассом, который переопределяет ObjectOutputStream.putFields или ObjectOutputStream.writeUnshared.

Также начиная с J2SE 1.4.0, общедоступный конструктор ObjectInputStream с одним параметром требует "enableSubclassImplementation" SerializablePermission когда вызвано (любой прямо или косвенно) подклассом, который переопределяет ObjectInputStream.readFields или ObjectInputStream.readUnshared.

Эти изменения не будут влиять на значительное большинство приложений. Однако, это будет влиять на любые подклассы ObjectInputStream/ObjectOutputStream, которые переопределяют методы putFields ИЛИ readFields, также не переопределяя остальную часть инфраструктуры сериализации.

Поддержка class - определила readObjectNoData метод (начиная с 1.4)

В дополнение к поддержке class - определенные методы writeObject() И readObject(), сериализация теперь включает поддержку class - определенные методы readObjectNoData(). Каждый class - определенный метод readObjectNoData() обязан иметь следующую подпись:

private void readObjectNoData() throws ObjectStreamException;

Метод readObjectNoData() походит на class - определенный метод readObject(), за исключением того, что (если определено) это вызывают в случаях, где дескриптор class для суперкласса десериализовываемого объекта (и следовательно объектные данные, описанные, что дескриптор class), не присутствует в потоке сериализации. Более формально: Если объект O class C десериализовывается, и S является суперклассом C в VM, который десериализовывает O, то S.readObjectNoData() вызывается ObjectInputStream во время десериализации O, если и только если следующие условия являются истиной:

1. S реализует java.io. Сериализуемый (прямо или косвенно).
2. S определяет метод readObjectNoData() с помощью упомянутой выше подписи.
3. Поток сериализации, содержащий O, не включает дескриптор class для S среди его списка дескрипторов суперкласса для C.

Отметьте, что readObjectNoData() никогда не вызывается в случаях, где class - определенный метод readObject() можно было вызвать, хотя сериализуемые конструкторы class могут вызвать readObjectNoData() изнутри readObject() как средство консолидации кода инициализации.

См. описание class в спецификации API ObjectInputStream для получения дополнительной информации.

Исправление ошибки: Десериализация перестала работать для объекта Класса типа примитива (начиная с 1.4)

В предыдущих выпусках, ошибка 4171142 вызванных попытки десериализовать объекты Класса типов примитивов перестать работать с ClassNotFoundException. Проблема состояла в том, что ObjectInputStream.resolveClass() не работал на дескрипторы ObjectStreamClass для типов примитивов. Эта ошибка исправляется в J2SE 1.4.0.

Исправление ошибки: ObjectInputStream.resolveProxyClass может перестать работать для непубличных случаев интерфейса (начиная с 1.4)

В предыдущих выпусках ObjectInputStream.resolveProxyClass не всегда выбирал бы надлежащий загрузчик class, чтобы определить прокси class в том, если бы один или больше интерфейсов прокси были непубличными. В этом выпуске, если ObjectInputStream.resolveProxyClass обнаруживает непубличный интерфейс, он пытается определить прокси реализации class в том же самом загрузчике class как интерфейс (запрещающий конфликты, когда исключение выдается), который необходим для прокси реализовать интерфейс.

Исправление ошибки: Недопустимое serialPersistentFields имя поля вызывает NullPointerException (начиная с 1.4)

В предыдущих выпусках, ошибка 4387368 вызванных NullPointerExceptions, которые будут брошены, сериализируя объекты, которые использовали сериализацию значения по умолчанию, но также и объявили serialPersistentField записи, которые не отображались на фактические поля class. Сериализация теперь бросит InvalidClassExceptions в такие случаи (так как никогда не необходимо определить такой "не имеющий поддержки" serialPersistentFields при использовании сериализации значения по умолчанию).

Исправление ошибки: ClassNotFoundException в пропущенных объектах заставляет сериализацию перестать работать (начиная с 1.4)

В предыдущих выпусках ClassNotFoundExceptions, инициированный "пропущенными" объектами - объекты, связанные с полями, не существующими в классах, загруженных стороной десериализации - заставили бы десериализацию всего графа объектов перестать работать, даже при том, что пропущенные значения не будут включены в график. Этот выпуск сериализации рассматривает эту проблему, игнорируя ClassNotFoundExceptions, связанный с такими пропущенными объектами, таким образом устраняя class ненужных ошибок десериализации. Другие разные изменения были также произведены, чтобы улучшить полную устойчивость сериализации относительно ClassNotFoundExceptions, с которым встречаются во время десериализации.

Строки дольше чем 64 K могут теперь быть сериализированы (начиная с 1.3)

До 1.3, попытка сериализировать строку дольше чем 64 K привела бы к a java.io.UTFDataFormatException брошенный. В 1.3, протокол сериализации был улучшен, чтобы позволить строкам дольше чем 64 K быть сериализированными. Отметьте, что, если 1.2 (или ранее) JVM пытается считать длинную строку, записанную из совместимой с 1.3 JVM, 1.2 (или ранее) JVM получит a java.io.StreamCorruptedException.

Улучшения производительности сериализации (начиная с 1.3)

Несколько изменений были произведены в сериализации, чтобы улучшить общую производительность:

• Строковые чтения/записи UTF были оптимизированы, чтобы уменьшить ненужные издержки выделения памяти и синхронизации/вызова метода.
• Код для чтения и записи примитивных массивов данных был оптимизирован. Плавание и двойные чтения/записи массива были повторно реализованы, чтобы минимизировать число звонков в собственные методы.
• Внутренняя буферизация была улучшена.
• Отражающие операции для того, чтобы получить/установить примитивные значения полей были обработаны в пакетном режиме, чтобы минимизировать число отдельных собственных вызовов метода.

Улучшенное создание отчетов исключения (начиная с 1.3)

Если class не может быть найден во время процесса разрешения class десериализации, оригинала java.lang.ClassNotFoundException бросается вместо универсального так, чтобы больше информации об отказе было доступно. Кроме того, исключение десериализации, сообщающее теперь, включает поддержание имени исходного class, который не мог быть найден вместо того, чтобы сообщить о высокоуровневом class, который десериализовывался. Например, если (в вызове RMI) тупиковый class может быть найден, но удаленный интерфейс, class не может, механизм сериализации теперь сообщит правильно, что интерфейс, class был class, который не мог быть найден вместо того, чтобы ошибочно сообщить, что тупиковый class не мог быть найден.

java.io.ObjectOutputStream.writeClassDescriptor,
java.io.ObjectInputStream.readClassDescriptor (начиная с 1.3)

writeClassDescriptor и readClassDescriptor методы были добавлены, чтобы обеспечить средство настройки сериализированного представления java.io.ObjectStreamClass Дескрипторы class. writeClassDescriptor вызывается когда экземпляр java.io.ObjectStreamClass потребности, которые будут сериализированы, и, ответственны за запись ObjectStreamClass к потоку сериализации. Наоборот, readClassDescriptor вызывается когда ObjectInputStream ожидает ObjectStreamClass экземпляр как следующий элемент в потоке сериализации. Переопределяя эти методы, подклассы ObjectOutputStream и ObjectInputStream может передать дескрипторы class в специализированном формате. Для получения дополнительной информации обратитесь к разделам 2.1 и 3.1 из Спецификации Сериализации Объекта Java.

java.io.ObjectOutputStream.annotateProxyClass,
java.io.ObjectInputStream.resolveProxyClass (начиная с 1.3)

Эти методы подобны в цели ObjectOutputStream.annotateClass и ObjectInputStream.resolveClass, за исключением того, что они применяются к динамическим прокси-классам (см. java.lang.reflect.Proxy), в противоположность непрокси-классам. Подклассы ObjectOutputStream может переопределить annotateProxyClass хранить пользовательские данные в потоке наряду с дескрипторами для динамических прокси-классов. ObjectInputStream подклассы могут тогда переопределить resolveProxyClass использовать пользовательские данные в выборе локального class, чтобы связать с данным прокси дескриптор class. Для получения дополнительной информации см. раздел 4 из Спецификации Сериализации Объекта Java.

javadoc теги инструмента @serial, @serialField, и @serialData (начиная с 1.2)

Теги javadoc @serial, @serialField, и @serialData были добавлены, чтобы обеспечить способ задокументировать сериализированную форму class. Javadoc генерирует спецификацию сериализации, основанную на содержании этих тегов. Для получения дополнительной информации отошлите к разделу 1.6 из Спецификации Сериализации Объекта Java.

Управление версиями протокола (начиная с 1.2)

До 1.2, объектная сериализация, используемая протокол, который не поддерживал перескакивающие объекты, реализовывая java.io.Externalizable взаимодействуйте через интерфейс, если классы для тех объектов не были доступны. В 1.2, была добавлена новая версия протокола, который адресовал этот недостаток. Для назад совместимости, ObjectOutputStream и ObjectInputStream может считать и записать потоки сериализации, записанные в любом протоколе; используемая версия протокола может быть выбрана, вызывая ObjectOutputStream.useProtocolVersion метод. Для получения дополнительной информации и обсуждение проблем совместимости, см. раздел 6.3 из Спецификации Сериализации Объекта Java.

Определенный с помощью класса writeReplace и readResolve методы (начиная с 1.2)

С тех пор 1.2, классы могут определить writeReplace и readResolve методы, которые позволяют экземплярам данных классов назначать замены на себя во время сериализации и десериализации. Необходимые подписи этих методов, наряду с более подробной информацией, описываются в разделах 2.5 и 3.6 из Спецификации Сериализации Объекта Java.

java.io.ObjectOutputStream.writeObjectOverride, java.io.ObjectInputStream.readObjectOverride (начиная с 1.2)

С тех пор 1.2, подклассы ObjectOutputStream и ObjectInputStream может реализовать пользовательский протокол сериализации, переопределяя writeObjectOverride и readObjectOverride методы. Отметьте, что эти методы только вызовут если ObjectOutputStream/ObjectInputStream подклассы обладают разрешением java.io.SerializablePermission("enableSubclassImplementation"), и вызовите конструкторов без параметров ObjectOutputStream/ObjectInputStream. См. разделы 2.1 и 3.1 из Спецификации Сериализации Объекта Java для получения дополнительной информации.

Проверки права доступа (начиная с 1.2)

Подклассы ObjectOutputStream и ObjectInputStream может переопределить наследованные методы, чтобы получить "рычаги" в определенные аспекты процесса сериализации. С тех пор 1.2, объектная сериализация использует 1.2 модели обеспечения безопасности, чтобы проверить, что подклассы обладают соответствующими полномочиями, чтобы переопределить определенные рычаги. Полномочия java.io.SerializablePermission("enableSubclassImplementation") и java.io.SerializablePermission("enableSubstitution"), управляют действительно ли методы ObjectOutputStream.writeObjectOverride, ObjectOutputStream.replaceObject, ObjectInputStream.readObjectOverride, и ObjectInputStream.resolveObject будет вызван в течение сериализации. См. разделы 2.1 и 3.1 из Спецификаций Сериализации Объекта Java для получения дополнительной информации.

Определение сериализуемых полей для class (начиная с 1.2)

По умолчанию значения всех нестатических и непереходных полей сериализуемого class пишутся, когда экземпляр того, что class сериализируется. В 1.2, новый механизм был представлен, чтобы позволить классам более прекрасное управление этого процесса. Объявляя специальное поле serialPersistentFields, сериализуемые классы могут продиктовать, какие поля будут записаны, когда экземпляры class (или подклассы) будут сериализированы. Эта опция также позволяет классам "определить" сериализуемые поля, которые не соответствуют непосредственно фактическим полям в class. Используемый в соединении с сериализуемым полевым API (описанный ниже), эта возможность позволяет полям быть добавленными или удаленными из class, не изменяя сериализированное представление class. См. разделы 1.5 и 1.7 из Спецификации Сериализации Объекта Java для деталей.

Сериализуемый полевой API (начиная с 1.2)

Представленный в 1.2, сериализуемый полевой API позволяет class - определенный writeObject/readObject методы, чтобы явно установить и получают сериализуемые значения полей по имени и тип. Этот API особенно полезен для классов, которые должны поддержать назад совместимость с более старыми версиями class; в некоторых случаях более старая версия class, возможно, определила ряд сериализуемых полей, которые не могут быть отображены непосредственно на поля текущего class. В этом случае более новые версии class могут определить пользовательский writeObject и readObject методы, которые преобразовывают внутреннее состояние приведенного примера (нового) class в "старую" сериализированную форму, и наоборот. Для получения дополнительной информации см. раздел 1.7 из Спецификации Сериализации Объекта Java.

---

Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.

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