Программирование на Java
Шрифт:
Чтобы увидеть, во что превратился объект objSave, можно просмотреть содержимое массива:
byte[] bArray = os.toByteArray;
А чтобы восстановить объект, его нужно десериализовать из этого массива:
ByteArrayInputStream is =
new ByteArrayInputStream(bArray);
ObjectInputStream ois =
new ObjectInputStream(is);
Object objRead = ois.readObject;
Теперь можно убедиться, что восстановленный объект идентичен исходному:
System.out.println("readed object is: " +
objRead.toString);
System.out.println("Object equality is: " +
(objSave.equals(objRead)));
System.out.println("Reference equality is: " +
(objSave==objRead));
Результатом
readed object is: 1
Object equality is: true
Reference equality is: false
Как мы видим, восстановленный объект не совпадает с исходным (что очевидно – ведь восстановление могло происходить и на другой машине), но равен сериализованному по значению.
Как обычно, для упрощения в примере была опущена обработка ошибок. Однако, сериализация (десериализация) объектов довольно сложная процедура, поэтому возникающие сложности не всегда очевидны. Рассмотрим основные исключения, которые может генерировать метод readObject класса ObjectInputStream.
Предположим, объект некоторого класса TestClass был сериализован и передан по сети на другую машину для восстановления. Может случиться так, что у считывающей JVM на локальном диске не окажется описания этого класса (файл TestClass.class ). Поскольку стандартный механизм сериализации записывает в поток байт лишь состояние объекта, для успешной десериализации необходимо наличие описание класса. В результате будет брошено исключение ClassNotFoundException.
Причина появления java.io.StreamCorruptedException вполне очевидна из названия – неправильный формат входного потока. Предположим, происходит попытка считать сериализованный объект из файла. Если этот файл испорчен (для эксперимента можно открыть его в текстовом редакторе и исправить несколько символов), то стандартная процедура десериализации даст сбой. Эта же ошибка возникнет, если считать некоторое количество байт (с помощью метода read ) непосредственно из надстраиваемого потока InputStream. В таком случае ObjectInputStream снова обнаружит сбой в формате данных и будет брошено исключение java.io.StreamCorruptedException.
Поскольку ObjectOutput наследуется от DataOutput, ObjectOutputStream может быть использован для последовательной записи нескольких значений как объектных, так и примитивных типов в произвольной последовательности. Если при считывании будет вызван метод readObject, а в исходном потоке следующим на очереди записано значение примитивного типа, будет брошено исключение java.io.OptionalDataException. Очевидно, что для корректного восстановления данных из потока их нужно считывать именно в том порядке, в каком были записаны.
Восстановление состояния
Итак, сериализация объекта заключается в сохранении и восстановлении состояния объекта. В Java в большинстве случаев состояние описывается значениями полей объекта. Причем, что важно, не только тех полей, которые были явно объявлены в классе, от которого порожден объект, но и унаследованных полей.
Предположим, мы бы попытались своими силами реализовать стандартный механизм сериализации.
С другой стороны, не меньшей проблемой является восстановление объекта. Как говорилось раньше, объект может быть создан только вызовом его конструктора. У класса, от которого порожден десериализуемый объект, может быть несколько конструкторов, причем, некоторые из них, или все, могут иметь аргументы. Какой из них вызвать? Какие значения передать в качестве аргументов?
После создания объекта необходимо установить считанные значения его полей. Однако многие классы имеют специальные set -методы для этой цели. В таких методах могут происходить проверки, могут меняться значения вспомогательных полей. Пользоваться ли этими методами? Если их несколько, то как выбрать правильный и какие параметры ему передать? Снова возникает проблема работы с недоступными полями, полученными по наследству. Как же в стандартном механизме сериализации решены все эти вопросы?
Во-первых, рассмотрим подробнее работу с интерфейсом Serializable. Заметим, что класс Object не реализует этот интерфейс. Таким образом, существует два варианта – либо сериализуемый класс наследуется от Serializable -класса, либо нет. Первый вариант довольно прост. Если родительский класс уже реализовал интерфейс Serializable, то наследникам это свойство передается автоматически, то есть все объекты, порожденные от такого класса, или любого его наследника, могут быть сериализованы.
Если же наш класс впервые реализует Serializable в своей ветке наследования, то его суперкласс должен отвечать специальному требованию – у него должен быть доступный конструктор без параметров. Именно с помощью этого конструктора будет создан десериализуемый объект и будут проинициализированы все поля, унаследованные от классов, не наследующих Serializable.
Рассмотрим пример:
// Родительский класс, не реализующий Serializable
public class Parent {
public String firstName;
private String lastName;
public Parent {
System.out.println("Create Parent");
firstName="old_first"; lastName="old_last";
}
public void changeNames {
firstName="new_first"; lastName="new_last";
}
public String toString {
return super.toString+",first="+firstName+",last="+lastName;
}
}
// Класс Child, впервые реализовавший Serializable
public class Child extends Parent implements Serializable {
private int age;
public Child(int age) {
System.out.println("Create Child");
this.age=age;
}
public String toString {
return super.toString+",age="+age;
}
}
// Наследник Serializable-класса
public class Child2 extends Child {
private int size;
public Child2(int age, int size) {