References

When discussing types, we mentioned the fact that Java makes a distinction between two categories of types in the language: primitive types and reference types. At the time, we handwaived the difference and focused primarily on the primitive types provided by Java (byte, short, int, long, float, double, char, and boolean). In this chapter, we will take a look at what makes reference types so different as to justify its own category.

Before we investigate reference types we should first recall what makes a primitive type primitive. The idea is simple, primitive types are "predefined by the Java programming language and named by its reserved keyword" (§ 4.2). Structurally, from the point of view of Java, primitive types are distinct from reference types insofar as the primitive types represent the atomic stuff of the language. Furthermore, the values of primitive types are predefined:

The numeric types are the integral types and the floating-point types.

The integral types are byte, short, int, and long, whose values are 8-bit, 16-bit, 32-bit and 64-bit signed two's-complement integers, respectively, and char, whose values are 16-bit unsigned integers representing UTF-16 code units (§3.1).

The floating-point types are float, whose values exactly correspond to the 32-bit IEEE 754 binary32 floating-point numbers, and double, whose values exactly correspond to the 64-bit IEEE 754 binary64 floating-point numbers.

The boolean type has exactly two values: true and false.

A primitive type is one of eight possible types given by the language, and each can only contain values within their respective ranges. We also find one other clause within the specification about primitive types:

Primitive values do not share state with other primitive values

This is a subtle point, but one that has massive implications. A code example will illustrate the idea:

1: public class PrimitiveState{
2:     public static void main(String[] args){
3:         int x = 10;
4:         int y = x;
5:         x += 1;
6:         System.out.printf("x: %d%n", x);
7:         System.out.printf("y: %d%n", y);
8:     }
9: }  

What would you expect Listing 1 to print out? If we compile and run it we get the following:

josephraskind@stargazer:/tmp/references$ javac PrimitiveState.java; java PrimitiveState
x: 11
y: 10

We see that x contains the incremented value and y does not. This is because the state of a primitive value is not passed on to another variable during assignment. The int that x is tied to is distinct from the int that y is tied to because only its value was passed during the assignment statement. We have two distinct variables with two distinct values. We'll see that reference types do not share this behaviour!

By definition, a reference type is any type that is not a primitive type (i.e. anything that is not a byte, short, int, long, float, double, char, or boolean). We know now that types which we define through the use of classes are called objects when instantiated. Therefore, all objects in Java are reference types—this is also true of all arrays. What makes reference types special is their values "are pointers to these objects" (§ 4.3.1). What does that mean? A code example might be more instructive:

 1: class MyInt{
 2:     int i;
 3:     MyInt(int i){
 4:         this.i = i;
 5:     }
 6: }
 7: 
 8: public class ReferenceState{      
 9:     public static void main(String[] args){
10:         MyInt x = new MyInt(10);
11:         MyInt y = x;
12:         x.i += 1;
13:         System.out.printf("x: %d%n", x.i);
14:         System.out.printf("y: %d%n", y.i);
15:     }
16: }

You can see all I've done is switch out the primitive int for an object called MyInt which acts as a wrapper around a basic int. It wouldn't be too absurd to assume we would get the same printout of "11\n10", but when we compile and run the code we get:

josephraskind@stargazer:/tmp/references$ javac ReferenceState.java; java ReferenceState
x: 11
y: 11

How could that be?! This behavior hinges on the fundamental difference between primitive and reference types. Primitive types cannot share state whereas reference types can. This is because reference types store pointers to the underlying objects in memory. The following diagram shows this phenomenon visually:

Primitive types (int):

  int x = 10;          int y = x;           x += 1;

  +-------+            +-------+            +-------+
  |  x    |            |  x    |            |  x    |
  |  10   |            |  10   |            |  11   |
  +-------+            +-------+            +-------+
                       +-------+            +-------+
                       |  y    |            |  y    |
                       |  10   |            |  10   |  ← unchanged
                       +-------+            +-------+

  Each variable holds its own copy of the value.
  Assignment copies the value, not a reference to it.


