Java IO.pdf - Nguyen Dang Binh

Java I/O
Although other schemes are possible, almost all modern computers have standardized on
binary arithmetic performed on integers composed of an integral number of bytes.
Furthermore, they've standardized on two's complement arithmetic for signed numbers. In
two's complement arithmetic, the most significant bit is 1 for a negative number and for a
positive number; the absolute value of a negative number is calculated by taking the
complement of the number and adding 1. In Java terms, this means (-n == ~n + 1) is true
where n is a negative int.
Regrettably, this is about all that's been standardized. One big difference between computer
architectures is the size of an int. Probably the majority of modern computers use four-byte
integers that can hold a number between -2,147,483,648 and 2,147,483,647. However, some
systems are moving to 64-bit architectures where the native integer ranges from -
9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 and takes eight bytes. And many
older systems use 16-bit integers that only range from -32,768 to 32,767. Exactly how many
bytes a C compiler uses for each int is platform-dependent, which is one of many reasons C
code isn't as portable as one might wish. The sizes of C's short and long are even less
predictable and may or may not be the same as the size of a C int. Java always uses a twobyte
short, a four-byte int, and an eight-byte long, and this is one of the reasons Java code
is more portable than C code. However, you must be aware of varying integer widths when
your Java code needs to communicate binary numbers with programs written in other
languages.
C compilers also allow various unsigned types. For example, an unsigned byte is a binary
number between and 255; an unsigned two-byte integer is a number between and 65,535; an
unsigned four-byte integer is a number between and 4,294,967,295. Java doesn't have any
unsigned numeric data types (unless you count char), but the DataInputStream class does
provide two methods to read unsigned bytes and unsigned shorts.
Perhaps worst of all, modern computers are split almost down the middle between those that
use a big-endian and a little-endian ordering of the bytes in an integer. In a little-endian
architecture, used on Intel (x86, Pentium)-based computers, the most significant byte is at the
highest address in memory. On the other hand, on a big-endian system, the most significant
byte is at the lowest address in memory.
For example, consider the number 1,108,836,360. In hexadecimal this is written as
0x42178008. On a big-endian system the bytes are ordered much as they are in a hex literal;
that is, 42, 17, 80, 08. On the other hand, on a little endian system this is reversed; that is, 08,
80, 17, 42. If 1,108,836,360 is written into a file on a little-endian system, then read on a bigendian
system without any special treatment, it comes out as 0x08801742; that is,
142,612,29—not the same thing at all.
Java uses big-endian integers exclusively. Data input streams read and data output streams
write big-endian integers. Most Internet protocols that rely on binary numbers such as the
time protocol implicitly assume "network byte order," which is a fancy way of saying "bigendian."
And finally, almost all computers manufactured today, except those based on the
Intel architecture, use big-endian byte orders, so the Intel is really the odd one out. However,
the Intel is the 1000-pound gorilla of computer architectures, so it's impossible to ignore it or
the data formats it supports. Later in this chapter, I'll develop a class for reading little-endian
data.
99