Интерфейс Serializable

public interface Serializable

Сериализуемость класса включена, если класс реализует интерфейс java.io.Serializable.

Предупреждение: Десериализация недоверенных данных изначально небезопасна и должна быть избегнута. Недоверенные данные должны быть тщательно проверены в соответствии с разделом «Сериализация и десериализация» Руководства по разработке безопасного кода для Java SE. Фильтрация сериализации описывает лучшие методы для защищенного использования фильтров сериализации.

Классы, которые не реализуют этот интерфейс, не будут иметь сериализованного или десериализованного состояния. Все подтипы сериализуемого класса также являются сериализуемыми. Интерфейс сериализации не имеет методов или полей и служит только для определения семантики сериализации.

Возможно, что подтипы несериализуемых классов могут быть сериализованы и десериализованы. Во время сериализации данные не будут записываться для полей несериализуемых суперклассов. Во время десериализации поля несериализуемых суперклассов будут инициализированы с помощью конструктора без аргументов первого (наинизшего) несериализуемого суперкласса. Этот конструктор должен быть доступен для подкласса, который десериализуется. Неправильным является объявление класса Serializable, если это не так; ошибка будет обнаружена во время выполнения. Сериализуемый подтип может взять на себя ответственность за сохранение и восстановление состояния публичных, защищенных и (если доступны) полей пакета супертипа, не являющегося сериализуемым. Подробное описание процесса десериализации, включая обработку сериализуемых и несериализуемых классов, см. в разделе Спецификации сериализации Java объектов, раздел 3.1.

При обходе графа может быть встречен объект, который не поддерживает интерфейс Serializable. В этом случае будет выброшено исключение NotSerializableException, которое укажет класс несериализуемого объекта.

Классы, которые требуют специальной обработки во время сериализации и десериализации, должны реализовывать специальные методы с такими же сигнатурами:

 private void writeObject(java.io.ObjectOutputStream out)
     throws IOException;
 private void readObject(java.io.ObjectInputStream in)
     throws IOException, ClassNotFoundException;
 private void readObjectNoData()
     throws ObjectStreamException;
 

Метод writeObject отвечает за запись состояния объекта для его конкретного класса, чтобы соответствующий метод readObject мог восстановить его. Установленный механизм сохранения полей объекта может быть вызван путем вызова out.defaultWriteObject. Метод не должен заботиться о состоянии, принадлежащем его суперклассам или подклассам. Состояние сохраняется путем записи отдельных полей в ObjectOutputStream с помощью метода writeObject или с помощью методов для примитивных типов данных, поддерживаемых DataOutput.

Метод readObject отвечает за чтение из потока и восстановление полей класса. Он может вызвать in.defaultReadObject для вызова установленного механизма восстановления нестатических и нетранзиентных полей объекта. Метод defaultReadObject использует информацию из потока для присвоения полей объекта, сохраненного в потоке, соответствующим именованным полям в текущем объекте. Это обрабатывает случай, когда класс эволюционировал, добавив новые поля. Метод не должен заботиться о состоянии, принадлежащем его суперклассам или подклассам. Состояние восстанавливается путем чтения данных из ObjectInputStream для отдельных полей и выполнения присвоений соответствующим полям объекта. Чтение примитивных типов данных поддерживается DataInput.

Метод readObjectNoData отвечает за инициализацию состояния объекта для его конкретного класса в том случае, если поток сериализации не указывает данный класс как суперкласс объекта, который десериализуется. Это может произойти в тех случаях, когда принимающая сторона использует другую версию класса десериализованной инстанции, чем отправляющая сторона, и версия получателя расширяет классы, которые не расширяются версией отправителя. Это также может произойти, если поток сериализации был скомпрометирован; следовательно, readObjectNoData полезен для корректной инициализации десериализованных объектов, несмотря на «враждебный» или неполный исходный поток.

Сериализуемые классы, которые должны назначить альтернативный объект для использования при записи объекта в поток, должны реализовать этот специальный метод с точной сигнатурой:

 ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException;
 

Метод writeReplace вызывается сериализацией, если метод существует, и он был бы доступен из метода, определенного в классе сериализуемого объекта. Таким образом, метод может иметь закрытый, защищенный и пакетный доступ. Доступ к методу из подкласса соответствует правилам доступа Java.

Классы, которым нужно назначить замену при чтении экземпляра из потока, должны реализовать этот специальный метод с точной сигнатурой.

 ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;
 

Метод readResolve следует тем же правилам вызова и правилам доступа, что и writeReplace.

Типы перечислений полностью сериализуемы и обрабатываются в соответствии с Спецификация сериализации Java объектов во время сериализации и десериализации. Любые объявления специальных методов обработки, обсуждавшихся выше, игнорируются для типов перечислений.

Классы записей могут реализовывать Serializable и обрабатываться в соответствии с Спецификацией сериализации Java объектов, раздел 1.13, «Сериализация записей». Любые объявления специальных методов обработки, обсуждавшихся выше, игнорируются для типов записей.

Сериализация связывает с каждым сериализуемым классом номер версии, называемый serialVersionUID, который используется во время десериализации для проверки того, что отправитель и получатель сериализованного объекта загрузили классы для этого объекта, совместимые с точки зрения сериализации. Если получатель загрузил класс для объекта с другим serialVersionUID, чем у соответствующего класса отправителя, десериализация приведет к InvalidClassException. Сериализуемый класс может явно объявить свой serialVersionUID, объявив поле с именем "serialVersionUID", которое должно быть статическим, конечным и типа long:

 ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
 

Если сериализуемый класс не объявляет явно serialVersionUID, тогда среда выполнения сериализации вычисляет значение serialVersionUID по умолчанию для этого класса на основе различных аспектов класса, как описано в Спецификации сериализации Java объектов. Эта спецификация определяет serialVersionUID типа перечисления как 0L. Однако настоятельно рекомендуется, чтобы все сериализуемые классы, кроме типов перечислений, явно объявляли значения serialVersionUID, так как вычисление serialVersionUID по умолчанию сильно зависит от деталей класса, которые могут различаться в зависимости от реализаций компиляторов и, таким образом, могут привести к неожиданным InvalidClassException при десериализации. Поэтому, чтобы гарантировать согласованное значение serialVersionUID в различных реализациях компилятора Java, сериализуемый класс должен объявить явное значение serialVersionUID. Также настоятельно рекомендуется, чтобы явные объявления serialVersionUID использовали модификатор private, поскольку такие объявления применяются только к непосредственно объявляемому классу — поля serialVersionUID не полезны как унаследованные члены. Классы массивов не могут объявить явный serialVersionUID, поэтому они всегда имеют значение по умолчанию, вычисленное, но требование соответствия значений serialVersionUID отменяется для классов массивов.