The stream-based I/O uses streams to transfer data between a data source/sink and a Java program. The Java program reads from or writes to a stream one byte at a time. This approach to performing I/O operations is slow. The new input/output (NIO) solves the slow speed problem in the old stream based I/O.

In NIO , you deal with channels and buffers for I/O operations. A channel is like a stream. It represents a connection between a data source/sink and a Java program for data transfer. There is one difference between a channel and a stream. A stream can be used for one-way data transfer. That is, an input stream can only transfer data from a data source to a Java program; an output stream can only transfer data from a Java program to a data sink. However, a channel provides a two-way data transfer facility. You can use a channel to read data as well as to write data. You can obtain a read-only channel, a write-only channel, or a read-write channel, depending on your needs.

In stream-based I/O , the basic unit of data transfer is a byte. In channel-based NIO , the basic unit of data transfer is a buffer. A buffer is a bounded data container. That is, a buffer has a fixed capacity that determines the upper limit of the data it may contain. In stream-based I/O, you write data directly to the stream. In channel-based I/O, you write data into a buffer; you pass that buffer to the channel, which writes the data to the data sink. Similarly, when you want to read data from a data source, you pass a buffer to a channel. The channel reads data from the data source into the buffer. You read data from the buffer. Figure 9-1 depicts the interaction between a channel, a buffer, a data source, a data sink, and a Java program. It is evident that the most important parts in this interaction are reading from a buffer and writing into a buffer. I discuss buffers and channels in detail in subsequent sections.

A buffer is a fixed-length data container. There is a separate buffer type to hold data for each type of primitive value, except for boolean type values. A buffer is an object in your program. You have a separate class to represent each type of buffer. All buffer classes are inherited from an abstract Buffer class. Buffer classes that hold primitive values are as follows:

An object of an XxxBuffer class is used to hold data of the Xxx primitive data type. For example, a ByteBuffer holds byte values; a ShortBuffer holds short values; a CharBuffer is holds characters, and so on. The following are the four important properties of a buffer, which you must understand to use it effectively:

The capacity of a buffer is the maximum number of elements that it can hold. The capacity of a buffer is fixed when the buffer is created. You can think of the capacity of a buffer as the length of an array. Once you create an array, its length is fixed. Similarly, once you create a buffer, its capacity is fixed. However, a buffer is not necessarily backed by an array. You can check if a buffer is backed by an array by calling its hasArray() method, which returns true if the buffer is backed by an array. You can get access to the backing array of a buffer by using the array() method of the buffer object. Once you get access to the backing array of a buffer, any changes made to that array will be reflected in the buffer. A buffer has a capacity() method that returns its capacity as an int.

You can create a buffer of a particular kind in many ways. You can create a buffer by using the allocate() factory method of a particular buffer class as follows:

A byte buffer gets special treatment in NIO. It has an extra method called allocateDirect() that creates a byte buffer for which the memory is allocated from the operating system memory, not from the JVM heap. This avoids copying the contents to intermediate buffers during I/O operations. A direct buffer has an additional creation cost. However, it is faster during the I/O operations. You should use a direct byte buffer when a buffer is long-lived. You can use the isDirect() method of the ByteBuffer class to check if a buffer is direct or non-direct.

Another way to create a buffer is to wrap an array using the buffer’s static wrap() method:

You can use the same technique to create a buffer to store other primitive values. I discuss other ways of creating a buffer later in this section.

Position and limit are two properties of a buffer. When a buffer is created, its position is set to 0 and its limit is equal to its capacity. A buffer’s position is the index of the next element to be read or written. A buffer’s limit is the index of the first element that should not be read or written. So, a read/write operation start at the buffer’s position (inclusive) and may continue up to the buffer’s limit (exclusive).

Figure 9-2 shows the state of a buffer with a capacity of 8 just after its creation. All its elements have a value of 0. Its position is set to zero. Its limit is set to 8, which is equal to its capacity. In the figure, P and L denote the position and the limit of the buffer, respectively. Note that the figure shows the index at 8, which is out of range for the buffer, to show the value of the limit.

