Reference vs. Value Equality

[comp1110-1T]
  • Liam O'Connor, Fabian Muehlboeck

The difference between value types and reference types explains the differences between == and other methods to decide equality.

For value types, == happens to capture regular equality - for example, there are no two int values that represent the number 32 but are somehow different.

On the other hand, for reference types, == describes reference equality, identifying whether two references point to the same object in memory. Since there may be two different objects representing the same value, == is too strict in many cases. We have seen this for String equality and Array equality. It is the same way in general for objects of arbitrary classes, except that for those, by default, no other notion of equality comparison exists. We'll see later how to define our own equality comparison.

Finally, Enums are a special case: they are a reference type, but with a guarantee that each case of a Enum refers to the same object in memory. As such, comparing the references to Enum values using == is fine - as for ints, there are no two distinct values representing the same case.

Context

    Understanding reference types

    [comp1110-1U]
    • Liam O'Connor, Fabian Muehlboeck

    Example. A puzzling question

    [comp1110-1P]
    • Liam O'Connor, Fabian Muehlboeck

    Without running this program, try to deduce what it will output:

    void fun1(int[] arr) { arr[0] = 100; } void fun2(int[] arr) { arr = new int[]{5,4,3,2,1}; } void fun3(int i) { i = 200; } void main() { int[] arr = new int[]{1,2,3,4,5,6}; int i = arr[0]; fun1(arr); IO.println(arr[0]); IO.println(i); fun2(arr); IO.println(arr[0]); IO.println(i); fun3(i); IO.println(arr[0]); IO.println(i); }

    You will only get the answer correct if you understand what happens in Java when values are passed to functions.

    Definition. Passing by value (or copy)

    [comp1110-1R]
    • Liam O'Connor, Fabian Muehlboeck

    A function's variables, including its parameters, are local to that invocation of the function. When we invoke a function, some memory is set aside for a frame: storage space for the local variables in the function. The values of the arguments given in the function invocation are copied into the function's frame. This is called pass by value. When the function returns, the frame is no longer needed and destroyed.

    This is why the function fun3 has no effect on its arguments in example Example [comp1110-1P].

    Definition. Value types and reference types

    [comp1110-1Q]
    • Liam O'Connor

    Variables of type int and char (for example) are called value types. This means that a variable declared of type, say int:

    int x;

    Will contain a value, a single integer. When left uninitialised as above, they are initialised to a default value of 0.

    By contrast, array types like int[] and char[] are what's called reference types. This means that a variable declared of an array type will not contain the array data itself, but instead will contain the location in memory where the data may be found. This location is called a reference or pointer.

    Any type name that begins with a capital letter (e.g. String) is also a reference type. This is why Strings should not be compared with == — it would compare locations, not contents.

    Definition [comp1110-1Q] combined with Definition [comp1110-1R] tells us that when we call a function like fun1 or fun2 in Example [comp1110-1P], the array data itself is not copied into the function's frame, but instead just the reference is. When fun1 or fun2 are called, the variable arr in their frame has the same value as the variable arr in the frame of main — they both point to the same array. This means that when we call fun1, the contents of the array in main are observably changed, as the array indexing arr[0] follows the same pointer that is in main.

    When we call fun2, however, nothing changes in the function main, because we don't follow the pointers, but instead just change the value of the local variable arr to point to a new array, then immediately discard it.

    The Waterloo Java Visualizer

    [comp1110-1S]
    • Liam O'Connor

    The Waterloo Java Visualizer is a great way to visualise what's going on in these examples. Here's a link to Example [comp1110-1P] being visualised in it. Click "forward" to step through the program's execution.

    Note that it doesn't support Java 25, so I had to include some cruft that Java 25 has since made obsolete like (a method-free) class, public static etc. We will learn about these things later in the course but they are not relevant for now.

    Reference vs. Value Equality

    [comp1110-1T]
    • Liam O'Connor, Fabian Muehlboeck

    The difference between value types and reference types explains the differences between == and other methods to decide equality.

    For value types, == happens to capture regular equality - for example, there are no two int values that represent the number 32 but are somehow different.

    On the other hand, for reference types, == describes reference equality, identifying whether two references point to the same object in memory. Since there may be two different objects representing the same value, == is too strict in many cases. We have seen this for String equality and Array equality. It is the same way in general for objects of arbitrary classes, except that for those, by default, no other notion of equality comparison exists. We'll see later how to define our own equality comparison.

    Finally, Enums are a special case: they are a reference type, but with a guarantee that each case of a Enum refers to the same object in memory. As such, comparing the references to Enum values using == is fine - as for ints, there are no two distinct values representing the same case.

    Backlinks

      Definition. A spec and a test suite for sorting

      [comp1110-1W]
      • March 10, 2026
      • Liam O'Connor

      Any in-place sorting algorithm, no matter how it is implemented, should satisfy the following spec:

      /** Sort an array in-place. There are two postconditions: - After executing, the array must be sorted. - After executing, the array must be some permutation of the values that existed before. (many programmers will get the former but forget the latter) @param arr the array to sort */ void sort(int[] arr)

      Assuming we had such a function, we might test it (using proper array comparison) as follows:

      void sortAndCheck (int[] toSort, int[] toCheck) { sort(toSort); assert Arrays.equal(toSort, toCheck); } void main (String[] args) { // already sorted sortAndCheck(new int[]{1,2,3,4,5,6,7,8,9}, new int[]{1,2,3,4,5,6,7,8,9}); // inversely sorted sortAndCheck(new int[]{9,8,7,6,5,4,3,2,1}, new int[]{1,2,3,4,5,6,7,8,9}); // random order sortAndCheck(new int[]{6,-5,212,42,19,0,0,5,9718}, new int[]{-5,0,0,5,6,19,42,212,9718}); // negative and inverse sortAndCheck(new int[]{-1,-2,-3,-4,-5}, new int[]{-5,-4,-3,-2,-1}); // empty sortAndCheck(new int[]{}, new int[]{}); // singleton sortAndCheck(new int[]{0}, new int[]{0}); // two sortAndCheck(new int[]{100,100}, new int[]{100,100}); }

      Values vs. Entities

      [comp1110-3C]
      • Liam O'Connor, Fabian Muehlboeck

      Think of the number 5. If you add 1 to it, you don't "change" the 5; you simply produce to a completely different value, 6. The number 5 is immutable and has no identity other than its value. Enums behave like this, which is why you can compare them with ==. Strings, on the other hand, are immutable, but have identity, so there can be two String entities that represent the same text, but are different entities, and so == does not work.

      Now think about your bank account. If you deposit 100 dollars into your bank account, you don't get a new bank account, rather, your existing bank account is updated to reflect the new reality. This is also important when there are multiple people accessing the same bank account - they should see the same data, which would not be true if everyone kept creating new copies of it every time they change something. We saw this concept before when sorting arrays and when Inserting into a binary search tree.

      Related

        Warning. String comparisons

        [comp1110-0H]
        • July 30, 2026
        • Liam O'Connor, Fabian Muehlboeck

        If you are familiar with other programming languages, you might be wondering why we compared strings in Example [comp1110-0G] using a.equals(b) instead of something like a == b. While a == b is indeed the normal way to compare (e.g.) numbers, in Java equality for Strings is a little more complicated. In Example [comp1110-0G], a comparison answer == "yes" would always fail, even if the contents of answer were identical to the contents of the string "yes", because the two strings themselves have different identities, and exist at different locations in memory. Using the notation answer.equals("yes") instead compares the contents of the strings rather than their location, which is usually the functionality that we want.

        Note. Array Equality

        [comp1110-73]
        • Fabian Muehlboeck

        We've seen earlier that String Equality requires special attention compared to the more common equality operator ==. This is because the operator == expresses sameness, either of a numerical value, or of something larger within computer memory. Sameness implies equality, but not necessarily the other way around. We will look at the technical reasons for this later in the course.

        Similar to Strings, Arrays are also larger things in computer memory. But in contrast to Strings, the contents of arrays can change. What that means is that if your idea of equality is that two arrays contain equal values in the same order, then that may be true at one point in your program, and false at a different point, as the contents of one or both of the arrays may change in the meantime. This means that the identity of each array matters a lot more than it does for Strings.

        For that reason, a.equals(b) on arrays is the same as a == b. However, the Java Standard Libraries contain a number of standard functions dealing with arrays, among them a suitable equality function. To use it, you need to add an import declaration for java.util.Arrays to the top of your file. You can then use the expression Arrays.equals(a,b) to compare two arrays for equality based on the equality of their elements.

        Warning. Enums are reference types

        [comp1110-2I]
        • Liam O'Connor, Fabian Muehlboeck

        In Java, enum values are technically things that reside in memory, like Strings and arrays: each constant such as Month.JANUARY or Month.AUGUST has its own place in memory. However, for each constant there is exactly one object created by the Java runtime. This means every time the program refers to Month.JANUARY, it refers to the same object. Because there is only one instance of each constant, it is safe to compare enum values using ==. The comparison simply checks whether the two references point to the same object, which correctly tells us whether the two enum values are the same.

        bars magnifying-glass caret-down plus minus arrow-right xmark