SerialVersionUID en Java

La serialización en tiempo de ejecució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 son compatibles con respecto a la serialización. Geek, ahora debes estar preguntándote por qué usamos SerialVersionUID. 

Esto se debe a que SerialVersionUID se usa para garantizar que durante la deserialización se cargue la misma clase (que se usó durante el proceso de serialización). Considere ejecutar la ilustración que se proporciona a continuación para obtener una comprensión más justa de la serialización y la deserialización .

Ilustración:

• Supongamos que una persona que está en el Reino Unido y otra persona que está en la India van a realizar la serialización y la deserialización respectivamente. En este caso, para autenticar que el receptor que está en India es la persona autenticada, JVM crea una ID única que se conoce como SerialVersionUID .
• En la mayoría de los casos, la serialización y la deserialización las realiza una sola persona con el mismo sistema y la misma ubicación. Pero en la serialización, el remitente y el receptor no son las mismas personas, es decir, las personas pueden ser diferentes, la máquina o el sistema pueden ser diferentes y la ubicación debe ser diferente, entonces SerialVersionUID entra en escena. En la serialización, tanto el remitente como el receptor deben tener un archivo .class solo al momento de comenzar, es decir, la persona que va a serializar y la persona que está lista para la deserialización deben contener el mismo archivo .class solo al comienzo.

Serialización en el momento de la serialización, con cada objeto JVM del lado del remitente guardará un Identificador único . JVM es responsable de generar esa ID única basada en el archivo .class correspondiente que está presente en el sistema del remitente.
Deserialización en el momento de la deserialización, la JVM del lado del receptor comparará la ID única asociada con el Objeto con la ID única de la clase local, es decir, la JVM también creará una ID única basada en el archivo .class correspondiente que está presente en el sistema del receptor. Si ambos ID únicos coinciden, solo se realizará la deserialización. De lo contrario, obtendremos Runtime Exception diciendo InvalidClassException . Este identificador único no es más que SerialVersionUID .

También hay ciertas asociaciones de problemas que dependen del SerialVersionUID predeterminado generado por JVM, como se indica a continuación: 

1. Tanto el remitente como el receptor también deben usar la misma JVM con respecto a la plataforma y la versión. De lo contrario, el receptor no puede deserializarse debido a un SerialVersionUID diferente.
2. Tanto el remitente como el receptor deben usar la misma versión de archivo ‘.class’. Después de la serialización, si hay algún cambio en el archivo ‘.class’ en el lado del receptor, el receptor no puede deserializar.
3. Para generar SerialVersionUID internamente, JVM puede usar algoritmos complejos que pueden crear problemas de rendimiento.

Implementación: 

Podemos resolver el problema anterior configurando nuestro propio SerialVersionUID. Podemos configurar nuestro propio SerialVersionUID para el cual necesitamos 3 clases de la siguiente manera:

• Clase aleatoria que contiene dos variables que se van a serializar, que sea ‘Geeks’
• Clase para el lado del remitente que va a serializar un objeto
• Clase para el lado del receptor que se va a deserializar

Sintaxis:  

private static final long SerialVersionUID=10l;

Ejemplo 1:  
 

// Java program to illustrate Implementation of
// User-defined SerialVersionUID
 
// Main class
// // Geeks which contains two variable which
// are going to Serialize to
// Illustrate Implementation of Serializable Interface
class Geeks implements Serializable {
 
    // User-defined SerialVersionUID
    // Custom initialization
    private static final long SerialVersionUID = 10l;
    int i = 10;
    int j = 20;
}

Ejemplo 2: Clase para el lado del remitente que va a serializar un objeto
 

// Java program to illustrate
// implementation of User-defined
// SerialVersionUID
 
// Importing required classes
import java.io.*;
 
// Sender side class which is going to Serialize object
class Sender {
 
    // Main driver method
    public static void main(String[] args)
    {
        // Creating object of class Random class which
        // contains two variables which are going to
        // Serialize In simpler words , object of class
        // 'Geeks'
        Geeks g = new Geeks();
 
        // Here xyz.txt is the file name where the object is
        // going to serialize
        FileOutputStream fos
            = new FileOutputStream("xyz.txt");
        ObjectOutputStream oos
            = new ObjectOutputStream(fos);
 
        oos.writeObject(g);
    }
}

Ejemplo 3: Clase para el lado del receptor que se va a deserializar 
 

// Java program to illustrate Implementation of
// User-defined SerialVersionUID
 
// Importing I/O classes
import java.io.*;
 
// Receiver side class which is going to deserialize 
class Receiver {
 
    // main driver method
    public static void main(String[] args)
    {
        // Here xyz.txt is the file name where the object is
        // going to Deserialized
        FileInputStream fis
            = new FileInputStream("xyz.txt");
        ObjectInputStream ois = new ObjectInputStream(fis);
 
        // Creating object of class 'Geeks'
        Geeks g1 = (Geeks)ois.readObject();
 
        // Print and display the
        // deserialized object value
        System.out.println("Deserialized Object Value:"
                           + g1.i + "..." + g1.j);
    }
}

Producción: 
 

Podemos ver el archivo que es xyz.txt donde el objeto es Serializar y también la salida cuando deserializamos el Objeto.

Nota : en el programa anterior, si realizamos algún cambio en el archivo Geeks .class en el extremo del receptor. No tenemos ningún problema en el momento de la deserialización. En este caso, el remitente y el receptor no están obligados a mantener las mismas versiones de JVM.