Serializing/deserializing gacContainerR (Java record)
In a nutshell, the minimalist design of declaring Java records and their semantic constraints allows the serialization/deserialization operations to act differently from a typical Java class. And when I say “differently” I actually should say much better and robust. How so? Well, the serialization of a Java record is based only on its component’s state, while deserialization relies on the single point of entry for a Java record, its canonical constructor. Remember that the only way to create a Java record is to call directly/indirectly its canonical constructor? This applies to deserialization as well, so this operation can no longer bypass the canonical constructor.That being said, the gacContainerR object is a MelonContainerRecord instance:
MelonContainerRecord gacContainerR = new MelonContainerRecord(
LocalDate.now().plusDays(15), “ML9000SQA0”,
new Melon(“Gac”, 5000));
After serializing it in a file called object_record.data we obtain the byte stream representing the gacContainerR state. While you can inspect this file in the bundled code (use a hex-editor such as https://hexed.it/), here is a human-readable interpretation of its content:
Figure 4.7 – Human-readable interpretation of MelonContainerRecord serialization
Yes, you’re right, with the exception of the class name (MelonContainerRecord) the rest is the same as in figure 4.3. This sustains the migration from ordinary/regular Java classes to Java records. This time, the compiler can use the accessors exposed by the record, so no dark magic is needed.Ok, so nothing got our attention here, so let’s examine the deserialization operation.Remember that for regular Java classes, the deserialization builds the object-graph from top-down. In the case of Java records, this operation takes place from bottom-up, so in reverse order. In other words, this time, the compiler reads first the fields (primitives and reconstructed objects) from the stream and stores them in memory. Next, having all the fields in its hands, the compiler tries to match these fields (their names and values) against the components of the record. Any field from the stream that doesn’t match a component (name and value) is dropped from the deserialization operation. Finally, after the match is successfully performed, the compiler calls the canonical constructor to reconstruct the record object state.
Deserializing malicious stream
In the bundled code, you can find a file named object_record_malicious.data where we replaced the valid batch ML9000SQA0 with the invalid batch 0000000000. This time, deserializing this malicious stream will result in the exception from the following figure.
Figure 4.9 – Deserializing malicious stream causing an exception
As you already know, this exception origin in our guarding condition added in the explicit canonical constructor of our Java record.It is obvious that Java records significantly improve serialization/deserialization operations. This time, there is no moment when the reconstructed objects are in a corrupted state, and the malicious streams can be intercepted by guarding conditions placed in the canonical/compact constructor.In other words, the record’s semantically constraints, their minimalist design, the state accessible only via the accessor methods, and the object creation only via the canonical constructors sustain the serialization/deserialization as a trusted process.
Refactoring legacy serialization
Serialization/deserialization via Java records is awesome, but what can we do in case of legacy code, such as MelonContainer? We cannot take all our legacy classes that act as carriers of data and rewrite them as Java records. It will consume a lot of work and time.Actually, there is a solution backed in the serialization mechanism that requires us to add two methods named writeReplace() and readResolve(). By following this reasonable refactoring step, we can serialize legacy code as records and deserialize it back into legacy code.If we apply this refactoring step to MelonContainer then we start by adding in this class the writeReplace() method as follows:
@Serial
private Object writeReplace() throws ObjectStreamException {
return new MelonContainerRecord(expiration, batch, melon);
}
The writeReplace() method must throw an ObjectStreamException and return an instance of MelonContainerRecord. The compiler will use this method for serializing MelonContainer instances as long as we mark it with the @Serial annotation. Now, the serialization of a MelonContainer instance will produce the object.data file containing the byte stream corresponding to a MelonContainerRecord instance.Next, the readResolve() method must be added to the MelonContainerRecord as follows:
@Serial
private Object readResolve() throws ObjectStreamException {
return new MelonContainer(expiration, batch, melon);
}
The readResolve() method must throw an ObjectStreamException and return an instance of MelonContainer. Again, the compiler will use this method for deserializing MelonContainerRecord instances as long as we mark it with the @Serial annotation.When the compiler deserialize an instance of MelonContainerRecord it will call the canonical constructor of this record, so it will pass through our guarding conditions. This means that a malicious stream will not pass the guarding conditions so we avoid creating corrupted objects. If the stream contains valid values then the readResolve() method will use them to reconstruct the legacy MelonContainer.Hey, Kotlin/Lombok can you do this? No, you can’t!In the bundled code, you can find a file named object_malicious.data that you can use to practice the previous statement.