Во всех случаях, описанных выше, java.io.InvalidClassException будет выброшено в случае, если вы попытаетесь десериализовать класс.Причина такого поведения заключается в том, что серийная версия класса, используемого для десериализации , не соответствует серийной версии класса, используемого для сериализации класса .Это поведение по умолчанию .
Эта последовательная версия класса используется для проверки того, что сериализованные и десериализованные объекты имеют одинаковые атрибуты и, следовательно, совместимы (что являетсяэто не так в ваших примерах в вопросе.)
Если вы явно не объявите поле serialVersionUID (типа long), JVM сгенерирует его автоматически во время выполнения.время.Однако, если вы собираетесь использовать сериализацию Java, настоятельно рекомендуется явно объявить serialVersionUID (поскольку сгенерированный является зависимым от компилятора и, следовательно, может привести к неожиданным исключениям java.io.InvalidClassException).
Предположим, вы явно объявили serialVersionUID , но вы не обновляли его во время изменений.В ваших случаях:
- Когда новое поле добавляется в класс.Объект должен быть десериализован без каких-либо исключений, новое поле будет иметь значение по умолчанию.
- Когда нестатический член преобразуется в статический.Ваше статическое поле будет иметь значение соответствующего нестатического поля.
- Когда непереходное поле становится переходным.Ваше переходное поле будет игнорироваться во время десериализации и, следовательно, будет иметь значение по умолчанию.
- Когда переходное поле становится не переходным.Поскольку поля
transient игнорируются во время сериализации, этот случай почти равен случаю 1 - ваше поле будет иметь значение по умолчанию.