In all methods of flow control, some form of conditional expression if evaluated, and used to direct the flow to different parts of a program. Desired behavior depends entirely on the correctness of the comparisons made. In this section we examine the right way to make certain comparisons in Java, so you know that your program will always compare correctly.
Subsection6.6.1equals() vs. ==
Recall that in Section 2.6 we learned that a String object is immutable. All String methods that seemingly modify internal character data, actually return a new String object. This behavior is an opportunity for the Java runtime to optimize memory usage. The String class makes use of the immutable feature of String objects by storing only a single copy of any String literal. For example, whenever I create a String using literal notation, say String feeling1 = "Joy";, the String class will create the String "Joy" and store it in memory reseved for a special pool of Strings. The next time I create a String variable that refers to "Joy", say String feeling2 = "Joy";, rather than creating a new String, the String class finds the "Joy" String in the pool and returns a reference to the one that exists already. This is a process called String interning. By avoiding the creation and storage of multiple String objects, we conserve memory. String interning is possible only because String objects are immutable.
We can demonstrate that feeling1 and feeling2 refer to the exact same String object by comparing the variables using the == operator. Remember, the == operator uses object identity for the equivalence test.
If we create a third String object with the same character data, only this time using the String constructor instead of a literal, String feeling3 = new String("Joy"); and then compare this new String variable to either the String variables feeling1 or feeling2 using the == operator, we will find that they are not the exact same String object, even though the character data in the objects refered to by feeling3 and feeling2 are the same. These two objects are not identical because String literals are interned in the String pool, but Strings objects created with the String constructor are stored elsewhere in memory, and so they are not the identical object. See the following JShell session for a demonstration.
jshell> String feeling1 = "Joy"; // First String literal
feeling1 ==> "Joy"
jshell> String feeling2 = "Joy"; // Second String literal
feeling2 ==> "Joy"
jshell> feeling1 == feeling2; // Are they the same object?
$3 ==> true
jshell> String feeling3 = new String("Joy");
feeling3 ==> "Joy" // Third String using a constructor
jshell> feeling3 == feeling2; // Are they the same object?
$5 ==> false
jshell> feeling3.equals(feeling2); // Are the character the same?
$6 ==> true
Best Practice: Use equals(…) to Compare Strings.
If you are not absolutely certain how two Strings were created, always use the equals(…) String method to compare Strings.
Subsection6.6.2Comparing Floating-point Numbers
Have a look at the following program and the output below it.
That is a surprising result, wouldn’t you agree? We all know that 0.1 + 0.2 == 0.3. Why did Java tell us that they are not equal? Understanding the answer to this question requires a deeper understanding of how floating point numbers are represented in memory, especially when it comes to precision.
Without getting into to much detail, you know that data is stored in memory in binary, in other words base-2 numbers (1s and 0s). But humans work (mostly) in decimal, base-10 numbers. It is not possible to store certain base-10 numbers exactly using base-2 notation, especially when we have limited memory. For this reason, floating point number operations produce base-2 results that are as close as possible to the real base-10 numbers, given the precision possible in the available storage memory.
If we maintain the precision available for doubles, but extend the number of decimal places further, we can observe the actual base-10 numbers stored in memory for numbers that are not representable exactly. Specifically,
The base-2 numbers written above in base-10 do achieve the necessary base-10 precision for a double type. But, also note that the representations for 0.1 and 0.2 both have a tiny positive error in the decimal places after the required precision.
If we add the first two numbers exactly, the result is,
Because this number is not the same as the base-2 number chosen by the floating-point system to represent the literal 0.3, the result of 0.1 + 0.2 == 0.3 is false. This is the best we can do with limited memory and therefore limited precision. In general, these tiny errors seldom cause a problem. Nevertheless, it is best to compare floating-point numbers using a close enough approach. That is, compute the absolute value of the different between two floating-point numbers. If that difference is less than some small number considered close enough, then the two floating-point numbers are essentially equal, at least to the available precision. See the updated example below. Note that the outcome is now what we expect.
Best Practice: Check that floating-point numbers are close enough.
Do not use == to compare floating-point numbers. Test for close enough by computing the absolute value of the difference and check that it is less than the desired precision.
Subsection6.6.3Short-circuit Evaluation
We know that for a logical conjunction to be true, both the left and right subexpressions must evaluate to true. Proceeding left-to-right, if we find that the left subexpression of a conjunction evaluates to false there is no need to evaluate the right subexpression because we know already that the entire conjunction is false. Java skips evaluation of the right subexpression and returns false as soon as it finds that the left subexpression evaluates to false. This is called short-circuit evaluation.
Listing 6.6.3 demonstrates short-circuit evaluation with a helper method named eval(…). This method takes two parameters: the first is a String label to be printed and the second is a boolean value to be returned. The purpose of this method is to see when the method is invoked by looking for the String label to be printed before the overall result is output. The program given in Listing 6.6.3 evaluates a conjunction where the left subexpression with label "A" is false but the right subexpression with label "B" is true. If both subexpressions in the conjunction are evaluated, then we’ll see both the "A" and "B" labels printed before the conjunction evaluates to false. If short-circuit evaluation is in play, only the "A" label will print.
// ShortCircuit.java
public class ShortCircuit {
public static void main(String[] args) {
// Left subexpression is false, so the right is never evaluated
if ( eval("A", false) && eval("B", true) ) {
System.out.println("Conjunction is true");
} else {
System.out.println("Conjunction is false");
}
}
// Print label and return boolean parameter value
public static boolean eval(String label, boolean value) {
System.out.println(label);
return value;
}
}
Listing6.6.3.ShortCircuit.java
In the following we compile and run our test program. The only label printed by the test program is "A". Only the first subexpression of the conjunction was evaluated so Java must be practicing short-circuit evaluation.
javac ShortCircuit.java
java ShortCircuit
A
Conjunction is false
We can use this knowledge to make our programs more efficient by testing the more limiting or less costly condition first, on the left side of a conjunction, and putting the less limiting or more costly condition as the right-side subexpression.
Best Practice: Check the most limiting conditions first.
When writing conjunctions, order more limiting or less costly subexpression on the left and the less limiting or more costly subexpression on the right. This will take advantage of short-circuit evaluation property of Java.
