Respuesta.

Antecedentes:

Java ha soportado desde el principio el mecanismo de serialización de objetos a través de la interfaz Serializable. A veces es necesario guardar el estado de un objeto, pero no todos los campos deben ser serializados; por ejemplo, pueden ser sensibles a la seguridad o calcularse dinámicamente. Para estos casos se ideó el modificador transient.

Problema:

Si se serializa un objeto en su totalidad, sin tener en cuenta las características de los campos individuales, se puede permitir la fuga de datos privados o no serializables. Además, la serialización y deserialización de campos pesados o temporales (por ejemplo, hilos, conexiones a bases de datos) puede llevar a errores o a una disminución del rendimiento.

Solución:

Utilice el modificador transient para los campos que no deben ser serializados al guardar el objeto. Tales campos son simplemente ignorados por el mecanismo de serialización y al deserializar reciben valores predeterminados (por ejemplo, null para tipos de referencia o 0 para números).

Ejemplo de código:

import java.io.*;

class User implements Serializable {
    private String username;
    private transient String password; // ¡No se serializa!
    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }
}

Características clave:

transient se aplica solo a campos, no a métodos o clases.
Los campos transient pierden su valor al transferir el objeto a través de la red/cargar desde un archivo.
transient no protege los datos fuera del mecanismo de serialización estándar (por ejemplo, al copiar manualmente).

Preguntas capciosas.

¿Puede un campo estático ser transient?

Respuesta: Se puede declarar un campo como static transient, pero no tiene sentido: los campos estáticos no se serializan de todos modos, porque pertenecen a la clase, no al objeto.

¿Se puede tener control total sobre la serialización de campos transient?

Respuesta: Sí, implementando los métodos private void writeObject(ObjectOutputStream out) y private void readObject(ObjectInputStream in), se pueden serializar manualmente incluso los campos transient si es necesario.

Ejemplo de código:

private void writeObject(ObjectOutputStream out) throws IOException {
    out.defaultWriteObject();
    // out.writeObject(password); // si es necesario serializar explícitamente el campo transient
}

¿Qué pasará con un campo final transient después de la deserialización?

Respuesta: Los campos final transient también reciben valores predeterminados (generalmente cero o null), pero luego no pueden ser modificados sin trucos especiales, lo que a menudo lleva a errores.

Errores comunes y antipatrón

Marcar todos los campos privados como transient por costumbre.
No tener en cuenta que después de la deserialización, los campos transient deben ser inicializados nuevamente a mano (por ejemplo, en el método readObject).

Ejemplo de la vida real

Caso negativo

Se serializó un objeto con el campo transient DatabaseConnection. Después de la deserialización, se intentaron llamar métodos de esta conexión y se obtuvo un NullPointerException.

Ventajas:

Se guardó el objeto sin información sensible.

Desventajas:

Pérdida de funcionalidad del objeto, se requiere una inicialización adicional.

Caso positivo

Se serializó un objeto User con una contraseña transient, al deserializar en readObject se solicitó la contraseña al usuario o se restauró la conexión.