Reference types (MyInt):

  MyInt x = new MyInt(10);    MyInt y = x;         x.i += 1;

 +-------+                   +-------+            +-------+
 |  x    |                   |  x    |            |  x    |
 |  *----+--+                |  *----+---+        |  *----+--+
 +-------+  |                +-------+   |        +-------+  |
            |                            |                   | 
            v                +-------+   |                   v 
       +--------+            |  y    |   |               +--------+
       | MyInt  |            |  *----+---+               | MyInt  |
       |  i: 10 |            +-------+                   |  i: 11 |
       +--------+                |                       +--------+
                                 |                             ^
                                 +-----------------------------+

  Both x and y hold a pointer to the SAME object in memory.
  Modifying x.i modifies the shared object, so y.i changes too.

In Java, when we send in objects as parameters to methods we are always sending in references. For example, if we take the BankAccount class from the previous chapter:

 1: public class PassingReferences{
 2: 
 3:     static void applyBonus(BankAccount acc, double amount){
 4:         acc.deposit(amount);
 5:     }
 6: 
 7:     public static void main(String[] args){
 8:         BankAccount alice = new BankAccount("Alice", 1000.00);
 9: 
10:         System.out.println("Before bonus:");
11:         alice.printBalance();
12: 
13:         applyBonus(alice, 500.00);
14: 
15:         System.out.println("After bonus:");
16:         alice.printBalance();
17:     }
18: }

Here we can see that this new static method applyBonus takes a BankAccount object called acc. We then access the public method deposit and send in the amount. In the main method we print the bonus before and after a call to applyBonus. When we compile and run the above code we get the following output:

josephraskind@stargazer:/tmp/references$ javac PassingReferences.java; java PassingReferences
Before bonus:
Alice's balance: $1000.00
After bonus:
Alice's balance: $1500.00

Even though acc is a different variable than alice they both point to the same object.

The Java Language Specification lays out two possible reference values: "pointers to… objects, and a special null reference, which refers to no object". By default, all uninitialized reference types will refer to the null value. Again, the null value indicates the lack of a particular object associated with a reference type variable. For example, I could create a variable of type BankAccount without initializing it:

1: public class NullObject{
2:     static BankAccount emptyAcc;
3:     public static void main(String[] args){
4:           System.out.printf("emptyAcc: %s%n", emptyAcc);
5:     }
6: }

When we compile and run the above code we find the following printed:

josephraskind@stargazer:/tmp/references$ javac NullObject.java; java NullObject
emptyAcc: null

Because the null value refers to the lack of an instance tied to a given variable that means we cannot reference instance fields/method:

1: public class NullObject{
2:     static BankAccount emptyAcc;
3:     public static void main(String[] args){
4:           null.printBalance()
5:     }
6: }

Compiling and running the above we get:

josephraskind@stargazer:/tmp/references$ javac NullObject.java; java NullObject
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "BankAccount.printBalance()" because "NullObject.emptyAcc" is null
        at NullObject.main(NullObject.java:4)

We get a runtime exception! Again, null refers to a non-existent object, therefore we cannot dereference it.

A simple mistake many beginner Java programmers make is to do basic equivalency checks between reference types using the == operator. == only checks equivalency between stored values. This is not a problem when comparing two primitive types as they store values themselves. This is a problem when comparing two reference types as they store pointers to objects. Take a simple equivalancy comparison between two Strings:

1: public class ComparingStrings{
2:     public static void main(String[] args){
3:         String s1 = new String("Dog");
4:         String s2 = new String("Dog");
5:         boolean result = s1 == s2;
6:         System.out.printf("s1 == s2 returns %b%n", s1, s2, result);
7:     }
8: }

When we compile and run the above we get:

josephraskind@stargazer:/tmp/references$ javac ComparingStrings.java; java ComparingStrings
s1 == s2 returns false

What?! Again, this is because what's really going on is that Java is comparing the pointers stored in s1 and s2 and not the internal values themselves. Many built-in standard library Java objects have an equals method for direct equivalency checking:

