The write methods ObjectOutputStream
10.2 Using Serialization
Serialization is a mechanism built into the core Java libraries for writing a graph of objects into a stream of data. This stream of data can then be programmatically manipulated, and a deep copy of the objects can be made by reversing the process. This reversal is often called deserialization. In particular, there are three main uses of serialization: As a persistence mechanism If the stream being used is FileOutputStream , then the data will automatically be written to a file. As a copy mechanism If the stream being used is ByteArrayOutputStream , then the data will be written to a byte array in memory. This byte array can then be used to create duplicates of the original objects. As a communication mechanism If the stream being used comes from a socket, then the data will automatically be sent over the wire to the receiving socket, at which point another program will decide what to do. The important thing to note is that the use of serialization is independent of the serialization algorithm itself. If we have a serializable class, we can save it to a file or make a copy of it simply by changing the way we use the output of the serialization mechanism. As you might expect, serialization is implemented using a pair of streams. Even though the code that underlies serialization is quite complex, the way you invoke it is designed to make serialization as transparent as possible to Java developers. To serialize an object, create an instance of ObjectOutputStream and call the writeObject method; to read in a serialized object, create an instance of ObjectInputStream and call the readObject object.10.2.1 ObjectOutputStream
ObjectOutputStream , defined in the java.io package, is a stream that implements the writing-out part of the serialization algorithm. [ 2] The methods implemented by ObjectOutputStream can be grouped into three categories: methods that write information to the stream, methods used to control the streams behavior, and methods used to customize the serialization algorithm. [ 2] RMI actually uses a subclass of ObjectOutputStream to customize its behavior.10.2.1.1 The write methods
The first, and most intuitive, category consists of the write methods: public void writebyte[] b; public void writebyte[] b, int off, int len; public void writeint data; public void writeBooleanboolean data; public void writeByteint data; public void writeBytesString data; public void writeCharint data; public void writeCharsString data; public void writeDoubledouble data; public void writeFields ; public void writeFloatfloat data; public void writeIntint data; public void writeLonglong data; public void writeObjectObject obj; public void writeShortint data; public void writeUTFString s; public void defaultWriteObject ; For the most part, these methods should seem familiar. writeFloat , for example, works exactly as you would expect after reading Chapt er 1 ™it takes a floating-point number and encodes the number as four bytes. There are, however, two new methods here: writeObject and defaultWriteObject . writeObject serializes an object. In fact, writeObject is often the instrument of the serialization mechanism itself. In the simplest and most common case, serializing an object involves doing two things: creating an ObjectOuptutStream and calling writeObject with a single top-level instance. The following code snippet shows the entire process, storing an object™and all the objects to which it refers™into a file: FileOutputStream underlyingStream = new FileOutputStreamC:\\temp\\test; ObjectOutputStream serializer = new ObjectOutputStreamunderlyingStream; serializer.writeObjectserializableObject; Of course, this works seamlessly with the other methods for writing data. That is, if you wanted to write two floats, a String, and an object to a file, you could do so with the following code snippet: FileOutputStream underlyingStream = new FileOutputStreamC:\\temp\\test; ObjectOutputStream serializer = new ObjectOutputStreamunderlyingStream; serializer.writeFloatfirstFloat; serializer.writeFloatsecongFloat; serializer.writeUTFaString; serializer.writeObjectserializableObject; 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
Parts
» OReilly.Java.Rmi. 2313KB Mar 29 2010 05:03:49 AM
» Writing data Resource management
» Some Useful Intermediate Streams
» Revisiting the ViewFile Application
» Protocols Metadata Protocols and Metadata
» The accept method A Simple Web Server
» Customizing Socket Behavior Sockets
» Direct Stream Manipulation Subclassing Socket Is a Better Solution
» A Special-Purpose Socket Special-Purpose Sockets
» Factories Socket Factories Special-Purpose Sockets
» Registering providers Using SSL with JSSE
» Configuring SSLServerSocket Using SSL with JSSE
» A Network-Based Printer A Socket-Based Printer Server
» The Basic Objects A Socket-Based Printer Server
» DocumentDescription Encapsulation and Sending Objects
» ClientNetworkWrapper Network-Aware Wrapper Objects
» ServerNetworkWrapper Network-Aware Wrapper Objects
» Passing by Value Versus Passing by Reference
» The Architecture Diagram Revisited
» The Printer Interface Implementing the Basic Objects
» Examining the skeleton Implementing a Printer
» DocumentDescription The Data Objects
» The Client Application Summary
» The Bank Example Introducing the Bank Example
» Security Scalability Design Postponements
» The Basic Use Case A Distributed Architecturefor the Bank Example
» Partial Failures Problems That Arise in Distributed Applications
» Network Latency Problems That Arise in Distributed Applications
» Memory, in general, is not an issue here Sockets in RMI arent a limitation either
» Applying this to Bank versus Accounts
» Should We Implement Bank or Account?
» Iterators, again Applying this to the Account interface
» Applying this to the Account interface
» Data Objects Dont Usually Have Functional Methods Interfaces Give You the Data Objects
» Accounting for Partial Failure
» A Server That Extends UnicastRemoteObject A Server That Does Not Extend UnicastRemoteObject
» The benefits of UnicastRemoteObject
» The costs of UnicastRemoteObject
» Getting Rid of the Skeletons
» Build Test Applications The Rest of the Application
» Dont Hold Connections to a Server Youre Not Using
» Validate Arguments on the Client Side Whenever Reasonable
» The Actual Client Application
» Deploying the Application The Rest of the Application
» Drilling Down on Object Creation
» The write methods ObjectOutputStream
» The stream manipulation methods Methods that customize the serialization mechanism
» The read methods ObjectInputStream
» Declaring transient fields Implementing writeObject and readObject
» Implement the Serializable Interface Make Sure That Superclass State Is Handled Correctly
» The Data Format The Serialization Algorithm
» Writing A Simplified Version of the Serialization Algorithm
» annotateClass replaceObject RMI Customizes the Serialization Algorithm
» Maintaining Direct Connections The Serialization Algorithm
» The Two Types of Versioning Problems
» How Serialization Detects When a Class Has Changed Implementing Your Own Versioning Scheme
» Serialization Depends on Reflection Serialization Has a Verbose Data Format
» It Is Easy to Send More Data Than Is Required
» Comparing Externalizable to Serializable
» The Calling Stack Basic Terminology
» The Heap Threads Basic Terminology
» Mutexes Applying This to the Printer Server
» Controlling Individual Threads Threading Concepts
» Coordinating Thread Activities Threading Concepts
» Cache Management Assigning Priorities to Threads
» The effects of synchronization on the threads local cache
» The wait methods The notify methods
» Starting a thread is easy Stopping a thread is harder
» Using Runnable instead of subclassing Thread Useful methods defined on the Thread class
» The Basic Task Implementing Threading
» Applying this to the bank example
» Synchronize around the smallest possible block of code
» Dont synchronize across device accesses
» Concurrent modification exceptions Be Careful When Using Container Classes
» Start with Code That Works Use Containers to Mediate Interthread Communication
» Immutable Objects Are Automatically Threadsafe Always Have a Safe Way to Stop Your Threads
» Pay Careful Attention to What You Serialize
» Use Threading to Reduce Response-Time Variance Limit the Number of Objects a Thread Touches
» Acquire Locks in a Fixed Order Use Worker Threads to Prevent Deadlocks
» The Idea of a Pool Two Interfaces That Define a Pool
» A First Implementation of Pooling
» Problems with SimplePool Pools: An Extended Example
» The Creation Thread Pools: An Extended Example
» Gradually Shrinking the Pool
» What Were Testing Testing the Bank Application
» When Are Naming Services Appropriate?
» bind , rebind , and unbind lookup and list
» Bootstrapping the Registry The RMI Registry Is an RMI Server
» Querying the Registry Launching an Application-Specific Registry
» Filesystems Yellow pages The general idea of directories and entries
» Security Issues The RMI Registry
» Operations on contexts Hierarchies
» Attributes are string-valued, name-value pairs
» Federation Federation and Threading
» Value Objects Represent Sets and Lists Paths, Names, and Attributes Are All Distinct
» AttributeSet The Value Objects
» Path and ContextList The Value Objects
» The Context Interface The Java Naming and Directory Interface JNDI
» Using JNDI with the Bank Example
» How RMI Solves the Bootstrapping Problem
» Ordinary Garbage Collection Distributed Garbage Collection
» Defining Network Garbage Distributed Garbage Collection
» Leasing Distributed Garbage Collection
» The Actual Distributed Garbage Collector The Unreferenced Interface
» The Standard Log RMIs Logging Facilities
» The Specialized Logs RMIs Logging Facilities
» java.rmi.server.randomIDs sun.rmi.server.exceptionTrace
» sun.rmi.dgc.client.gcInterval sun.rmi.dgc.server.gcInterval
» sun.rmi.dgc.checkInterval sun.rmi.dgc.cleanInterval
» Resource Management Factories and the Activation Framework
» A Basic Factory Implementing a Generic Factory
» The new factory Building on the Account-Locking Mechanism
» The new account The launch code and the client
» Persistence and the Server Lifecycle
» Making a server into an activatable object
» Deploying an Activatable System
» ActivationDesc, ActivationGroupDesc, and ActivationGroup in More Detail
» Shutting Down an Activatable Server
» -port -log rmid Command-Line Arguments
» sun.rmi.server.activation.debugExec
» A Final Word About Factories
» Implementing Serializable Implementing equals and hashCode
» Modifying Ordinary Servers Incorporating a Custom Socket into an Application
» Modifying Activatable Servers Incorporating a Custom Socket into an Application
» Interaction with Parameters Incorporating a Custom Socket into an Application
» A Redeployment Scenario How Dynamic Classloading Works
» A Multiple-Deployment Scenario How Dynamic Classloading Works
» Requesting a Class The Class Server
» Receiving a Class Handling JAR files
» Suns Class Server The Class Server
» Server-Side Changes Using Dynamic Classloadingin an Application
» Naming-Service Changes Using Dynamic Classloadingin an Application
» Client-Side Changes Disabling Dynamic Classloading Entirely
» A Different Kind of Security Problem
» AWT permissions The Types of Permissions
» File permissions Socket permissions
» Property permissions The Types of Permissions
» Installing an Instance of SecurityManager
» How a Security Manager Works java.security.debug
» Using Security Policies with RMI Policy Tool
» Printer-Type Methods Report-Type Methods
» Client-side polling Polling code in the printer application
» Server-side callbacks Define a client-side callback interface
» Implement the client-side interface
» Server-evaluation models Ch a pt e r 7
» Iterators on the client side
» Implementing Background Downloading on the Client Side
» The Common Gateway Interface Servlets
» Naming services and the server machine
» The Servlet Code A Servlet Implementationof HTTP Tunneling
» Modifying the Tunneling Mechanism
» Disabling HTTP Tunneling HTTP Tunneling
» Defining the Interface Generating Stubs and Skeletons
» The Server The Launch and Client Code
Show more