You can get/set the position of a buffer using its overloaded position() method. The position() method returns the current value of the position of a buffer. The position(int newPosition) method sets the position of the buffer to the specified newPosition value and returns the reference of the buffer.

You can get/set the limit of a buffer using its overloaded limit() method. The limit() method returns the current value of the limit of a buffer. The limit(int newLimit) method sets the limit of a buffer to the specified newLimit value and returns the reference of the buffer.

You can bookmark a position of a buffer by using the mark() method. When you call the mark() method, the buffer stores the current value of its position as its mark value. You can set the position of a buffer to its previously bookmarked value by using the reset() method. The buffer’s mark is not defined when it is created. You must call the reset() method on a buffer only when its mark is defined. Otherwise, the reset() method throws an InvalidMarkException.

The following invariant must hold during the lifetime of a buffer:

Since the capacity of a buffer never changes and mark has limited use through the mark() and reset() methods, I limit the discussion only to the position and limit properties of a buffer. There are some indirect consequences of changing the position and limit values. Since the mark cannot be greater than the position, the mark is discarded if the position is set less than the current mark value. If you set the limit less than the position, the position is automatically set equal to the limit value.

So far, you have read a great deal on buffers. It’s time to see a buffer in action. Listing 9-2 contains the code to create a new buffer and display its four properties.

There are two ways to read data from a buffer:

In an absolute position read, you specify the index in the buffer from which you want to read the data. The position of the buffer is unchanged after an absolute position read.

In a relative position read, you specify how many data elements you want to read. The current position of the buffer determines which data elements will be read. In a relative position read, the read starts at the current position of the buffer and the position is incremented by one after reading each data element.

The get() method is used to read data from a buffer. The get() method is overloaded. It has four versions. Just replace the data type byte with another data type for other primitive type buffers in the following methods:

Writing data to a buffer is the opposite of reading data from it. The put() method is used to write data to a buffer. The put() method has five versions: one for absolute position write and four for relative position write. The absolute version of the put() method does not affect the position of the buffer. The relative versions of the put() method write the data and advance the position of the buffer by one for each written element. Different buffer classes have different versions of the put() method; however, there are five versions that are common among all types of buffers. The following are the five versions of the put() method for ByteBuffer. These methods throw a ReadOnlyBufferException when the buffer is read-only. Just replace the data type byte with another data type for other primitive type buffers in the following methods.

Let’s have some pictorial views of the state of a buffer and its properties after each read and write. Figure 9-3 through Figure 9-6 depict how the position of a buffer with a capacity of 8 is advanced after each write in the buffer. After the eighth write in the buffer, the position and the limit become equal. If you attempt to write a ninth time, you would get a BufferOverflowException. Note that I have used a relative write using the put(byte b) method.

Let’s read the data that you have just written into the buffer whose state is shown in Figure 9-6. Note that the position of the buffer is 8 and its limit is also 8. If you call the get() method (a relative read) to read data from this buffer, you would get a BufferUnderflowException. You have just filled the buffer with data. However, when you attempt to read the data, you get an exception because the get() method returns data from the current position of the buffer, which is out of range in this case. The get() method will return data only if the position of the buffer is in the range of 0 and 7. Let’s not lose hope and try to read the data using an absolute position with the get(int index) method. If you call get(0), get(1) ... get(7), you will be surprised to know that you can read all the data you had written. Listing 9-3 demonstrates this.

Now you understand that there is a big difference in using relative and absolute methods for reading from and writing to a buffer. Both methods have a working range. The data must be read and written in the working range. The working range for relative and absolute methods is different.

The working range for a relative read/write are the indices between position and limit –1 of the buffer, where position is less than limit -1. That is, you can read/write data using the relative get() and put() methods if the position of the buffer is less than its limit.