1: public class ComparingStrings{
2:     public static void main(String[] args){
3:         String s1 = new String("Dog");
4:         String s2 = new String("Dog");
5:         boolean result = s1.equals(s2);
6:         System.out.printf("s1.equals(s2) returns %b%n", s1, s2, result);
7:     }
8: }

When we compile and run the above:

josephraskind@stargazer:/tmp/references$ javac ComparingStrings.java; java ComparingStrings
s1 == s2 returns false

That's better!

Whenever you write your own classes in Java, make sure that you write your own methods for direct comparisons!

1. Compile and run Listing 1. Then change int to double and repeat the experiment with decimal values. Does the behavior change? What does this confirm about all primitive types?
2. Compile and run Listing 3. Then add a third variable MyInt z = y and increment z.i by 5. Print x.i, y.i, and z.i. Before running, predict each value. Explain the result in terms of references.
3. The chapter draws a distinction between copying a value and copying a reference. In your own words, explain what happens in memory when you write int y = x versus MyInt y = x. Use the ascii diagrams from the chapter as a guide.
4. Compile and run Listing 5. Then modify applyBonus to also print the balance of acc inside the method before returning. Does the value printed inside applyBonus match the value printed in main after the call? What does this confirm about references being passed to methods?
5. The chapter states that even though acc and alice are different variables, they point to the same object. Write a program that demonstrates this by passing alice to a method that calls withdraw rather than deposit. Verify that the withdrawal is reflected in main after the method returns.
6. Replace the mutable BankAccount with the immutable version from Listing 7 and rerun Listing 5. The balance no longer updates in main. Modify applyBonus so that it returns the new BankAccount object produced by deposit and update main to capture and print the returned object. What does this pattern require the programmer to do differently compared to the mutable version?
7. The chapter states that Java's String class is immutable. Write a program that demonstrates this by attempting to change a character in a String using a method call. What happens? Now create a new String using concatenation and assign it back to the original variable. Does the original String object change, or is a new one created?
8. Compile and run Listing 9. Then attempt to call emptyAcc.deposit(100) instead of printing it. Record the exception. In your own words explain what a NullPointerException is and why it occurs. How could you guard against it before calling a method on a reference type variable?
9. Compile and run Listing 13. Then change new String("Dog") to just "Dog" for both s1 and s2 and rerun. Does == now return true? Research why this happens (hint: look up "string interning" in Java) and write a short explanation.
10. Compile and run Listing 15. Notice the printf format string uses %b but passes three arguments (s1, s2, result). What does the output look like? Fix the format string so it correctly prints the result and recompile.

11. Add an equals method to the BankAccount class that returns true if two BankAccount objects have the same owner and balance:

    boolean equals(BankAccount other){
        // your implementation here
    }
    

    Test it with two accounts that have identical fields and two that differ. Then test what happens when you use == instead — explain why the results differ.

12. The chapter explains that the immutable BankAccount returns a new object from deposit and withdraw rather than modifying the existing one. Write a short program that calls deposit on an immutable BankAccount but does not assign the return value. Print the balance after. What do you observe? What does this tell you about the risk of ignoring return values from immutable objects?
13. Write a method transfer that takes two BankAccount objects and a double amount and transfers that amount from the first account to the second. Use the mutable BankAccount defined in the previous chapter. Verify that both balances update correctly after the call.
14. The chapter states that uninitialized reference type fields default to null. Write a class with three fields: an int, a String, and a BankAccount. Instantiate the class without setting any fields and print all three. What are their default values? Why does int have a different default than the reference types?

15. The following code contains a subtle bug related to references:

    BankAccount a = new BankAccount("Alice", 500.00);
    BankAccount b = a;
    b = new BankAccount("Alice", 500.00);
    System.out.println(a == b);
    System.out.println(a.equals(b));
    

    Before running, predict the output of both print statements. Then run it and verify. Explain what happens to the reference stored in b after the second line and why a is unaffected by the reassignment of b.