Сериализация Java 1.4 против 1.6 - PullRequest
4 голосов
/ 25 ноября 2008

У меня есть одна java-программа, которая должна быть скомпилирована как 1.4, и другая программа, которая может быть чем угодно (например, 1.4 или 1.6), и обеим нужно передавать сериализованные объекты туда и обратно. Если я определю сериализуемый класс в месте, где его могут видеть обе программы, будет ли работать сериализация в java или мне нужны только версии 1.6-1.6 или 1.4-1.4?

Ответы [ 5 ]

5 голосов
/ 25 ноября 2008

Убедитесь, что сериализуемые классы определяют и присваивают значение static final long serialVersionUID, и все должно быть в порядке.

Тем не менее, обычно я бы не стал этого делать. Я предпочитаю использовать обычную сериализацию только внутри одного процесса или между двумя процессами на одном компьютере и получать сериализованные классы из одного и того же файла JAR. Если это не так, сериализация в XML является лучшим и безопасным выбором.

3 голосов
/ 25 ноября 2008

Наряду с serialVersionUID структура пакета должна оставаться согласованной для сериализации, поэтому, если у вас было myjar.mypackage.myclass в 1.4, вы должны иметь myjar.mypackage.myclass в 1.6.

Нередко бывает, что версия Java или версия выпуска где-то в структуре пакета. Даже если serialVersionUID остается неизменным между компиляциями, структура пакета вызовет появление несовместимой версии исключения во время выполнения.

Кстати, если вы реализуете Serializable в своих классах, вы должны получить предупреждение компилятора, если serialVersionUID отсутствует.

На мой взгляд (и на основе нескольких лет довольно горького опыта) нативная сериализация Java чревата проблемами и ее следует избегать, если это возможно, особенно потому, что есть отличная поддержка XML / JSON. Если вам действительно нужно сериализовать изначально, то я рекомендую вам скрыть ваши классы за интерфейсами и реализовать шаблон фабрики в фоновом режиме, который при необходимости создаст объект нужного класса.

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

1 голос
/ 26 ноября 2008

Нет, другая версия JVM не нарушит сериализацию.

Если некоторые объекты, которые вы сериализуете, взяты из среды выполнения Java, и их классы развивались несовместимо, вы увидите сбои. Большинство основных классов Java осторожны с этим, но в некоторых пакетах в прошлом были разрывы.

Я успешно использовал сериализацию (в контексте RMI) с классами из разных компиляций на разных машинах, на которых в течение многих лет работали разные версии среды выполнения Java.

Я не хочу отступать слишком далеко от первоначального вопроса, но хочу отметить, что развитие сериализованного класса всегда требует осторожности, независимо от формата. Это не проблема, специфичная для сериализации Java. Вы должны иметь дело с теми же понятиями, независимо от того, сериализуетесь ли вы в XML, JSON, ASN.1 и т. Д. Сериализация Java дает довольно четкую спецификацию того, что разрешено и как вносить изменения, которые разрешены. Иногда это ограничительно, иногда полезно иметь рецепт.

1 голос
/ 25 ноября 2008

Классы библиотек Java должны иметь совместимые сериализованные формы между 1.4 и 1.6, если не указано иное. Swing прямо заявляет, что он несовместим между версиями, поэтому, если вы пытаетесь сериализовать объекты Swing, вам не повезло.

Вы можете столкнуться с проблемами, когда код, сгенерированный javac, немного отличается. Это изменит serialVersionUID. Вы должны обеспечить явное объявление UID во всех ваших сериализуемых классах.

0 голосов
/ 26 ноября 2008

Если обе стороны используют один и тот же файл jar, он будет работать большую часть времени. Однако, если вы используете разные версии одного и того же пакета / модуля / фреймворка (например, разные jar-файлы weblogic или расширенное использование некоторых «редких» исключений), для того, чтобы его можно было одобрить, необходимо провести много интеграционных тестов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...