The working range for the absolute read/write is the index between zero and limit -1. So, how do you read all the data from a buffer using a relative position read, after you have finished writing data into the buffer? One way to accomplish this is to set the limit of the buffer equal to its position and set its position to 0. The following snippet of code shows this technique:

The Buffer class has a method to accomplish just what you have coded in this snippet of code. You can set the limit of the buffer to its position and set the position to 0 by using its flip() method. Figure 9-7 shows the state of a buffer, which has a capacity of 8, after it has been created and after its two elements at index 0 and 1 have been written. Figure 9-8 shows the state of the buffer after its flip() method is called. The flip() method discards the mark of a buffer if it is defined.

In the previous snippet of code, you used a for loop to read the data from the buffer. The index of the for loop runs from zero to limit –1. However, there is an easier way to read/write data from/to a buffer using a relative read/write method. The hasRemaining() method of a buffer returns true if you can use relative get() or put() method on the buffer to read/write at least one element. You can also get the maximum number of elements you can read/write using relative get() or put() methods by using its remaining() method. Listing 9-4 demonstrates the use of these methods.

Apart from the flip() method, there are three more methods of a buffer that change its mark, position, and/or limit. They are clear(), reset(), and rewind().

The clear() method of a buffer sets the position to zero, limit to its capacity, and discards its mark. That is, it sets the buffer’s properties as if the buffer has just been created. Note that it does not change any data in the buffer. Figure 9-9 and Figure 9-10 show the mark, position, and limit of a buffer before and after calling the clear() method. Typically, you call the clear() method on a buffer before you start filling it with fresh data.

The reset() method sets the position of a buffer equal to its mark. If a mark is not defined, it throws an InvalidMarkException. It does not affect the limit and data of the buffer. Typically, it is called to revisit (for rereading or rewriting) the buffer’s elements starting from the previously marked position and up to the current position. The mark of the buffer remains unchanged by the reset() method. Figure 9-11 and Figure 9-12 show the states of a buffer before and after its reset() method is called.

The rewind() method sets the position of the buffer to zero and discards its mark. It does not affect the limit. Typically, you call this method between multiple read/write operations to use the same number of data elements in the buffer multiple times. Figure 9-13 and Figure 9-14 show the state of a buffer before and after calling its rewind() method.

A buffer can be read-only or read-write. You can only read the contents of a read-only buffer. Any attempt to change the contents of a read-only buffer results in a ReadOnlyBufferException. Note that the properties of a read-only buffer such as its position, limit, and mark can be changed during the read operations, but not its data.

You may want to get a read-only buffer from a read-write buffer, so you can pass it as an argument to a method to make sure the method does not modify buffer’s contents. You can get a read-only buffer by calling the asReadOnlyBuffer() method of the specific buffer class. You can check if a buffer is read-only by calling the isReadOnly() method as follows:

The read-only buffer returned by the asReadOnlyBuffer() method is a different view of the same buffer. That is, the new read-only buffer shares data with its original buffer. Any modifications to the contents of the original buffer are reflected in the read-only buffer. A read-only buffer has the same value of position, mark, limit, and capacity as its original buffer at the time of creation and it maintains them independently afterwards.

You can also get a view of a byte buffer for different primitive data types. For example, you can get a character view, a float view, etc. of a byte buffer. The ByteBuffer class contains methods such as asCharBuffer(), asLongBuffer(), asFloatBuffer(), etc. to obtain a view for other primitive data types.

A character is not always stored in one byte. The number of bytes used to store a character depends on the coded character set and the character-encoding scheme. A coded-character set is a mapping between a set of abstract characters and a set of integers. A character-encoding scheme is a mapping between a coded-character set and a set of octet sequence. Refer to Appendix A in the first volume of this series for more details on character set and character encoding.

The process of converting a character into a sequence of bytes based on an encoding scheme is called character encoding . The process of converting a sequence of bytes into a character based on an encoding scheme is called decoding .

