This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Meaning of Serializable

Posted by Bill Venners on 02 Sep 1998, 5:07 PM

Al,

> Hi yall. I've just looked through the forum on your beanification column,
> and wanted to put forward an idea of mine which I've come up with
> with regards to Beanification.

> I think that it's a good idea that most objects can be treated
> as Beans. I think that sometimes it is not necessarily the case
> that *all* objects should be treated as beans though. Some objects
> are holders for algorithms (say, the Math object in java.lang),
> and some objects have no concept on what it means to be saved
> (say, for instance, a Transaction object which may have run-time
> sense, but not necessarily persistant sense).

> The main worry that I have re: beanification is implementing the
> Serialisable interface. In my mind, the Java spec hasn't got it
> right in the saving/loading of objects, but that isn't the issue here.
> The problem is that marking an object as Serialisable may do more damage
> than it is worth. Consider the following:

> public MyClass implements Serializable {
> Image anImage = new Image();
> }

> Now, although this object declares itself to be serializable,
> in practise it isn't. This kind of hand-wavy-error just to gain
> a Bean(TM) stamp on it results in seriously difficult to debug
> code, especially if a decent IDE points out all the non-transient
> non-serialisable instance variables.

> The issue is that you shouldn't say you're Serializable unless you're
> sure you *are* serializable. Most people will not test this,
> especially if they are just writing an object which they never
> expect to save. If The Great Book Of Coding Standards says that
> you should create a class with 0-arg constructor and implement
> the Serializable interface, then we've lost the point of it
> anyway ... instead, we'll have a whole bunch of objects which
> are marked Serializable but which trash your IDE all the time
> with NotSerializableExceptions all over the place.

> This is even more noticable with sub-classes;

> public MySubClass extends MyClass {
> Image iDontCareAboutBeingSerializable;
> }

> The point: class heirarchies, signatures and interfaces should
> be designed, and decided on if a class is Serializable rather
> than a coding convention. Yes, it is a good idea -- but only
> if coders understand the consequences.

I agree with this, and think it is an important point to make.
Implementing Serializable should mean instances can actually
be serialized.

bv