What is the penalty for unnecessarily implementing Serializable?

Question

I need to develop a Java RMI application for my distributed systems class.

During the lecture, the professor was stressing to only let classes implement Serializable that have to be passed by value over the network.

This implies that there is some downside or penalty to letting too many classes implement Serializable. Classes that don't require to be sent over the network.

I don't see how there could be any downside since the serialization/deserialization would never happen if you never actually send it over the network.

Contagium

Why would it be serialized if it's never sent over the network? You don't think that adding implements Serializable makes your object become serialized with no reason? – Usury

by implementing an Interface you are merely adding a type/behaviour to your class... – Bituminize

I don't think it would be serialized if it's never sent over the network. That's why the supposed overhead doesn't make sense to me and that's why I asked the question. – Contagium

I don't understand the question. What would the penalty be other than 'unnecessary overhead'? And why would anything be serialized if it wasn't going to be sent over the network? Your question doesn't make much sense. – Scrubber

@Bituminize I have to develop a Java RMI application as a small project for my distributed systems class. During the lecture, the professor was stressing to only serialize classes that have to be passed by value. I don't think he would be stressing it if there wasn't some downside to serializing too many classes. – Contagium

@EJP You're right, I'm already assuming that there is some overhead. Even though I'm not sure there is any. I'm going to change the question to make it more clear. – Contagium

@duffymo The first part of the project is to develop an RMI applications. The second part is to develop a Java EE application. The third part is to develop a Google App Engine application. The course is an introduction to distributed systems so an introduction to Object Request Brokers seems reasonable. – Contagium

@duffymo 'Long out of date' is entirely in the eye of the beholder. RMI/IIOP is the basis of J2EE and there are millions of applications out there using it. I have flagged your comments as not constructive. – Scrubber

I'll start by pointing out that J2EE is 1999 teminology; we should use Java EE now. The fact that there are lots of Java EE apps out there doesn't change the fact that the world has moved on from all-Java applications. Your application will be more useful and longer-lived if it exposed HTTP services to clients. It's more than the eye of the beholder. It's what the marketplace has decided. google.co.uk/trends/explore?q=javaee,web%20services – Sigmatism

@duffymo: I disagree with your generalization. Age doesn't matter; technology exists to solve problems. The new fad of HTTP for everything doesn't really work for high performance applications. I agree that new applications can benefit from "newer" things like binary RPC protocol's but HTTP services are not really a direct replacement of cases where RMI was used... – Debora

I don't think RMI or serialization are associated with high performance. This is about distributed components and how it's done today. I'd be surprised to learn that CORBA mattered anymore. It's a 90s technology. Any student who is being taught that CORBA and RMI are cutting edge should get their money back. – Sigmatism

@Sigmatism J2EE and Java EE are the same thing with different names. CORBA is at the heart of most J2EE/Java EE implementations, and indeed there is an ORB inside every JRE out there. You can't describe that as 'dead'. Your FUD is off topic. – Scrubber

@EJP - keep telling yourself that. J2EE is the original name given in 1999 when Bill Joy announced it at Java One (I was there). The ORB is in every JRE, but nobody cares about it. Apparently you've missed the fact that HTTP web services and cloud have swept CORBA away. – Sigmatism

The accepted answer does not account for design/maintainability - there is definitely is a penalty. It's similar to unnecessarily exposing properties: unnecessarily implementing Serializable imposes an unnecessary intent (*this object may be serialized). Modifying serializable types may result in either version refining (which is a pain) or breaking software. Check out my answer – Tallou

Answer 1

only let classes implement Serializable that have to be passed by value over the network.

Your professor is suggesting you minimize your use of Serializable to areas where it's strictly needed.

This is because serialization is a strong candidate for leaking implementation. Implementing Serializable shows intent of serialization (even if the object is never actually serialized), which imposes the idea that developers should take caution when modifying those classes to avoid breaking software.

---

Joshua Bloch covers this in his book Effective Java.

The moment you serialize an object, the class that it was instantiated from can no longer be modified without special treatment^†. If you modify the class, the binary representation will no longer match the objects already serialized. Thus deserialization of any objects serialized before modifying the class will fail.

If a type implements Serializable, it has the potential to be serialized. If an instance of that type was serialized, you may break code by modifying it's implementation.

Since there's no easy way of knowing for sure that an instance of a serializable type has been serialized (albeit you may not intend for objects to be serialized), developers take strong caution when modifying implementations of those types.

---

^† - This could be avoided by properly versioning your serializable types, but due to the potential of versioning a type that had no contract change (with no compile time error handling support to notify you), it's best to keep explicit versioning minimal to avoid adding excess complexity to your design.

Tallou

This assumes that no explicit version ID is provided when implementing the Serializable interface which is a must IMO. You really don't want to leave yourself to the mercy of the VM implementation to generate it for you. – Debora