In NIO, you can convert a Unicode character to a sequence of bytes and vice versa using an encoding scheme. The java.nio.charset package provides classes to encode/decode a CharBuffer to a ByteBuffer and vice versa. An object of the Charset class represents the encoding scheme. The CharsetEncoder class performs the encoding. The CharsetDecoder class performs the decoding. You can get an object of the Charset class using its forName() method by passing the name of the character set as its argument.

The String and InputStreamReader classes support character encoding and decoding. When you use str.getBytes("UTF-8"), you are encoding the Unicode-characters stored in the string object str to a sequence of bytes using the UTF-8 encoding-scheme. When you use the constructor of the String class String(byte[] bytes, Charset charset) to create a String object, you are decoding the sequence of bytes in the bytes array from the specified character set to the Unicode-character set. You are also decoding a sequence of bytes from an input stream into Unicode-characters when you create an object of the InputStreamReader class using a character set.

For simple encoding and decoding tasks, you can use the encode() and decode() methods of the Charset class. Let’s encode a sequence of characters in the string Hello stored in a character buffer and decode it using the UTF-8 encoding-scheme. The snippet of code to achieve this is as follows:

The encode() and decode() methods of the Charset class are easy to use. However, they cannot be used in all situations. They require you to know the inputs in advance. Sometimes you do not know the data to be encoded/decoded in advance.

CharsetEncoder and CharsetDecoder classes provide much more power during the encoding and decoding process. They accept a chunk of input to be encoded or decoded. The encode() and decode() methods of the Charset class return the encoded and decoded buffers to you. However, CharsetEncoder and CharsetDecoder will let you use your buffers for input and output data. The power comes with a little complexity! If you want more powerful encoding/decoding, you need to use the following five classes instead of just the Charset class:

You still need to use the Charset class to represent a character set. A CharsetEncoder object lets you encode characters into a sequence of bytes using its encode() method. A sequence of bytes is decoded using the decode() method of a CharsetDecoder object. The newEncoder() method of a Charset object returns an instance of the CharsetEncoder class, whereas its newDecoder() method returns an instance of the CharsetDecoder class.

Two buffers, an input buffer and an output buffer, are needed for encoding and decoding. A character buffer supplies the input characters to the encoding process and receives the decoded characters from the decoding process. The encoding process writes the encoded result into a byte buffer and the decoding process reads its input from a byte buffer. The following snippet of code illustrates the few steps in using an encoder and a decoder:

Consider a situation of encoding 16 characters stored in a character buffer using a 4-byte buffer. The encoding process cannot encode all characters in one call to the encode() method. There must be a way to read all encoded output repeatedly. You can apply the same argument for the decoding process. You can pass an input to the encoding/decoding process and receive an output from them in chunks. The encoder’s encode() method and decoder’s decode() method return an object of the CoderResult class , which contains the status of the encoding/decoding process. There are two important results that this object can indicate:

An underflow indicates that the process needs more input. You can test for this condition by using the isUnderflow() method of the CoderResult object. You can also test this condition by comparing the return value of the encode() or decode() method with CoderResult.UNDERFLOW object as follows:

An overflow indicates that the process has produced more output than the capacity of the output buffer. You need to empty the output buffer and call the encode()/decode() method again to get more output. You can test for this condition by using the isOverflow() method of the CoderResult object. You can also test for this condition by comparing the return value of the encode() or decode() method with CoderResult.OVERFLOW object as follows:

The last argument to the encode()/decode() method is a boolean value, which indicates the end of the input. You should pass true for the end of the input argument when you pass the last chunk of data for encoding or decoding.

After passing the last chunk of data, you need to call the flush() method to flush the internal buffer of the engine. It returns an object of CoderResult that can indicate underflow or overflow. If there is an overflow, you need to empty the output buffer and call the flush() method again. You need to keep calling the flush() method until its return value indicates an underflow. The flush() method call should be placed in a loop, so you get all of the encoded/decoded data.

