Java NIO, e-book, JAVA
[ Pobierz całość w formacie PDF ]
Java™ NIO
Ron Hitchens
Publisher: O'Reilly
First Edition August 2002
ISBN: 0-596-00288-2, 312 pages
Copyright
Index
Full Description
Reviews
Reader reviews
Errata
Java NIO
explores the new I/O capabilities of version 1.4 in detail and
shows you how to put these features to work to greatly improve the
efficiency of the Java code you write. This compact volume examines the
typical challenges that Java programmers face with I/O and shows you how
to take advantage of the capabilities of the new I/O features. You'll learn
how to put these tools to work using examples of common, real-world I/O
problems and see how the new features have a direct impact on
responsiveness, scalability, and reliability.
Because the NIO APIs supplement the I/O features of version 1.3, rather
than replace them, you'll also learn when to use new APIs and when the
older 1.3 I/O APIs are better suited to your particular application.
1
Table of Content
2
3
Dedication
To my wife, Karen.
What would I do without you?
Preface
Computers are useless. They can only give you answers.
—Pablo Picasso
This book is about advanced input/output on the Java platform, specifically I/O using the
Java 2 Standard Edition (J2SE) Software Development Kit (SDK), Version 1.4 and later.
The 1.4 release of J2SE, code-named Merlin, contains significant new I/O capabilities
that we'll explore in detail. These new I/O features are primarily collected in the
java.nio
package (and its subpackages) and have been dubbed New I/O (NIO). In this
book, you'll see how to put these exciting new features to work to greatly improve the I/O
efficiency of your Java applications.
Java has found its true home among Enterprise Applications (a slippery term if ever there
was one), but until the 1.4 release of the J2SE SDK, Java has been at a disadvantage
relative to natively compiled languages in the area of I/O. This weakness stems from
Java's greatest strength: Write Once, Run Anywhere. The need for the illusion of a virtual
machine, the JVM, means that compromises must be made to make all JVM deployment
platforms look the same when running Java bytecode. This need for commonality across
operating-system platforms has resulted, to some extent, in a least-common-denominator
approach.
Nowhere have these compromises been more sorely felt than in the arena of I/O. While
Java possesses a rich set of I/O classes, they have until now concentrated on providing
common capabilities, often at a high level of abstraction, across all operating systems.
These I/O classes have primarily been stream-oriented, often invoking methods on
several layers of objects to handle individual bytes or characters.
This object-oriented approach, composing behaviors by plugging I/O objects together,
offers tremendous flexibility but can be a performance killer when large amounts of data
must be handled. Efficiency is the goal of I/O, and efficient I/O often doesn't map well to
objects. Efficient I/O usually means that you must take the shortest path from Point A to
Point B. Complexity destroys performance when doing high-volume I/O.
The traditional I/O abstractions of the Java platform have served well and are appropriate
for a wide range of uses. But these classes do not scale well when moving large amounts
of data, nor do they provide some common I/O functionality widely available on most
operating systems today. These features — such as file locking, nonblocking I/O,
readiness selection, and memory mapping — are essential for scalability and may be
4
required to interact properly with non-Java applications, especially at the enterprise level.
The classic Java I/O mechanism doesn't model these common I/O services.
Real companies deploy real applications on real systems, not abstractions. In the real
world, performance matters — it matters a lot. The computer systems that companies buy
to deploy their large applications have high-performance I/O capabilities (often
developed at huge expense by the system vendors), which Java has until now been unable
to fully exploit. When the business need is to move a lot of data as fast as possible, the
ugly-but-fast solution usually wins out over pretty-but-slow. Time is money, after all.
JDK 1.4 is the first major Java release driven primarily by the Java Community Process.
The JCP (
provides a means by which users and vendors of Java products
can propose and specify new features for the Java platform. The subject of this book,
Java New I/O (NIO), is a direct result of one such proposal. Java Specification Request
#51 (
details the need for high-speed, scalable I/O, which
better leverages the I/O capabilities of the underlying operating system. The new classes
comprising
java.nio
and its subpackages, as well as
java.util.regex
and changes to a
few preexisting packages, are the resulting implementation of JSR 51. Refer to the JCP
web site for details on how the JSR process works and the evolution of NIO from initial
request to released reference implementation.
With the Merlin release, Java now has the tools to make use of these powerful
operating-system I/O capabilities where available. Java no longer needs to take a
backseat to any language when it comes to I/O performance.
Organization
This book is divided into six chapters, each dealing with a major aspect of Java NIO.
iscusses general I/O concepts to set the stage for the specific discussions that
follow.
through
cover the core of NIO: buffers, channels, and
selectors. Following that is a discussion of the new regular expression API. Regular
expression processing dovetails with I/O and was included under the umbrella of the JSR
51 feature set. To wrap up, we take a look at the new pluggable character set mapping
capabilities, which are also a part of NIO and JSR 51.
For the impatient, anxious to jump ahead, here is the executive summary:
Buffers
The new
Buffer
classes are the linkage between regular Java classes and channels.
Buffers implement fixed-size arrays of primitive data elements, wrapped inside an
object with state information. They provide a rendezvous point: a
Channel
consumes data you place in a
Buffer
(write) or deposits data (read) you can then
fetch from the buffer. There is also a special type of buffer that provides for
memory-mapping files.
5
[ Pobierz całość w formacie PDF ]