How does Java's serialization work and when it should be used instead of some other persistence technique?

Question

I\'ve been lately trying to learn more and generally test Java\'s serialization for both work and personal projects and I must say that the more I know about it, the less I

Answer 1

I bumped into this dilemma about a month ago (see the question I asked).

The main lesson I learned from it is use Java serialization only when necessary and if there's no other option. Like Jon said, it has it's downfalls, while other serialization techniques are much easier, faster and more portable.

Answer 2

Serializing means that you put your structured data in your classes into a flat order of bytecode to save it.

You should generally use other techniques than the buildin java-method, it is just made to work out of the box but if you have some changing contents or changing orders in future in your serialized classes, you get into trouble because you'll cannot load them correctly.

Answer 3

I would personally try to avoid Java's "built-in" serialization:

• It's not portable to other platforms
• It's not hugely efficient
• It's fragile - getting it to cope with multiple versions of a class is somewhat tricky. Even changing compilers can break serialization unless you're careful.

For details of what the actual bytes mean, see the Java Object Serialization Specification.

There are various alternatives, such as:

• XML and JSON, as you've shown (various XML flavours, of course)
• YAML
• Facebook's Thrift (RPC as well as serialization)
• Google Protocol Buffers
• Hessian (web services as well as serialization)
• Apache Avro
• Your own custom format

(Disclaimer: I work for Google, and I'm doing a port of Protocol Buffers to C# as my 20% project, so clearly I think that's a good bit of technology :)

Cross-platform formats are almost always more restrictive than platform-specific formats for obvious reasons - Protocol Buffers has a pretty limited set of native types, for example - but the interoperability can be incredibly useful. You also need to consider the impact of versioning, with backward and forward compatibility, etc. The text formats are generally hand-editable, but tend to be less efficient in both space and time.

Basically, you need to look at your requirements carefully.

Answer 4

see the Java Object Serialization Stream Protocol for a description of the file format an grammar used for serialized objects.

Personally I think the built-in serialization is acceptable to persist short-lived data (e.g. store the state of a session object between to http-requests) which is not relevant outside your application.

For data that has a longer live-time or should be used outside your application, I'd persist either into a database or at least use a more commonly used format...

Answer 5

How does Java's built-in serialization works?

Whenever we want to serialize an object, we implement java.io.Serializable interface. The interface which does not have any methods to implement, even though we are implementing it to indicate something to compiler or JVM (known as Marker Interface). So if JVM sees a Class is Serializable it perform some pre-processing operation on those classes. The operation is, it adds the following two sample methods.

private void writeObject(java.io.ObjectOutputStream stream)
            throws IOException {
        stream.writeObject(name); // object property
        stream.writeObject(address); // object property
    }

    private void readObject(java.io.ObjectInputStream stream)
            throws IOException, ClassNotFoundException {
        name = (String) stream.readObject(); // object property
        address = (String) stream.readObject();// object property
    }

When it should be used instead of some other persistence technique?

The built in Serialization is useful when sender and receiver both are Java. If you want to avoid the above kind of problems, we use XML or JSON with the help of frameworks.

Answer 6

The advantage of Java Object Serialization (JOS) is that it just works. There are also tools out there that do the same as JOS, but use an XML format instead of a binary format.

About the length: JOS writes some class information at the start, instead of as part of each instance - e.g. the full field names are recorded once, and an index into that list of names is used for instances of the class. This makes the output longer if you write only one instance of the class, but is more efficient if you write several (different) instances of it. It's not clear to me if your example actually uses a class, but this is the general reason why JOS is longer than one would expect.

BTW: this is incidental, but I don't think JSON records class names (as you have in your example), and so it might not do what you need.