The DataSourceSink class in Listing 9-5 serves as a data source and a data sink. I created this class only for illustration purposes; you would not need a class like this in a real-world application. It supplies a stanza from the poem Lucy by William Wordsworth in a character buffer. The getCharData() method fills the character buffer. It returns -1 when there are no more characters to supply. You use this method during the encoding process. The storeByteData() method is used to accumulate the encoded bytes during the encoding process. The getByteData() method is used during the decoding process to supply the encoded bytes in chunks that you accumulate during the encoding process.

Listing 9-6 demonstrates how to use a character set encoder/decoder. The encode() and decode() methods of the CharEncoderDecoder class have the encoding and decoding logic. This example displays the decoded characters on the standard output.

You can get the list of all available character sets supported by the JVM using the static availableCharsets() method of the Charset class, which returns a SortedMap<String,Charset> whose keys are character set names and values are Charset objects.

Listing 9-7 demonstrates how to list all character sets supported by the JVM. A partial output is shown. You may get a different output.

A channel is an open connection between a data source/data sink and a Java program to perform some I/O operations. The Channel interface is in the java.nio.channels package. It is used as a base to implement channels in Java. It declares only two methods: close() and isOpen(). When a channel is created, it is open and its isOpen() method returns true. Once you are finished using a channel, you should call its close() method to close it. At that point, isOpen() returns false. Figure 9-15 depicts the class diagram for the Channel interface.

Java program interacts with a channel for an I/O operation using byte buffers. That is, even if you have many different kinds of buffers, you will need to convert them to a byte buffer before you can pass them to a channel for reading/writing data.

A ReadableByte Channel is used to read data from a data source into a byte buffer using its read() method. A WritableByte Channel is used to write data from a byte buffer to a data sink using its write() method. A ByteChannel is capable of both reading and writing byte data.

A ScatteringByte Channel reads data from a data source into multiple byte buffers. It is useful to read data from a known file format or a similar data source, where data is supplied in some fixed-length headers followed by a variable length body. For example, suppose a file has a 256-byte fixed-length header and a variable length body. An object of the ScatteringByteChannel class is used to read data from this kind of file using two byte buffers. The first byte buffer will be of capacity 256. The second buffer will be of a size of your choice. When you pass these two buffers to this channel, the fixed-length header of 256 bytes will be read in the first buffer. The second buffer will have the file data and you may have to use the second buffer multiple times to read the rest of bytes from the file. The advantage of using this channel is separating the fixed-length header data from other data.

A GatheringByte Channel performs just the opposite of what a ScatteringByteChannel performs. It writes data from multiple byte buffers to a data sink. It is used to write data in a format that is grouped in some fixed-length headers, followed by a variable length body.

An InterruptibleChannel channel can be closed asynchronously. If a thread is blocked on an I/O operation on this channel, another thread can call its close() method to close it. The blocked thread will receive an AsynchronousCloseException. If a thread is blocked on an I/O operation on this channel, another thread can call the interrupt() method on the blocked thread. This channel is closed, and the blocked thread receives a ClosedByInterruptException exception.

Typically, you do not deal with these channel interfaces directly in your programs. You deal with concrete channel classes that implement one or more of these interfaces. Unlike I/O streams, you do not create a channel directly. You get it indirectly by calling a method. To obtain a channel for a data source and a data sink, you need to create an object of InputStream and OutputStream—using old ways of working with I/O using classes in the java.io package. The Channels class in the java.nio.channels package is a utility class that has many static methods to convert streams into channels and vice versa. The Channels class also provides methods to convert readers/writers to channels and vice versa. For example, if you have an input stream object named myInputStream, you can obtain a ReadableByteChannel as follows:

If you have a ReadableByteChannel named rbc, you can obtain the underlying InputStream object as follows:

