Réponse.

Historique de la question :

Java prend en charge depuis le début le mécanisme de sérialisation des objets via l'interface Serializable. Il est parfois nécessaire de sauvegarder l'état d'un objet, mais tous les champs ne doivent pas être sérialisés - par exemple, ils peuvent être sensibles à la sécurité ou calculés dynamiquement. C'est pour de tels cas que le modificateur transient a été conçu.

Problème :

Si l'on sérialise un objet dans son intégralité, sans tenir compte des spécificités des champs individuels, on peut risquer de divulguer des données privées ou non résistantes à la sérialisation. De plus, la sérialisation et la désérialisation de champs lourds ou temporaires (par exemple, des flux, des connexions à une base de données) peuvent entraîner des erreurs ou une diminution des performances.

Solution :

Utilisez le modificateur transient pour les champs qui ne doivent pas être sérialisés lors de la sauvegarde de l'objet. Ces champs sont simplement ignorés par le mécanisme de sérialisation et reçoivent des valeurs par défaut lors de la désérialisation (par exemple, null pour les types de référence ou 0 pour les nombres).

Exemple de code :

import java.io.*;

class User implements Serializable {
    private String username;
    private transient String password; // Ne sera pas sérialisé !
    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }
}

Caractéristiques clés :

transient s'applique uniquement aux champs, et non aux méthodes ou classes
les champs transient perdent leur valeur lors de la transmission de l'objet sur le réseau / lors du chargement à partir d'un fichier
transient ne protège pas les données en dehors du mécanisme de sérialisation standard (par exemple, lors de la copie manuelle)

Questions pièges.

Un champ static peut-il être transient ?

Réponse : Il est possible de déclarer un champ comme static transient, mais cela n'a pas de sens : les champs statiques ne sont pas sérialisés car ils appartiennent à la classe et non à l'objet.

Peut-on avoir un contrôle total sur la sérialisation des champs transient ?

Réponse : Oui, en mettant en œuvre les méthodes private void writeObject(ObjectOutputStream out) et private void readObject(ObjectInputStream in), il est possible de sérialiser soi-même même les champs transient si nécessaire.

Exemple de code :

private void writeObject(ObjectOutputStream out) throws IOException {
    out.defaultWriteObject();
    // out.writeObject(password); // si besoin de sérialiser explicitement un champ transient
}

Que se passera-t-il avec un champ final transient après la désérialisation ?

Réponse : Les champs final transient reçoivent également des valeurs par défaut (généralement zéro ou null), mais il est ensuite impossible de les modifier sans ruses particulières, ce qui entraîne souvent des bogues.

Erreurs typiques et anti-modèles

Marquer tous les champs privés comme transient par habitude
Ne pas tenir compte que, après la désérialisation, les champs transient doivent être réinitialisés manuellement (par exemple, dans la méthode readObject)

Exemple de la vie réelle

Cas négatif

Un objet avec un champ transient DatabaseConnection a été sérialisé. Après la désérialisation, nous avons essayé d'appeler des méthodes de cette connexion - nous avons obtenu NullPointerException.

Avantages :

L'objet a été sauvegardé sans information sensible

Inconvénients :

Perte de la fonctionnalité de l'objet, nécessitant une réinitialisation supplémentaire

Cas positif

Un objet User avec un mot de passe transient a été sérialisé, lors de la désérialisation dans readObject, le mot de passe a été demandé à l'utilisateur ou la connexion a été restaurée.