A little note on referential equality in Java

Answering M. F. Hasler’s question, I casually tossed off the term “referential equality.” It’s one of those terms that I’ve come to take for granted, forgetting that sometimes it needs to be explained, even if the reader has a good idea what I meant.

Consider this Java unit testing toy example:

public void testAdditionToyExample() {
int expected = 2;
int actual = 1 + 1;
assert expected == actual;

Suppose gets allocated in memory at 04F0 and gets allocated right after at 04F4. The memory allocations don’t matter for the assertion: and hold the same value, so the test passes, just as one would expect.

Now consider this other unit testing toy example:

public void testStringToyExample() {
String phrase = "Hello, world!";
String expected = "hello, world!";
String actual = phrase.toLowerCase();

assert expected == actual;

Since both and hold “hello, world!”, we would expect the test to pass. But instead the assertion fails.

That’s because in Java, is a primitive, is a reference type, and the operator works differently for reference types.

Let’s say was allocated at 32A1 BEC0 and at 2292 7A81. For a reference type like , the operator checks the pointers. In this case, they don’t match, so the assertion fails.

The only way this second assertion can pass is if and point to the exact same object.

In Java, every class has , if nothing else, by inheritance from . But just does a comparison with the operator. By overriding , a class like can customize to do something more useful.

Image for post
Image for post
Photo by Erol Ahmed on Unsplash

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store