The FileInputStream and FileOutputStream classes contain methods to work with channels. They have a method called get Channel() , which returns a FileChannel object. A FileChannel is used to read and write data to a file. A FileChannel obtained from a FileInputStream is opened in a read-only mode. A FileChannel obtained from a FileOutputStream object is opened in a write-only mode. If you obtain a FileChannel from a RandomAccessFile, it is opened in a read-only, write-only, or read-write mode, depending on the way you create that RandomAccessFile object. The following snippet of code obtains FileChannel objects for different kinds of file streams:

I covered the basic concepts of buffers and channels. A FileChannel maintains a position as a buffer does. The read() and write() methods for FileChannel come in two varieties: relative position read/write and absolute position read/write. The meanings of relative and absolute position read/write are the same as in the context of a buffer read/write. When you open a FileChannel, its position is set to 0, which is the beginning of the file. When you read from a FileChannel using a relative read() method, its position is incremented by the number of bytes read. An absolute position read from a FileChannel does not affect its position. You can get the current value of the position of a FileChannel using its position() method. You can set its position to a new position using its position(int newPosition) method. You need to follow a few easy steps to read data from a file and to write data to a file using NIO.

The steps to read data from a file using buffer and channel are as follows:

Listing 9-8 puts all of these steps together. It reads text from a file named luci1.txt. The file should be in your current working directory. If the file does not exist, the program prints a message with the full path where the file is expected to exist. If you do not have this file, create it and enter the following text in the file, before you run the program:

You need to pay close attention to the call to the clear() and flip() methods on a buffer. When you call the read() or write() method of a channel, it performs a relative position read/write on the buffer. Therefore, you must call the flip() method of the buffer to read data from it after the channel writes data into the buffer.

The steps to write data to a file using a buffer and a channel are as follows:

Listing 9-9 puts all these steps together to write the following text to a luci5.txt file:

The code creates a string from the text inserting a platform-dependent new line character between two lines. It converts the text into a byte array, creates a ByteBuffer by wrapping the byte array, and writes the buffer to the file channel. Note that you do not need to use the flip() method on the buffer because, before passing it to the channel for writing, your buffer object was just created with the text, and its position and limit were set appropriately by the wrap() method. The program prints the path of the file in which the text was written that may be different on your machine.

A file has two kinds of data associated with it. One is its contents and the other is metadata such as creation time, last-modified time, etc. When you write data to a file channel, the data may not be actually written to the storage device (for example, the hard disk) immediately. To write the data to the storage device immediately, after a call to the write() method on a file channel, you can call its force(boolean metaData) method. It guarantees that the file’s contents and metadata are written to its storage device. If you call force(false), only the file’s metadata is written to the storage device. If you call force(true), both the file’s content and its metadata are written to the storage device. In fact, this is guaranteed only if the storage device is local. Otherwise, the JVM tries its best to write the data to the storage device.

For memory-mapped file I/O, start by obtaining a FileChannel for the file, and use the map() method of the FileChannel to get a MappedByteBuffer. Read or write directly to the mapped byte buffer instead of using the read() or write() method of the FileChannel. When you read from the mapped byte buffer, you read from the file’s region you have mapped. When you write to the mapped byte buffer, you write to the mapped region of the file. If you want to write the written data to the mapped byte buffer immediately to the storage device, you need to use the force() method of the mapped byte buffer. There is no boolean argument to force() related to metadata.

Once you obtain the mapped byte buffer from a FileChannel, closing the channel has no effect on your buffer. You can keep reading/writing the mapped byte buffer, even after the FileChannel is closed.

NIO supports file locking to synchronize access to a file. You have the ability to lock a region of a file or the entire file. The file locking mechanism is handled by the operating system and, therefore, its exact effect is platform-dependent. On some operating systems, a file lock is advisory, whereas on some, it is mandatory. Since it is handled by the operating system, its effect is visible to other programs as well as to Java programs running in other JVMs.

