este problema se puede abordar de diferentes maneras, pero te dejamos la respuesta más completa para nosotros.
Solución:
los documentos para java.io.Serializable son probablemente una explicación tan buena como la que obtendrás:
El tiempo de ejecución de serialización asocia con cada clase serializable un número de versión, llamado
serialVersionUID, que se usa durante la deserialización para verificar que el remitente y el receptor de un objeto serializado hayan cargado clases para ese objeto que sean compatibles con respecto a la serialización. Si el receptor ha cargado una clase para el objeto que tiene una diferenteserialVersionUIDque el de la clase del remitente correspondiente, entonces la deserialización resultará en un
InvalidClassException. Una clase serializable puede declarar su propiaserialVersionUIDexplícitamente al declarar un campo llamadoserialVersionUIDeso debe ser staticfinal, y de tipolong:
ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
Si una clase serializable no declara explícitamente un
serialVersionUIDentonces el tiempo de ejecución de serialización calculará un valor predeterminadoserialVersionUIDvalor para esa clase en función de varios aspectos de la clase, como se describe en la Especificación de serialización de objetos de Java(TM). Sin embargo lo és muy recomendado que todas las clases serializables declaran explícitamenteserialVersionUIDvalores, ya que el valor predeterminadoserialVersionUIDel cálculo es muy sensible a los detalles de la clase que pueden variar según las implementaciones del compilador y, por lo tanto, pueden generar resultados inesperados.InvalidClassExceptionsdurante la deserialización. Por lo tanto, para garantizar una consistenciaserialVersionUIDvalor a través de diferentes implementaciones del compilador Java, una clase serializable debe declarar un explícitoserialVersionUIDvalor. También se recomienda encarecidamente que sea explícitoserialVersionUIDLas declaraciones usan el modificador privado siempre que sea posible, ya que tales declaraciones se aplican solo a la clase declarante inmediata:serialVersionUIDlos campos no son útiles como miembros heredados.
Si está serializando solo porque tiene que serializar por el bien de la implementación (a quién le importa si serializa por un HTTPSessionpor ejemplo… si está almacenado o no, probablemente no te importe de-serializing un objeto de formulario), entonces puede ignorar esto.
Si realmente está usando la serialización, solo importa si planea almacenar y recuperar objetos usando la serialización directamente. los serialVersionUID representa la versión de su clase, y debe incrementarla si la versión actual de su clase no es compatible con versiones anteriores.
La mayoría de las veces, probablemente no usará la serialización directamente. Si este es el caso, genere un valor predeterminado SerialVersionUID haciendo clic en la opción de solución rápida y no se preocupe por eso.
No puedo dejar pasar esta oportunidad de publicar el libro de Josh Bloch Java efectivo (2ª edición). El Capítulo 11 es un recurso indispensable sobre la serialización de Java.
Según Josh, el UID generado automáticamente se genera en función de un nombre de clase, interfaces implementadas y todos los miembros públicos y protegidos. Cambiar cualquiera de estos de alguna manera cambiará el serialVersionUID. Por lo tanto, no necesita meterse con ellos solo si está seguro de que no se serializará más de una versión de la clase (ya sea a través de procesos o recuperada del almacenamiento en un momento posterior).
Si los ignora por ahora y luego descubre que necesita cambiar la clase de alguna manera pero manteniendo la compatibilidad con la versión anterior de la clase, puede usar la herramienta JDK serializador para generar el serialVersionUID sobre el viejo class, y establecerlo explícitamente en la nueva clase. (Dependiendo de sus cambios, es posible que deba implementar también la serialización personalizada agregando writeObject y readObject métodos – ver Serializable javadoc o el mencionado capítulo 11.)