called small changes: the ability to specify a binary literal and to use underscores
in a numeric literal. At first glance, these
seem like nearly inconsequential additions, hardly worth mentioning, but the
opposite is true. Not only do they add
convenience, they help prevent errors.
For example, consider a situation in
which some specific bit pattern is required, perhaps for use as a bit mask.
Obviously, one normally thinks about
a bit pattern in terms of binary. Thus, it
would be helpful to specify a bit pattern
using a binary literal. The trouble was
that, in the past, there were no binary
literals. This meant that a different
approach was required, of which there
were several.
For instance, if the bit pattern 0110
1101 was needed, you might have used
Byte.parseByte("01101101", 2), but this
involves a method call. If what you
wanted was an actual literal, it was not
uncommon to press a hexadecimal
literal into service. For example, who
hasn’t seen something like this?
is very difficult to find. Alternatively, the
value might be right, but the bit pattern
in the comment might be wrong, thus
misleading anyone reading the code.
With JDK 7, you can eliminate the possibility of such errors because you can
now use a binary literal to specify a bit
pattern. For example:
FileInputStream fIn = null;
try {
fIn = new FileInputStream("somefilename");
// Access the file ...
} catch(IOException e) {
// ...
} finally {
// Close file.
try {
if(fIn != null) fIn.close();
} catch(IOException e) {
// ...
}
}
byte myBits = 0b01101101;
JAVA IN ACTION
Here, the value is encoded directly by
a binary literal. This means that there
is no chance for conversion errors, and
the bit pattern is self-documented.
Thus, you have a direct, visual representation of precisely the bit pattern
you wanted—a much more reliable,
transparent approach.
You can further enhance the readability of a binary value by inserting underscores, like this:
See all listings as text
byte myBits = 0b0110_1101;
ABOUT US
byte myBits = 0x6D; // 0110 1101
Although useful here, underscores in
large binary values are even more valuable. For example, which of the following values is easier to read?
Here, the value is encoded as the
hexadecimal literal 0x6D, and the comment depicts the bit pattern. This approach is not, however, without problems, one being that it is possible to
make a mistake when converting from
binary into hexadecimal, resulting in the
wrong bit pattern. (Maybe your finger
presses the wrong key on the calculator,
and you don’t catch it.) Unfortunately,
such a mistake could result in a bug that
0b0110110111000111
0b0110_1101_1100_0111
Even though binary literals and underscores in numeric values are two of
the smallest of the “small” language
enhancements, they both offer significant improvements that let you write
code with greater clarity and less chance
for error.
Try-with-Resources Statement
If binary literals and underscores in
numeric values are on one end of the
change spectrum, at the other end is
try-with-resources. I consider try
-with-resources to be the single most important new language feature added by JDK
7. It not only addresses a long-standing
issue, it also prevents an entire class of
errors. One of the thorniest things about
handling resources, such as file streams,
is ensuring that they are closed when
they are no longer needed. Forgetting
to close a resource can lead to memory
leaks and other problems. The try
-with-resources statement automates the
closing process, and it does so in an
elegant way.
To understand the importance of
try-with-resources, let’s begin by review-
ing an example of the type of situation
it is designed to improve. As you know,
working with a file has traditionally in-
volved three separate actions. You need
to open the file, use the file, and then
close the file. Prior to JDK 7, you might
have used some variation of the code
shown in Listing 1.
blog
