Are there objections against invoking writeExternal instead of writeObject?

If it is known that a class A implements Externalizable, is it then bad practice to serialize an object of A by invoking a.writeExternal(objOut) instead of objOut.writeObject(a)? I would like to use this in a (customized) serialization method of a class that contains a number of A objects, in order to reduce memory footprint (it avoids repeatedly storing structural information about class A).

[402 byte] By [MN3M0N1CSa] at [2007-11-26 16:14:04]
# 1
Generally it would be considered bad practice but there are exceptions to every rule. However I don't think your justification holds water. How and where is that going to reduce memory consumption?
ejpa at 2007-7-8 22:36:51 > top of Java-index,Core,Core APIs...
# 2

Currently I am using object input/output streams over an socket to transfer some large structure. Because the amount of data to be transferred was causing the main bottleneck in the performance, I tried to lower this amount by implementing Externalizable instead of Serializable. To my surprise, this only increased the amount of data. By calling writeExternal on the objects that comprise the large structure, the amount of data does decrease.

MN3M0N1CSa at 2007-7-8 22:36:51 > top of Java-index,Core,Core APIs...
# 3
So now you're talking about the amount of data transmitted?
ejpa at 2007-7-8 22:36:51 > top of Java-index,Core,Core APIs...
# 4
When i send objects over an objectoutputstream, the amount of data to transfer is deternmined by the bytes used to serialize an object?
MN3M0N1CSa at 2007-7-8 22:36:51 > top of Java-index,Core,Core APIs...
# 5

Obviously, that's just a tautology, but you started out talking about 'memory footprint' which is a different issue from bandwidth usage. If you're concerned about bandwidth usage, of course you can reduce it arbitrarily by implementing Externalizable and doing whatever you like inside readExternal() and writeExternal(). But that has nothing to do with memory footprint.

ejpa at 2007-7-8 22:36:51 > top of Java-index,Core,Core APIs...