Java Reference
In-Depth Information
the
Externalizable
interface. The big advantage of the
Externalizable
interface is perform-
ance. The algorithm for serialization uses reflection for marshaling and demarshaling. The
serialization algorithm will systematically determine the nontransient and nonstatic class
members through the use of reflection.
However, this can be quite expensive because the reflection algorithm costs in terms of
CPU cycles and memory. The costs result from the JVM having to dynamically discover class
properties during runtime. In situations where performance is more important than flexibility,
consider using a reflectionless approach to serialization, such as
Externalizable
. For more
information on reflection, refer to the following Sun tutorial:
http://java.sun.com/docs/
books/tutorial/reflect/
.
Customizing Serialization with the Externalizable Interface
If performance is a must, then you can serialize using the
java.io.Externalizable
interface
instead of the
Serializable
interface. So just how does
Externalizable
improve on the
default serialization mechanism?
Externalizable
requires that you write the details of
reading and writing the object's state to the byte stream. This is much more tedious than rely-
ing on reflection, but ultimately it provides more of a speed burst to your application. The
ObjectOutputStream
class no longer simplifies this process. You must use the methods
readExternal
and
writeExternal
and be aware of the member's type—whether it is a primitive
type, a
String
(i.e., UTF), or some other type of object, other than
String
, that is serializable.
Since you are involved in the low-level handling, you must read your object's members in the
same order in which they were written to the stream.
Listing 6-3 presents an example of how our
DVD
class might look if it were
Externalizable
.
For illustration purposes, the nuts and bolts of the class are not shown—just the code that
relates to
writeExternal
and
readExternal
. Both methods can be private since the serializa-
tion mechanism can circumvent the normally applicable accessibility rules for classes (i.e.,
the JVM can invoke an object's private serialization methods).
■
Note
If the
readObject
and
writeObject
methods are implemented in the
Serializable
object, the
heavy reliance on reflection is not required and there is actually a performance edge over the default seriali-
zation mechanism (i.e., implementing
Serializable
without overriding the
readObject
and
writeObject
methods).
This approach is similar to externalization, with some minor differences with regard to inheritance and
the handling of class metadata. The signatures of the methods to override appear in Listing 6-3. When you
override these methods, it is crucial that the order in which the class attributes are written to the stream is
the same as the order they are read back. As long as the serializable objects are not part of a class hierar-
chy,
readObject
and
writeObject
are implemented exactly as
readExternal
and
writeExternal
,as
discussed later in this section. Here are the method signatures for
readObject
and
writeObject
:
private void writeObject(java.io.ObjectOutputStream out) throws IOException
private Object readObject(java.io.ObjectInputStream in) throws IOException,
➥
ClassNotFoundException
