Answer.

Background:

Java has supported the mechanism of object serialization through the Serializable interface since its inception. Sometimes it is necessary to save the state of an object, but not all fields should be serialized — for example, they may be security-sensitive or calculated dynamically. The transient modifier was invented for such cases.

Issue:

Serializing an object entirely without considering the peculiarities of individual fields can lead to leaking private or non-serializable data. Additionally, serializing and deserializing heavy or temporary fields (such as streams, database connections) can cause errors or decrease performance.

Solution:

Use the transient modifier for fields that should not be serialized when saving the object. Such fields are simply ignored by the serialization mechanism, and upon deserialization, they receive default values (for example, null for reference types or 0 for numbers).

Code example:

import java.io.*;

class User implements Serializable {
    private String username;
    private transient String password; // Not serialized!
    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }
}

Key features:

transient is applied only to fields, not to methods or classes
transient fields lose their value when the object is sent over the network or loaded from a file
transient does not protect data outside the standard serialization mechanism (for example, during manual copying)

Tricky questions.

Can a static field be transient?

Answer: It is possible to declare a field as static transient, but it makes no sense: static fields are not serialized anyway, since they belong to the class, not the object.

Can you have complete control over the serialization of transient fields?

Answer: Yes, by implementing the methods private void writeObject(ObjectOutputStream out) and private void readObject(ObjectInputStream in), you can manually serialize even transient fields if needed.

Code example:

private void writeObject(ObjectOutputStream out) throws IOException {
    out.defaultWriteObject();
    // out.writeObject(password); // if you need to explicitly serialize a transient field
}

What happens to a final transient field after deserialization?

Answer: final transient fields also receive default values (usually zero or null), but they cannot be changed afterwards without special tricks, which often leads to bugs.

Common mistakes and anti-patterns

Marking all private fields as transient out of habit
Not considering that transient fields need to be manually reinitialized after deserialization (for example, in the readObject method)

Real-life example

Negative case

Serialized an object with a transient DatabaseConnection field. After deserialization, tried to call methods on this connection — got NullPointerException.

Pros:

Saved the object without sensitive information

Cons:

Lost the object's functionality, requiring additional initialization

Positive case

Serialized a User object with a transient password, during deserialization in readObject asked the user for the password or restored the connection.