There are two kinds of file locking: exclusive and shared . Only one program can hold an exclusive lock on a region of a file. Multiple programs can hold shared locks on the same region of a file. You cannot mix an exclusive lock and a shared lock on the same region of a file. If a program has a shared lock on a region, another program must wait to get an exclusive lock on that region and vice versa. Some operating systems do not support a shared file lock, and, in that case, the request for a shared file lock is converted to a request for an exclusive file lock.

An object of the FileLock class, which is in the java.nio.channels package, represents a file lock. You acquire a lock on a file by using the lock() or tryLock() method of the FileChannel class. The lock() method blocks if the lock on the requested region of the file is not available. The tryLock() method does not block; it returns immediately. It returns an object of the FileLock class if the lock was acquired; otherwise, it returns null.

Both lock() and tryLock() methods have two versions: one without an argument and another with three arguments. The version without an argument locks the entire file. The version with three arguments accepts the starting position of the region to lock, the number of bytes to lock, and a boolean flag to indicate if the lock is shared. The isShared() method of the FileLock object returns true if the lock is shared; otherwise, it returns false.

The following snippet of code shows different ways of obtaining locks on a file. The exception handling code is omitted for clarity.

The region of a file that you lock may not be contained in the range of the file size. Suppose you have a file with a size of 100 bytes. When you request a lock on this file, you can specify that you want to lock a region of this file starting at byte 11 and covering 5000 bytes. Note that this file contains only 100 bytes; you are locking 5000 bytes. In such a case, if the file size grows beyond 100 bytes, your lock covers the additional region of the file. Suppose you locked the entire file, which is 100 bytes in size. If this file grows to 150 bytes, your lock does not cover the last 50 bytes that was added after you acquired the lock. The lock() and tryLock() methods of the FileChannel object, where you do not specify any argument, lock a region from 0 to Long.MAX_VALUE of the file. The two method calls—fc.lock() and fc.lock(0, Long.MAX_VALUE, false)—have the same effect.

When you are done with the file lock, you need to release it by using the release() method. A file lock is released in three ways: by calling its release() method, by closing the file channel it is obtained from, and by shutting down the JVM. It is good practice to use a try-catch-finally block to acquire and release a file lock as follows:

You can use buffers and channels to copy a file much faster. Copying the contents of a file to another file is just one method call when you use a FileChannel. Get the FileChannel object for the source file and the destination file, and call the transferTo() method on the source FileChannel object or call the transferFrom() method on the sink FileChannel object. The following snippet of code shows how to copy the luci5.txt file to luci5_copy.txt:

Listing 9-10 contains the complete code. The program prints the path of the source and destination files when the file copy succeeds.

If you ever wanted to know the byte order (also called endian-ness) of your machine, you need to use the nativeOrder() method of the ByteOrder class, as shown in Listing 9-11. The byte order of a machine/buffer is discussed in detail in the next section. The program prints the byte order of the machine on which it is run. You may get a different output.

A short value is stored in two bytes. The value 300 can be represented in 16-bits as 0000000100101100, where the right-most bit is the least significant bit and the left-most bit is the most significant bit. You can split the 16-bit into two bytes as 00000001 and 00101100. At the byte level, you can think of 00000001 as the most significant byte and 00101100 as the least significant byte. If you consider two bytes separately for a short value, you may store them as either 00000001 followed by 00101100 or 00101100 followed by 00000001. As long as you know the order of the bytes in which they are stored, you can compute the correct value 300 using either form of the 16 bits: 0000000100101100 or 0010110000000001.

A byte order is called big endian if the bytes of a multi-byte value are stored from the most significant byte to the least significant byte. If the bytes of a multi-byte value are stored from the least significant byte to the most significant byte, it is known as little endian. To remember the two definitions easily, you can replace the word “big” with “most significant,” “little” with “least significant,” and “endian” with “first”. That is, remember “big endian” as “most significant first” and “little endian” as “least significant first.”

If you store a short value of 300 as 0000000100101100, you are using the big endian byte order. In the little endian byte order, you would store 300 as 0010110000000001, which seems backwards for representing a 16-bit value.

