Writing data Resource management
1.1.3 OutputStream
OutputStream is an abstract class that represents a data sink. Once it is created, client code can write information to it. OutputStream consists of the following methods: public void close throws IOException public void flush throws IOException public void writebyte[] buffer throws IOExcep tion public void writebyte[] buffer, int startingOffset, int numberOfBytes throws IOException public void writeint value throws IOException The OutputStream class is a little simpler than InputStream ; it doesnt support navigation. After all, you probably dont want to go back and write information a second time. OutputStream methods serve two purposes: writing data and resource management.1.1.3.1 Writing data
OutputStream defines three basic methods for writing data: public void writebyte[] buffer throws IOException public void writebyte[] buffer, int startingOffset, int numberOfBytes throws IOException public void writeint value throws IOException These methods are analogous to the read methods defined for InputStream . Just as there was one basic method for reading a single byte of data, there is one basic method, writeint value , for writing a single byte of data. The argument to this write method should be an integer between 0 and 255. If not, it is reduced to module 256 before being written. Just as there were two array-based variants of read , there are two methods for writing arrays of bytes. writebyte[] buffer causes all the bytes in the array to be written out to the stream. writebyte[] buffer, int startingOffset, int numberOfBytes causes numberOfBytes bytes to be written, starting with the value at buffer[startingOffset] . The fact that the argument to the basic write method is an integer is somewhat peculiar. Recall that read returned an integer, rather than a byte, in order to allow instances of InputStream to signal exceptional conditions. write takes an integer, rather than a byte, so that the read and write method declarations are parallel. In other words, if youve read a value in from a stream, and its not -1, you should be able to write it out to another stream without casting it.1.1.3.2 Resource management
OutputStream defines two resource management methods: public void close public void flush close serves exactly the same role for OutputStream as it did for InputStream ™itshould be called when the client code is done using the stream and wishes to free up all the associated operating-system resources. The flush method is necessary because output streams frequently use a buffer to store data that is being written. This is especially true when data is being written to either a file or a socket. Passing data to the operating system a single byte at a time can be expensive. A much more practical strategy is to buffer the data at the JVM level and occasionally call flush to send the data en masse.1.2 Viewing a File
To make this discussion more concrete, we will now discuss a simple application that allows the user to display the contents of a file in a JTextArea . The application is called ViewFile and is shown in Exam ple 1- 1 . Note that the applications main method is defined in the c om.ora.rmibook.chapter1.ViewFile class. [ 3] The resulting screenshot is shown in Figur e 1- 1 . [ 3] This example uses classes from the Java Swing libraries. If you would like more information on Swing, see Java Swing OReilly or Java Foundation Classes in a Nutshell OReilly. Figure 1-1. The ViewFile applicationParts
» 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