3

When we develop a class in java, the decision of whether you should make the class serializable or not is usually simple. If the class represents a model object that may be transferred across the n/w, it should be serializable.
Is this reasoning correct?
If so, what is the logic behind some of native Java API classes being serializable while others are not?
From this list of native classes that implement Serilizable, it appears that there is more than one reason to implement serializable.
http://download.oracle.com/javase/6/docs/api/java/io/class-use/Serializable.html

Any clarifications would be appreciated.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
Victor
  • 16,609
  • 71
  • 229
  • 409

2 Answers2

0

If the class represents a model object that may be transferred across the n/w, it should be serializable. Is this reasoning correct?

This reasoning is somewhat correct. If you are creating a public API where compatibility will be important, you may wish to make classes serializable which might one day need to be serialized. However, if you are creating a private application, classes should be made serializable only when needed. One reason (among a few) to attempt to avoid implementing Serializable is that it introduces the need to maintain and secure the newly added 'interface' to your serializable class: its byte-code representation.

If so, what is the logic behind some of native Java API classes being serializable while others are not? From this list of native classes that implement Serilizable, it appears that there is more than one reason to implement serializable.

One of the main reasons why many classes in the Java API do not implement Serializable is that, due to the nature of interfaces and inheritence, any class which extends a class which implements Serializable must also implement Serializable. For example, if java.lang.Object implemented Serializable, every java class would need to be designed to be properly serializable. This would place a large burden on the design of any class: suddenly, security and byte-code validity and compatibility would need to be considered.

Community
  • 1
  • 1
Kevin
  • 4,070
  • 4
  • 45
  • 67
0

The decision of when to implement Serializable should not be simple.

Implementing this interface exposes your class to an extralinguistic mechanism for creating objects. Extralinguistic, for this purpose, means outside of the usual constructor mechanism in the Java language. This is actually a bad thing which means that you may need to reverify all the class invariants on the deserialized object and enforce instance control (if such a system was put in place).

It can make your class easily corruptable and vulnerable to security hacks. It can also compromise encapsulation/information hiding (thereby forever tying you to a particular implementation if not done thoughtfully).

Implementing Serialzable should be a deliberate, conscious choice ... and then, and only then, you should serialize ONLY the logical state of the object. All other fields should be marked transient.

scottb
  • 9,908
  • 3
  • 40
  • 56