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

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

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

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

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

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

Исправление ошибки: 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 параметр. Мертвая блокировка больше не должна произойти в этом случае.

Исправление ошибки: никакая спецификация для 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 могут использоваться, чтобы более эффективно считать содержавшие объекты массива безопасным способом; для получения дополнительной информации см. раздел 6 Спецификации Сериализации Объекта Java, "Охраняя Неразделенные Десериализованные Объекты".

Права доступа, теперь требуемые переопределять 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, также не переопределяя остальную часть инфраструктуры сериализации.

Поддержка определенного с помощью класса readObjectNoData метода (начиная с 1.4)

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

private void readObjectNoData() throws ObjectStreamException;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

writeClassDescriptor и readClassDescriptor методы были добавлены, чтобы обеспечить средство настройки сериализированного представления java.io.ObjectStreamClass дескрипторы класса. writeClassDescriptor вызывается когда экземпляр java.io.ObjectStreamClass потребности, которые будут сериализированы, и, ответственны за запись ObjectStreamClass к потоку сериализации. Наоборот, readClassDescriptor вызывается когда ObjectInputStream ожидает ObjectStreamClass экземпляр как следующий элемент в потоке сериализации. Переопределяя эти методы, подклассы ObjectOutputStream и ObjectInputStream может передать дескрипторы класса в специализированном формате. Для получения дополнительной информации обратитесь к разделам 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 использовать пользовательские данные в выборе локального класса, чтобы связаться с данным дескриптором прокси-класса. Для получения дополнительной информации см. раздел 4 из Спецификации Сериализации Объекта Java.

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

Теги javadoc @serial, @serialField, и @serialData были добавлены, чтобы обеспечить способ задокументировать сериализированную форму класса. 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 для получения дополнительной информации.

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

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

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

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

---

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

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