Serialization. Practical Tasks

A class Horse implements Serializable, but its parent Animal does not. You write a horse named Bucephalus to a file, read it back — and the name field is null. Remove the no-arg constructor from Animal, and writing still succeeds, but readObject() throws InvalidClassException: no valid constructor. Such rules stick much better once you have written the code yourself.

These Java serialization and cloning exercises practice the module «Serialization and Cloning in Java»: writing and reading objects with ObjectOutputStream and ObjectInputStream, transient and serialVersionUID, serializing a subclass of a non-serializable class, saving the shopping cart of the online shop to a file, inspecting a class with reflection, and making a deep copy of an object in three ways. Before you start, read the lessons Serialization and Deserialization in Java and Object Cloning in Java.

Student and Aspirant: Save the Group to a File (Serialization)

Student and Aspirant · part 4 of 4 · ← part 3

This continues the Student and Aspirant project. Take the Student and Aspirant classes from the exercise «Inheritance: Student and Aspirant», the static counter from «A counter of Students» and the ReflectionToString.toString() method from «Universal toString() with Reflection». Now the group has to be saved to a file and loaded back.

1. Make only Aspirant serializable: implements Serializable and an explicit serialVersionUID. Do not change Student yet. Write the methods static void saveGroup(Student[] group, String fileName) and static Student[] loadGroup(String fileName) that write and read the whole array. Close the streams with try-with-resources.
2. Save a group of one student and one aspirant. Which exception do you get, and on which object, given that Aspirant is a subclass of Student and is serializable?
3. Save a group of a single aspirant and read it back. If Student has only a constructor with parameters, reading fails: with which exception, and why was there no error on writing? Add an empty no-arg constructor to Student and try again. Print the aspirant with ReflectionToString.toString() before writing and after reading:

   Aspirant{firstName=John, lastName=Brown, group=PH-21, averageMark=5.0, researchWork=Quantum computing}
   Aspirant{firstName=null, lastName=null, group=null, averageMark=0.0, researchWork=Quantum computing}

   Explain why the Student fields are lost while researchWork is restored.
4. Without making Student serializable, add private writeObject() and readObject() methods to Aspirant that save and restore the Student fields (add getters and setters if you do not have them yet). Make sure that after reading the second line of the output matches the first one.
5. Now make Student itself serializable and remove writeObject()/readObject() from Aspirant. Does Aspirant still need implements Serializable? Save and read a group of a student and an aspirant and call getScholarship() for every element of the array you read: the amounts must match the ones before writing, and the second element must still be an Aspirant.
6. Print the value of the static student counter before writing and after reading. Why did reading two objects not increase it? What does the counter show in a separate program that only reads the file?
7. Mark the averageMark field as transient, save and read the group again and compare the scholarships. Why must such a field not be transient? Remove the modifier again.

Save the Last Cart with Serialization

Online Store · part 10 of 11 · ← part 10

Continue the online shop project: a customer should see their last purchase even after the program restarts.

1. Make the cart class and every class it refers to (product, cart item, customer) serializable. Declare serialVersionUID in each of them.
2. After a purchase is completed, save the cart to the file last-cart.ser, overwriting the previous one.
3. When the program starts, load the last cart and print its contents and the total. If there is no file yet (the first run), print No purchases yet instead of an exception stack trace.
4. Mark fields that should not or cannot be saved (for example, a reference to the payment service or a cached total) as transient, and restore them after reading.
5. Check compatibility: add a new field to the product class without changing serialVersionUID and read the old file. Then change serialVersionUID and note which exception you get when reading the same file.

Deep Copy of an Order: clone(), Copy Constructor and Serialization

You are given an order class:

public class Order {
    private final String id;
    private Customer customer;   // Customer: mutable fields name and email
    private List<Item> items;   // Item: mutable fields title and price

    // constructor, getters, toString()
}

1. Implement a shallow copy in Order with clone(). Print the results of copy == order, copy.getItems() == order.getItems() and copy.getItems().get(0) == order.getItems().get(0), then change the price of the first item in the copy and print the original. Expected results of the comparisons: false, true, true.
2. Make clone() deep: the copy must have its own list, its own Item objects and its own Customer. The method must not declare throws CloneNotSupportedException.
3. Write two more ways to make a deep copy: a copy constructor Order(Order other) and a utility method that copies the order through in-memory serialization (ByteArrayOutputStream and ByteArrayInputStream).
4. For each of the three ways, check that after copy.getItems().get(0).setPrice(0), copy.getItems().add(...) and copy.getCustomer().setName(...) the original has not changed.
5. Declare the items field as final. Which of the three ways stops compiling, and why?

What Each Task Practices

Three tasks practice built-in Java serialization (inheritance, transient, compatibility of class versions and what a class looks like to the serialization mechanism), and the fourth practices cloning and deep copying. If a solution does not work, go back to the lesson section from the table: each one has the rule and an example with its output.

What Most Often Goes Wrong in Solutions

Most mistakes in these tasks do not show up on the first run: the program writes the file without any exception, and the problem appears only on reading, after the class changes or when the copy is modified. So test every solution with the full cycle «write — change — read», not with a single write.

• Expecting the constructor to run on reading. The constructor of a serializable class is not called, so its logic (default values, checks) does not run after readObject().
• Streams without try-with-resources. An unclosed ObjectOutputStream can leave the file incomplete, and the next read fails with EOFException or StreamCorruptedException.
• An empty catch block. If you catch IOException and print nothing, a NotSerializableException with the name of the offending class goes unnoticed, and the program loads null.
• Copying the list instead of its elements. new ArrayList<>(items) and items.clone() create a new list that holds the same objects — it is still a shallow copy.
• Checking a copy with equals(). equals() compares contents and returns true for both a deep and a shallow copy. Only == on nested objects, and changing the copy and then printing the original, show whether the copy is independent.