In-depth Insight: 5 things you don't know about serialization of Java objects

Some useful little knowledge about the serialization of Java objects is difficult to understand, but sooner or later it is useful to solve the Java programming challenge.

Serializing the Java object API it existed in JDK 1.1 from the beginning. A few things about serialization that this article describes will persuade you to revisit those standard Java APIs.

Introduction to Java serialization

Java object serialization is one of the pioneering features introduced in JDK 1.1 as a mechanism for converting the state of a Java object into a byte array for storage or transport, and then converting the byte array back to the original state of the Java object.

So far, nothing new or exciting has been seen, but this is a good starting point. We'll use person to discover 5 things you might not know about the serialization of Java objects.

1. Serialization allows refactoring

Serialization allows a certain number of class variants, even after refactoring, and ObjectInputStream can still read them well.

The key tasks that the Java Object serialization specification can automatically manage are:

· To add a new field to a class

· Change a field from static to non-static

· Change a field from transient to non-transient

Depending on the degree of backward compatibility required, the Conversion field form (converting from non-static to static or from non-transient to transient) or deleting a field requires additional message delivery.

Refactoring Serialization Classes

Now that we know that serialization allows refactoring, let's take a look at what happens when you add a new field to the person class.

As shown in Listing 3, PersonV2 introduces a new field that represents gender on the basis of the original person class.

Listing 3. Add a new field to the serialized person

Serialization uses a hash, which is calculated based on almost everything in a given source file-method name, field name, field type, access modification method, and so on-the serialization compares the hash value to the hash value in the serialized stream.

In order for the Java runtime to believe that the two types are actually the same, the second and subsequent versions of the person must have the same serialized version hash as the first version (stored as the private static final Serialversionuid field). Therefore, we need the Serialversionuid field, which is computed by running the JDK serialver command on the original (or V1) version of the person class.

Once you have the person's serialversionuid, you can not only create the PersonV2 object from the serialized data of the person of the original object (the new field is set as the default when a new field appears, the most common is "null"), and you can do the reverse: from It's no surprise that PersonV2 's data gets person by deserializing it.

2. Serialization is not secure

To the surprise and discomfort of Java developers, the serialized binary format is fully written in the document and is completely reversible. In fact, simply dumping the contents of a binary serialized stream into the console is sufficient to see what the class looks like and what it contains.

This has a negative impact on security. For example, when a remote method call is made through RMI, any private field in the object sent through the connection is almost always in clear text in the socket stream, which is obviously prone to even the simplest security issues.

Fortunately, serialization allows the "hook" serialization process and protects (or blurs) the field data after serialization and deserialization. You can do this by providing a writeobject method on the Serializable object.

Blurring serialized data

Assume that the sensitive data in the person class is the age field. After all, the lady Taboo talk about age. We can blur the data before serialization, move the number loop to the left one bit, and then reset it after deserialization. (You can develop a more secure algorithm, the current algorithm is just as an example.) ）

In order to "hook" the serialization process, we will implement a WriteObject method on the person, in order to "hook" the deserialization process, we will implement a ReadObject method on the same class. It is important that the details of the two methods be correct-if the access modification method, parameter, or name differs from the content in Listing 4, then the code will fail unnoticed and the age of the person will be exposed.

If you need to view the blurred data, you can always view the serialized data stream/file. Also, because the format is fully documented, the contents of the serialized stream can still be read, even if the class itself cannot be accessed.

3. Serialized data can be signed and sealed

The previous technique assumes that you want to obfuscate the serialized data instead of encrypting it or making sure it is not modified. Of course, password encryption and signature management can be achieved by using writeobject and ReadObject, but there is a better way.

If you need to encrypt and sign the entire object, it is easiest to put it in a javax.crypto.SealedObject and/or Java.security.SignedObject wrapper. Both are serializable, so wrapping the object in Sealedobject can create a "box" around the original object. You must have a symmetric key to decrypt it, and the key must be managed separately. Similarly, signedobject can be used for data validation, and symmetric keys must also be managed separately.

Together, these two objects make it easy to seal and sign serialized data without stressing the details of digital signature validation or encryption. It's simple, isn't it?

4. Serialization allows the agent to be placed in the stream

In many cases, a class contains a core data element through which you can derive or find other fields in the class. In this case, it is not necessary to serialize the entire object. You can mark a field as transient, but whenever a method accesses a field, the class must still explicitly generate code to check whether it is initialized.

If the first problem is serialization, it is best to specify a flyweight or proxy to be placed in the stream. Provides a writereplace method for the original person, which can serialize different types of objects instead of it. Similarly, if a readresolve method is found during deserialization, the method is called and the alternate object is supplied to the caller.

Packaging and unpacking agents

The Writereplace and Readresolve methods enable the person class to package all its data (or its core data) into a single personproxy, put it into a stream, and then unpack it when deserializing.

Listing 5. You complete me, I take your place

Note that Personproxy must track all data for person. This usually means that the proxy needs to be an internal class of person so that the private field can be accessed. Sometimes proxies also need to track other object references and serialize them manually, such as the spouse of a person.

This technique is one of the few techniques that does not require a read/write balance. For example, a version of a class that is re-formed into another type can provide a Readresolve method to silently convert the serialized object to a new type. Similarly, it can use the Writereplace method to serialize the old class into a new version.

5. Trust, but verify that

It is not a problem to think that the data in the serialized stream is always consistent with the data originally written to the stream. But, as one former president of the United States said, "Trust, but verify."

For serialized objects, this means validating the fields to ensure that they still have the correct values after deserialization, "just in case." To do this, you can implement the ObjectInputValidation interface and override the Validateobject () method. If the method is called to find an error somewhere, a invalidobjectexception is thrown.

Welcome to join the Learning Exchange Group 569772982, we learn to communicate together.

In-depth Insight: 5 things you don't know about serialization of Java objects