I think this answer deserves credit, although the problem is more of a meta-problem and harder to quantify than--say--how much memory your application is using. – Wraparound

@SanjayT.Sharma The answer also relates to versioning conflicts, where a developer changes the version without any changes to the contract. Using Serializable adds complexity that has no compile time error handling support (won't get a compiler error for versioning an impl change), thus requiring special treatment to avoid blow ups. IMO, it's best to set encapsulate that special treatment with requirements, narrowing the scope of potential errors. – Tallou

You need to reread the Object Versioning chapter of the Java Object Serialization Specification. It specifically and at length contradicts your assertions above. The ‘proper versioning’ you allude to occurs by default. – Scrubber

Answer 2

I would understand the professor's "only let classes implement Serializable that have to be passed by value over the network" differently. I would think the idea is that if you have to use a class in this way then make your own implementation of writeObject, readObject and readObjectNoData, which could be more efficient than the default implementation.

Chondrule

The original poster can probably best tell whether this interpretation is likely. – Unutterable

Answer 3

What is the penalty for unnecessarily implementing Serializable?

There is no penalty for unnecessarily implementing Serializable. If you never serialize the object, nothing happens just because you added implements Serializable. If you do serialize it, it works instead of failing. That's not a penalty.

Why the professor was stressing that is a mystery. Ask him. There is no overhead other than when serializing, and if you're passing objects by value via RMI you don't have any choice but to implement Serializable, so there is nothing to evalute the overhead against. It is meaningless.

Scrubber

That's kind of what I thought initially. Browsing through the archive of possible exam questions for the course, I encountered this question a number of times. The question asks to explain the difference between Remote, Local and Serializable. The second part asks what would happen if you make too many classes implement Serializable. I guess the answer would be "nothing", right? – Contagium

Yep. Just fewer runtime errors. However you need to be sure the prof. agrees with you, there are some strange ideas floating around out there. The JVM never looks at Serializable: only ObjectOutputStream does that. – Scrubber

@Sigmatism Re 'you are long out of date' I really have no idea what you are talking about, and I don't take kindly to pointless remarks of this nature. Kindly cut it out. The question is about RMI and I have answered it. Your inference is baseless. I'm not in need of any'heads-up' about RMI from you either. – Scrubber

I do know what I'm talking about. You have answered it; well enough for me to vote it up. I'm providing another viewpoint that a student and professor might benefit from. Don't take it so personally or even as criticism. – Sigmatism

Thank you for your answer. The thing is, I'm starting to think that I didn't interpret the question correctly. As I said, it's a re-occurring question in the archive of possible exam questions and it exists of two parts. Some versions of the question have a different second part: "What happens when you use Serializable instead of Remote?". This is a sensible question, to which I do know the answer. – Contagium

@Sigmatism OK, so what are you talking about? To whom was the remark 'you are long out of date' addressed? and why? – Scrubber

@Sigmatism You are comparing apples and oranges. Every J2EE system on the planet uses RMI internally and HTTP externally. They are not in competition. – Scrubber

Answer 4

If someone later want to subclass your serializable class, they will have to make sure that their class is indeed serializable too. That could require an effort they don’t want to do.

Say you have:

public class YourClass implements Serializable {
}

Now if I write:

class MyClass extends YourClass {
    private SomeoneElsesClass myField;
}

and SomeoneElsesClass is not serializable, my FindBugs will flag myField with the message “Non-transient non-serializable instance field in serializable class”. I am trying to keep my code clean from warning messages, but in this case, I cannot.

I’m often specializing Swing classes. Sometimes I want to have instance fields of non-serializable classes, which basically introduces errors in my code. In real life I only get a warning message, and as long as the object isn’t actually serialized, it works; I’m still annoyed with those warning messages.

Unutterable

This answer is entirely incorrect. Implemented interfaces are inherited. There is nothing extra to do. You should not be serializing Swing classes at all, and there is a specific warning against it in the Javadoc of every one of them. – Scrubber

Yes, implemented interfaces are inherited, that’s what is causing the trouble I wrote about. Are you referring to the following warning? “Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans™ has been added to the java.beans package. Please see XMLEncoder.” Does that invalidate anything of what I wrote? How? Does it remove the warning message I see in Eclipse? – Unutterable

@EJP Just because implemented interfaces are inherited that doesn't mean serialization will work correctly, just as using the interface on the parent class doesn't guarantee serializability. – Parapsychology

@Parapsychology That is exactly what it means, and exactly what it guarantees. If you have some counterexample in mind please provide it.. – Scrubber

@EJP It may "guarantee" it in the sense of establishing a contract, but it's not actually enforced until runtime. You can implement or extend Serializable in a class containing non-serializable fields and it'll compile fine. – Parapsychology