The stream manipulation methods Methods that customize the serialization mechanism

ObjectOutputStream s constructor takes an OutputStream as an argument. This is analagous to many of the streams we looked at in Chapt er 1 . ObjectOutputStream and ObjectInputStream are simply encoding and transformation layers. This enables RMI to send objects over the wire by opening a socket connection, associating the OutputStream with the socket connection, creating an ObjectOutputStream on top of the sockets OutputStream , and then calling writeObject . The other new write method is defaultWriteObject . defaultWriteObject makes it much easier to customize how instances of a single class are serialized. However, defaultWriteObject has some strange restrictions placed on when it can be called. Heres what the documentation says about defaultWriteObject : Write the nonstatic and nontransient fields of the current class to this stream. This may only be called from the writeObject method of the class being serialized. It will throw the NotActiveException if it is called otherwise. That is, defaultWriteObject is a method that works only when it is called from another specific method at a particular time. Since defaultWriteObject is useful only when you are customizing the information stored for a particular class, this turns out to be a reasonable restriction. Well talk more about defaultWriteObject later in the chapter, when we discuss how to make a class serializable.

10.2.1.2 The stream manipulation methods

ObjectOutputStream also implements four methods that deal with the basic mechanics of manipulating the stream: public void reset ; public void close ; public void flush ; public void useProtocolVersionint ver sion; With the exception of useProtocolVersion , these methods should be familiar. In fact, reset , close , and flush are standard stream methods. useProtocolVersion , on the other hand, changes the version of the serialization mechanism that is used. This is necessary because the serialization format and algorithm may need to change in a way thats not backwards-compatible. If another application needs to read in your serialized data, and the applications will be versioning independently or running in different versions of the JVM, you may want to standardize on a protocol version. There are two versions of the serialization protocol currently defined: PROTOCOL_VERSION_1 and PROTOCOL_VERSION_2. If you send serialized data to a 1.1 or earlier JVM, you should probably use PROTOCOL_VERSION_1. The most common case of this involves applets. Most applets run in browsers over which the developer has no control. This means, in particular, that the JVM running the applet could be anything, from Java 1.0.2 JVM running the applet could be anything, from Java 1.0.2 through the latest JVM. Most servers, on the other hand, are written using JDK1.2.2 or later. [ 3] If you pass serialized objects between an applet and a server, you should specify the serialization protocol. [ 3] The main exception is EJB containers that require earlier versions of Java. At this writing, for example, Oracle 8 is EJB container uses JDK 1.1.6.

10.2.1.3 Methods that customize the serialization mechanism

The last group of methods consists mostly of protected methods that provide hooks that allow the serialization mechanism itself, rather than the data associated to a particular class, to be customized. These methods are: public ObjectOutputStream.PutField putFields ; protected void annotateClassClass cl; protected void annotateProxyClassClass cl; protected boolean enableReplaceObjectboolean enable; protected Object replaceObjectObject obj; protected void drain ; protected void writeObjectOverrideObject obj; protected void writeClassDescriptorObjectStreamClass classdesc; protected void writeStreamHeader ; These methods are more important to people who tailor the serialization algorithm to a particular use or develop their own implementation of serialization. As such, they require a deeper understanding of the serialization algorithm. Well discuss these methods in more detail later, after weve gone over the actual algorithm used by the serialization mechanism.

10.2.2 ObjectInputStream