When you deal with byte data in a byte buffer, you may be considering each byte as an independent byte. A byte in a byte buffer may be part of a bigger value. When a byte value in a byte buffer is independent, the byte order is not a consideration. When a byte in a byte buffer is part of a bigger value (e.g., two bytes of a short value 300), the byte order becomes very important in reading. If you read two bytes from a byte buffer to compute a short value, you must know how those two bytes are stored. Suppose you read two bytes as 0000000100101100. If it is in a big endian byte order, it represents a value of 300. If it is in a little endian byte order, it represents a value of 11265.

Java uses a big-endian byte order to store data. By default, a byte buffer uses a big endian byte order. An instance of the java.nio.ByteOrder class represents a byte order. You will not need to instantiate this class because you always use the value that represents a byte order; you don’t create a new byte order. In fact, this class has no public constructor. You can use two constants, BIG_ENDIAN and LITTLE_ENDIAN, which are defined in the ByteOrder class to represent these byte orders.

Listing 9-12 demonstrates how to get and set byte order for a byte buffer. You use the order() method of the ByteBuffer class to get or set the byte order. The program stores a short value of 300 in two bytes of a byte buffer. It displays the values stored in the first and the second bytes using both big endian and little endian byte orders. The output shows the values of bytes in decimal as 1 and 44, whose binary equivalents are 00000001 and 00101100, respectively.

A buffer maintains several properties that are affected by reading its data or writing data to it. The position property of a buffer is the index in the buffer that is the starting position to be read or written in the next read/write operation. The limit property of a buffer is the index in the buffer that is the starting index indicating the invalid read/write position. The buffer’s position may change as you read from the buffer or write to the buffer.

Buffer-related classes contain methods to manipulate those properties directly as well. A buffer supports absolute read/write and relative read/write. In absolute read/write, the buffer’s position is unaffected. In a relative read/write, the position property of the buffer is automatically advanced.

Byte buffers support different views. You can use a view of a buffer to access the data buffer’s data as different primitive type values or to see only part of the buffer’s data.

A character is not always stored in one byte. The number of bytes used to store a character depends on the coded character set and the character-encoding scheme. A coded-character set is a mapping between a set of abstract characters and a set of integers. A character-encoding scheme is a mapping between a coded-character set and a set of octet sequence. An instance of the java.nio.charset.Charset class represents a character set and a character-encoding scheme. Examples of some character set names are US-ASCII, ISO-8859-1, UTF-8, UTF-16BE, UTF-16LE, and UTF-16. The process of converting a character into a sequence of bytes based on an encoding scheme is called character encoding . The process of converting a sequence of bytes into a character based on an encoding scheme is called decoding . In NIO, you can convert a Unicode character to a sequence of bytes and vice versa using an encoding scheme. The java.nio.charset package provides classes to encode/decode a CharBuffer to a ByteBuffer and vice versa. An object of the Charset class represents the encoding scheme. The CharsetEncoder class performs the encoding. The CharsetDecoder class performs the decoding. You can get an object of the Charset class using its forName() method by passing the name of the character set as its argument.

A FileChannel, along with buffers, are used to read/write files. You can obtain a FileChannel from an InputStream, an OutputStream, or using the factory method of the FileChannel class. You can also lock a file in exclusive or shared mode using the lock() method of the FileChannel class.

The byte order is the order in which bytes of a multi-byte value are stored. A byte order is called big endian if the bytes of a multi-byte value are stored from the most significant byte to the least significant byte. If the bytes of a multi-byte value are stored from the least significant byte to the most significant byte, it is known as little endian. You need to deal with the byte order of a byte buffer if the buffer represents multi-byte data. The java.nio.ByteOrder class represents the byte order. It contains two constants, BIG_ENDIAN and LITTLE_ENDIAN, to represent big-endian and little-endian byte orders, respectively.