When should we implement Serializable interface?

java serialization

public class Contact implements Serializable {
    private String name;
    private String email;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

When should I implement Serializable interface? Why do we do that? Does it give any advantages or security?

FYI the accepted answer here is incomplete and misleading, because it doesn't address the security drawbacks. See Effective Java, item 86: Implement Serializable with great caution. Raedwald's answer here saying not to use serialization is the correct one.

Kasun Siyambalapitiya

From What's this "serialization" thing all about?: It lets you take an object or group of objects, put them on a disk or send them through a wire or wireless transport mechanism, then later, perhaps on another computer, reverse the process: resurrect the original object(s). The basic mechanisms are to flatten object(s) into a one-dimensional stream of bits, and to turn that stream of bits back into the original object(s). Like the Transporter on Star Trek, it's all about taking something complicated and turning it into a flat sequence of 1s and 0s, then taking that sequence of 1s and 0s (possibly at another place, possibly at another time) and reconstructing the original complicated "something." So, implement the Serializable interface when you need to store a copy of the object, send them to another process which runs on the same system or over the network. Because you want to store or send an object. It makes storing and sending objects easy. It has nothing to do with security.

Is it a best practice to implement seriablizble interface to all of domain models...

@theJava It's not a question of best practices. It's a question of whether or not you need to series of bytes.

When using JSON you don't have to implement this interface and can simply send that string.. so Im still not sure why to use this interface when you can use JSON.

@YonatanNir I'm not sure why one would use JSON when MsgPack, Avro, Thrift, or Protobuf are better for IO transfer.

@YonatanNir A Strictly defined schema is better. And JSON is meant to be human readable, while binary encoded formats are far more efficient over the wire

Raedwald

The answer to this question is, perhaps surprisingly, never, or more realistically, only when you are forced to for interoperability with legacy code. This is the recommendation in Effective Java, 3rd Edition by Joshua Bloch:

There is no reason to use Java serialization in any new system you write

Oracle's chief architect, Mark Reinhold, is on record as saying removing the current Java serialization mechanism is a long-term goal.

Why Java serialization is flawed

Java provides as part of the language a serialization scheme you can opt in to, by using the Serializable interface. This scheme however has several intractable flaws and should be treated as a failed experiment by the Java language designers.

It fundamentally pretends that one can talk about the serialized form of an object. But there are infinitely many serialization schemes, resulting in infinitely many serialized forms. By imposing one scheme, without any way of changing the scheme, applications can not use a scheme most appropriate for them.

It is implemented as an additional means of constructing objects, which bypasses any precondition checks your constructors or factory methods perform. Unless tricky, error prone, and difficult to test extra deserialization code is written, your code probably has a gaping security weakness.

Testing interoperability of different versions of the serialized form is very difficult.

Handling of immutable objects is troublesome.

What to do instead

Instead, use a serialization scheme that you can explicitly control. Such as Protocol Buffers, JSON, XML, or your own custom scheme.

not much of an expert at that level but feel you've got a point.

I think it's the best answer!

The answer we need! Thanks.

What about this Sonar rule rules.sonarsource.com/java/RSPEC-1948 - stating that most J2EE frameworks flush to disk on heavy load. Sounds outdated to me, but does someone know more?

The only way so far that I know for your app to survive Tomcat restart is to implement serialization on all items stored in session scope beans. Right? I can guess there is another way but way back some years ago that was legal way to go.

roottraveller

Implement the Serializable interface when you want to be able to convert an instance of a class into a series of bytes or when you think that a Serializable object might reference an instance of your class. Serializable classes are useful when you want to persist instances of them or send them over a wire. Instances of Serializable classes can be easily transmitted. Serialization does have some security consequences, however. Read Joshua Bloch's Effective Java.

When should we implement Serializable interface?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US