Estate atento porque en esta noticia vas a hallar la contestación que buscas.
Solución:
Lo que no entiendo, ¿la anotación afecta la deserialización en sí?
No. Su retención es ‘fuente’, por lo que se descarta después de la compilación. El bytecode no contendrá ningún rastro de él. No tiene forma de influir en el comportamiento del tiempo de ejecución (además de la posible generación de código en tiempo de compilación, lo que no sucede).
Me gusta @Overridees opcional y se supone que brinda cierta seguridad en tiempo de compilación para problemas que, de otro modo, podrían no detectarse hasta el tiempo de ejecución.
Por ejemplo, falta de ortografía serialVersionUID:
@Serial
private static final long seralVersionUID = 123L; // compile-time error, should be 'serialVersionUID'
O el modificador de acceso incorrecto
// compile-time error, must be private
@Serial
public void writeObject(java.io.ObjectOutputStream out) throws IOException
Básicamente, algo anotado con esto debe coincidir exactamente con las descripciones de los 7 elementos aplicables mencionados en el JavaDoc (5 métodos, 2 campos). Si la firma de un método no coincide, o los modificadores son incorrectos, detectará el problema antes de que falle la serialización en tiempo de ejecución.
Esta anotación existe únicamente para mejorar la verificación de tipos en tiempo de compilación. Es análogo de esta manera a la @Override anotación, que existe únicamente para capturar la intención del diseño, de modo que los humanos y las herramientas tengan más información con la que trabajar. los @Override la anotación no hacer una declaración de método anula a otra, que es manejada por el lenguaje basado en la comparación de nombres, firmas y accesibilidad entre el método y los métodos en los supertipos. Qué @Override lo que hace es afirmar que “Creo que esto es una anulación, si me equivoco, por favor dímelo en forma de error de compilación”. Y sirve como aviso a los lectores del código de que este método no es nuevo con esta clase.
Debido a que la serialización utiliza métodos “mágicos” y nombres de campo (métodos como readObject no son parte de ninguna interfaz, la serialización les da significado mágicamente), y la determinación de si la magia funciona es complicada (los métodos no solo deben tener el nombre y los argumentos correctos, sino también la accesibilidad y static-ness), es fácil declarar un método que cree que debe ser utilizado por la serialización, pero para el cual la serialización no está de acuerdo.
los @Serial La anotación le permite hacer un tipo de afirmación similar: que tiene la intención de que este sea uno de esos miembros mágicos de serialización (campos y métodos), y si no coincide con el perfil, el compilador debería alertarlo con un error. Y proporciona una pista similar a los lectores de que este miembro será utilizado por la serialización.
La mayoría de los desarrolladores probablemente no se molestarán con esto para la aplicación y el código de dominio. Pero los autores de bibliotecas pueden encontrarlo útil como una forma de realizar una verificación de tipos más sólida y capturar mejor la intención del diseño.
Te mostramos reseñas y puntuaciones
Finalizando este artículo puedes encontrar las notas de otros desarrolladores, tú igualmente tienes la habilidad dejar el tuyo si dominas el tema.