Сериализация Java, UID не изменен. Могу ли я добавить в класс новые переменные и метод?

У меня есть класс, который сериализуется. Теперь мне нужно добавить новую переменную в класс, используя методы setter и getter. Этот класс отправляется через провод в RMI.

Не меняя UID, могу ли я добавить для него новые параметры и методы getter и setter? Я попытался написать примерный класс, который отправляется по проводке, и не изменил UID, и добавил для него новые параметры и методы getter и setter. С другой стороны, я протестировал его, и я все еще правильно понял значения. Я предположил, что если я добавлю новые параметры, методы getter и setter, мне нужно изменить UID. Я не прав?

Ответы

Ответ 1

Если вы жестко запрограммируете SerialVersionUID класса (обычно для 1L), сохраните некоторые экземпляры, а затем переопределите класс, вы в основном получите это поведение (что более или менее здравый смысл):

  • Новые поля (присутствующие в определении класса, не присутствующие в сериализованном экземпляре) присваиваются значениям по умолчанию, которое является нулевым для объектов или тому же значению, что и неинициализированное поле для примитивов.
  • Удаленные поля (не присутствующие в определении класса, но присутствующие в сериализованном экземпляре) просто игнорируются.

Итак, общее эмпирическое правило: если вы просто добавляете поля и методы и не меняете какой-либо существующий материал, и если вы в порядке со значениями по умолчанию для этих новых полей, вы, как правило, в порядке.

Ответ 2

Ничего себе, много плохой информации.

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

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

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

Java-сериализация очень хорошо документирована в Интернете, вы сможете найти всю эту информацию в соответствующих учебных пособиях/документах по солнцу/оракулу.

Ответ 3

Это имеет значение только для того, чтобы позволить Java генерировать UID по умолчанию для вашего класса. Он использует фактические члены и методы класса для его создания, что делает его недействительным после изменения структуры класса. Если вы предоставляете UID для своего класса, тогда это имеет значение только в том случае, если вам нужно десериализовать старые версии вашего класса из файла и т.д.

Ответ 4

Хотите определить несколько пунктов, чтобы выделить изменения, которые влияют на сериализацию. Ниже вы найдете ссылку на Oracle Java Docs для более подробной информации.

Несовместимые изменения

Несовместимые изменения в классах - это те изменения, за которые нельзя поддерживать гарантию совместимости. Несовместимые изменения, которые могут возникать при разработке класса, следующие:

  • Удаление полей
  • Перемещение классов вверх или вниз по иерархии
  • Изменение нестатического поля на статическое или нетрансловое поле на переходный
  • Изменение объявленного типа примитивного поля
  • Изменение метода writeObject или readObject, чтобы он больше не записывал и не читал данные поля по умолчанию или не менял его так, чтобы он пытался его записать или прочитать, когда предыдущая версия не выполнялась.
  • Изменение класса от Serializable до Externalizable или наоборот.
  • Изменение класса из типа, отличного от перечисления, в тип перечисления или наоборот.
  • Удаление Serializable или Externalizable.
  • Добавление метода writeReplace или readResolve к классу, если поведение приведет к созданию объекта, который несовместим с любой более старой версией класса.

Ссылка, из которой берется вышеуказанная информация http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html#6678