¿Es seguro usar técnicas de mejora de bytecode en las clases que se pueden serializar y por qué?

Question

No he intentado esto todavía, pero parece arriesgado. El caso en el que estoy pensando es instrumentar clases simples de VO con JiBX. Estos VO se serializarán en AMF y posiblemente en otros esquemas. ¿Puede alguien confirmar o negar mis sospechas de que hacer cosas secundarias como la mejora del código de bytes podría estropear algo en general, y proporcionar información básica sobre por qué? Además, estoy interesado en el caso específico de JiBX.

Answer 1

Detrás de escena, la serialización usa la reflexión. La manipulación de su bytecode presumiblemente agrega campos. Entonces, a menos que marques estos campos como transitorios, se serializarán como campos normales.

Por lo tanto, siempre que haya realizado la misma manipulación de bytecode en ambos lados, todo irá bien.

Si no lo hizo, deberá leer la documentación de serialización para comprender cómo funcionan las funciones de compatibilidad con versiones anteriores. Básicamente, creo que puede enviar campos que el receptor no espera y está bien; y puede perder campos y obtendrán sus valores predeterminados en el extremo receptor. ¡Pero debe comprobar esto en la especificación!

Si solo está agregando métodos, entonces no tienen ningún efecto en la serialización, a menos que sean cosas como readResolve(), etc. que son específicamente utilizados por el mecanismo de serialización.

Answer 2

Añadir/cambiar/eliminar campos o métodos públicos o protegidos a una clase afectará su capacidad de deserialización. Al igual que agregar interfaces. Estos se utilizan, entre otras cosas, para generar un serialVersionUID que se escribe en la secuencia como parte del proceso de serialización. Si el serialVersionUID de la clase no coincide con la clase cargada durante la deserialización, fallará.

Si configura explícitamente el serialVersionUID en su definición de clase, puede hacerlo. Es posible que desee implementar readObject y writeObject también.

En el caso extremo, puede implementar Externalizable y tener control total de toda la serialización del objeto.

El peor de los escenarios (aunque es increíblemente útil en algunas situaciones) es implementar writeReplace en un objeto complejo para cambiarlo por una especie de objeto de valor más simple en la serialización. Luego, en la deserialización, el objeto de valor más simple puede implementar readResolve para reconstruir o ubicar el objeto complejo en el otro lado. Es raro cuando necesitas sacarlo, pero terriblemente divertido cuando lo haces.