Безопасно ли использовать методы улучшения байт-кода в классах, которые могут быть сериализованы, и почему?

Question

Я еще не пробовал, но это кажется рискованным.Случай, о котором я думаю, - это инструментарий простых классов VO с JiBX.Эти VO будут сериализованы через AMF и, возможно, другие схемы.Может ли кто-нибудь подтвердить или опровергнуть мои подозрения, что такие закулисные действия, как улучшение байт-кода, могут вообще испортить что-то и предоставить некоторую справочную информацию о том, почему?Также меня интересует конкретный случай JiBX.

Answer 1

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

Итак, если вы выполнили одинаковые манипуляции с байт-кодом с обеих сторон, все будет в порядке.* Если у вас нет, вам нужно прочитать документацию по сериализации, чтобы понять, как работают функции обратной совместимости.По сути, я думаю , что вы можете отправлять поля, которые не ожидаются получателем, и все в порядке;и вы можете пропустить поля, и они получат свои значения по умолчанию на принимающей стороне.Но вы должны проверить это в спецификации!

Если вы просто добавляете методы, то они не влияют на сериализацию, если они не такие, как readResolve() и т. Д.специально используется механизмом сериализации.

Answer 2

Добавление / изменение / удаление открытых или защищенных полей или методов в классе повлияет на его способность к десериализации.Как будет добавление интерфейсов.Они используются, среди прочего, для генерации serialVersionUID , который записывается в поток как часть процесса сериализации.Если serialVersionUID класса не совпадает с загруженным классом во время десериализации, то произойдет сбой.

Если вы явно установите serialVersionUID в своем определении класса, вы можете получить это.Вы также можете реализовать readObject и writeObject.

В крайнем случае вы можете реализовать Externalizable и иметь полный контроль над всей сериализацией объекта.

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