unserialize - Es la serialización de objetos java compatible entre 1.5 y 1.6

unserialize java

Question

Me pregunto si es seguro mezclar jdk 1.5 y 1.6 (Java 6) serialización de objetos (comunicación bidireccional). Busqué una declaración explícita del sol con respecto a esta pregunta, pero no tuvo éxito. Entonces, además de la factibilidad técnica, estoy buscando una declaración "oficial" sobre el problema.

Answer 1

¿Has leído la especificación de serialización de objetos Java ? Hay un tema sobre el versioning de versioning . También hay un artículo para implementadores de clase: Descubre los secretos de la API de serialización de Java . Cada lanzamiento de Java va acompañado de notas de compatibilidad .

De la especificación de Java 6 en la serialización:

Los objetivos son:

• Admite comunicación bidireccional entre diferentes versiones de una clase que operan en diferentes máquinas virtuales por:
  • Definición de un mecanismo que permite a las clases JavaTM leer las secuencias escritas por versiones anteriores de la misma clase.
  • Definición de un mecanismo que permite a las clases de JavaTM escribir flujos destinados a ser leídos por versiones anteriores de la misma clase.
• Proporcione serialización predeterminada para la persistencia y para RMI.
• Realice bien y produzca transmisiones compactas en casos simples, para que RMI pueda usar la serialización.
• Ser capaz de identificar y cargar clases que coincidan con la clase exacta utilizada para escribir la secuencia.
• Mantenga la sobrecarga baja para las clases no versionadas.
• Utilice un formato de flujo que permita el recorrido de la secuencia sin tener que invocar métodos específicos para los objetos guardados en la secuencia.

Answer 2

A menos que se indique lo contrario, esto debería ser parte de la compatibilidad binaria. Las clases de Swing explícitamente no son compatibles entre versiones. Si encuentra un problema con otras clases, informe un error en bugs.sun.com .

Answer 3

Añadiría rápidamente que es posible cambiar la clase, pero se olvida de cambiar el serialVersionUID. Por lo tanto, es incorrecto que "si la clase define un serialVersionUID, y esto no cambia, se garantiza que la clase sea compatible". Por el contrario, tener el mismo serialVersionUID es la forma en que una API promete compatibilidad con versiones anteriores.

Answer 4

Después de probar con un objeto serializado escrito en un archivo usando ObjectOutputStream en un programa Java 1.5, y luego ejecutar una lectura con un ObjectInputStream en un programa Java 1.6, puedo decir que funcionó sin ningún problema.

Answer 5

El mecanismo de serialización en 1.5 y 1.6 es compatible. Por lo tanto, el mismo código compilado / en ejecución en un contexto 1.5 y 1.6 puede intercambiar objetos serializados. Si las dos instancias de VM tienen la misma versión / compatible de la clase (como puede indicar el campo serialVersionUID) es una pregunta diferente que no está relacionada con la versión de JDK.

Si tiene un Foo.java serializable y lo usa en un JDK / VM 1.5 y 1.6, instancias serializadas de Foo creadas por un V; puede ser deserializado por el otro.

Answer 6

El mecanismo de serialización en sí no ha cambiado. Para clases individuales, dependerá de la clase específica. Si una clase tiene un campo serialVersionUID, se supone que esto indica la compatibilidad de serialización.

Algo como:

private static final long serialVersionUID = 8683452581122892189L;

Si no se modifica, las versiones serializadas son compatibles. Para las clases JDK, esto está garantizado, pero, por supuesto, siempre es posible olvidarse de actualizar el serialVersionUID después de realizar un cambio radical.

Cuando no se garantiza que las clases JDK sean compatibles, esto generalmente se menciona en el Javadoc.

Advertencia: los objetos serializados de esta clase no serán compatibles con futuras versiones de Swing

Answer 7

No es seguro mezclar Java 1.5 y 1.6. Por ejemplo, tengo un objeto Java 1.5 serializado en un archivo e intenté abrirlo en Java 1.6 pero apareció el siguiente error.

java.io.InvalidClassException: javax.swing.JComponent; local class incompatible: stream classdesc serialVersionUID = 7917968344860800289, local class serialVersionUID = -1030230214076481435
at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readArray(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readArray(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)

Answer 8

Tenga en cuenta que la especificación Java Beans detalla un método de serialización independiente de la versión que permite una fuerte compatibilidad hacia atrás. También da como resultado formularios legibles "serializados". De hecho, un objeto serializado se puede crear con bastante facilidad utilizando el mecanismo.

Busque la documentación en las clases XMLEncoder y XMLDecoder .

No utilizaría esto para pasar un objeto por el cable necesariamente (aunque si el alto rendimiento es un requisito, tampoco usaría la serialización) pero es invaluable para el almacenamiento persistente de objetos.