Java Serialization: Interface & Keyword Explained

1. What is Serialization and Why Do We Need It?

At its core, serialization is about capturing the current state of a Java object and turning it into a sequence of bytes. The reverse process, deserialization, reconstructs the object from that byte stream.

This capability is fundamental for two main reasons:

1. Persistence: Saving the state of an object to a file on disk, so it can be restored later, even after the JVM has shut down.
2. Communication: Sending an object from one Java application to another, for instance, over a network in a client-server or microservices architecture.

The key feature of Java's serialization is that the byte stream is platform-independent. An object serialized on a Windows machine can be deserialized on a Linux machine without any issues.

To get a quick overview of this process, watch the first part of the following video.

2. The Core Mechanism: Serializable and I/O Streams

To make a Java class serializable, you must implement the java.io.Serializable interface. This is a marker interface, meaning it has no methods to implement. Its sole purpose is to "mark" the class and signal to the JVM that its instances are allowed to be serialized.

The actual serialization and deserialization work is done using two key stream classes:

• java.io.ObjectOutputStream: Wraps an OutputStream (like FileOutputStream) and provides the writeObject() method to serialize an object.
• java.io.ObjectInputStream: Wraps an InputStream (like FileInputStream) and provides the readObject() method to deserialize an object.

The following video segments demonstrate this process with code, showing how to make a class serializable and then write it to and read it from a file.

Here's a summary of the code structure:

// 1. The class must implement Serializable
public class Employee implements java.io.Serializable {
    private int id;
    private String name;
    // constructors, getters, setters...
}

// 2. To Serialize (write) the object
Employee emp = new Employee(1, "John Doe");
try (FileOutputStream fileOut = new FileOutputStream("employee.ser");
     ObjectOutputStream out = new ObjectOutputStream(fileOut)) {
    out.writeObject(emp);
}

// 3. To Deserialize (read) the object
Employee empFromFile;
try (FileInputStream fileIn = new FileInputStream("employee.ser");
     ObjectInputStream in = new ObjectInputStream(fileIn)) {
    empFromFile = (Employee) in.readObject();
}

3. Controlling Serialization: transient and static

By default, Java's serialization mechanism tries to save the values of all of an object's instance fields. However, you often need more control. This is where the transient and static keywords become important.

The transient Keyword

You use the transient keyword to mark a field that should not be serialized. When an object is deserialized, a transient field will be initialized to its default value (e.g., 0 for int, false for boolean, null for object references).

Why would you do this?

• Sensitive Data: To prevent sensitive information, like passwords or credit card numbers, from being written to a byte stream.
• Derived Data: If a field's value can be calculated from other fields, there's no need to serialize it. You can simply recalculate it after deserialization.
• Non-Serializable Fields: If a field holds an object that doesn't implement Serializable (like a thread pool or a database connection), you must mark it as transient to avoid a NotSerializableException.

The static Keyword

static fields are also not part of the serialization process. This is a crucial interview point. Serialization saves the state of an object instance. static fields belong to the class, not to any individual instance. Therefore, they are not included in the object's serialized state.

import java.io.Serializable;
import java.util.logging.Logger;

public class User implements Serializable {
    private String username;
    private String password; // Sensitive
    private Logger logger = Logger.getLogger(User.class.getName()); // Not Serializable
}

import java.io.Serializable;
import java.util.logging.Logger;

public class User implements Serializable {
    private String username;
    private transient String password; // Mark as transient to prevent serialization
    private transient Logger logger = Logger.getLogger(User.class.getName()); // Must be transient as Logger is not Serializable
}

4. Versioning with serialVersionUID

This is one of the most important and frequently asked interview topics related to serialization.

What happens if you serialize an object, then change the class (e.g., add a new field), and then try to deserialize the old object? By default, this will fail with an java.io.InvalidClassException.

To prevent this, the serialization mechanism uses a version number called serialVersionUID.

• If you don't declare it: The JVM generates one at runtime based on the class's structure (name, fields, methods, etc.). Any change to the class structure will result in a different serialVersionUID.
• If you declare it: You explicitly provide a private static final long serialVersionUID. Now, if you make a compatible change (like adding a new field), the serialVersionUID remains the same, and deserialization will still work. The newly added field will simply be initialized to its default value.

Best practice is to always declare serialVersionUID in your serializable classes. This gives you control over which class changes are compatible and which are not.

The following video segment explains this concept very well.

5. Advanced Topics and Interview Pitfalls

For a senior role, you'll be expected to know more than just the basics. Here are some common follow-up questions.

Composition and NotSerializableException

If your class contains a field that is a reference to another object, that object's class must also implement Serializable. If it doesn't, the JVM will throw a java.io.NotSerializableException at runtime when you try to serialize the parent object. The only way around this is to mark the field as transient.

Inheritance

• If a superclass is Serializable, its subclasses are also serializable by default.
• If a subclass is Serializable but its superclass is not, the fields of the superclass are not serialized. During deserialization, the JVM will call the no-argument constructor of the non-serializable superclass to initialize its fields. This means any non-serializable superclass must have a no-arg constructor.

Customizing Serialization

While Serializable provides an automatic mechanism, you can gain full control.

1. writeObject() and readObject(): By providing private methods with these exact signatures in your Serializable class, you can define your own custom serialization logic. The JVM will invoke these instead of the default mechanism. This is useful for encrypting fields or handling transient fields that need special initialization.
2. Externalizable interface: This interface extends Serializable and requires you to implement writeExternal() and readExternal(). It gives you complete, mandatory control over the serialization process, disabling the default mechanism entirely.

Conclusion

You've now covered the Java serialization mechanism, a core concept that bridges object-oriented programming with I/O and network communication. It's a fundamental topic that demonstrates a deep understanding of the Java platform.

Key Takeaways:

• Purpose: Serialization converts an object's state into a byte stream for persistence or transmission.
• Core Interface: A class must implement the java.io.Serializable marker interface to be eligible for serialization.
• Core Classes: ObjectOutputStream.writeObject() serializes, and ObjectInputStream.readObject() deserializes.
• Controlling Fields: The transient keyword excludes a field from serialization, and static fields are never serialized as they belong to the class, not the instance.
• Versioning: Always declare a private static final long serialVersionUID to manage class evolution and prevent InvalidClassException.
• Common Pitfalls: Be aware of NotSerializableException with composed objects and the special handling of inheritance when a superclass is not serializable.

Preview of the Next Lesson:
This lesson marks the end of our module on advanced core Java topics. We will now transition into the world of frameworks, which build upon these core principles. Our next module, "Spring & Spring Boot Core," begins with the very foundation of the Spring framework. In the next lesson, we will explain Inversion of Control (IoC), Dependency Injection (DI), and compare constructor vs. setter injection.