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 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 (http://jcp.org/) 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 (http://jcp.org/jsr/detail/51.jsp) 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.
To study this article, please download the eBook it by following the link below:
