Java References vs Values: The Mistake That Confused Me

When I began my journey into object-oriented programming with Java, I encountered a significant obstacle that I believe many novices face: a misunderstanding of how variables function, particularly when objects come into play. The error I committed and the subsequent clarification that brought clarity will be outlined below. The error In Java, primitive data types (such as int, double, boolean, and char) behave predictably - assigning one variable to another creates an independent copy. For instance:

int a = 5;

int b = a;

b = 10;

System.out.println(a); // Outputs 5

System.out.println(b); // Outputs 10

In this scenario, modifying b does not alter a. The concept is straightforward. However, when dealing with objects, the situation differs considerably:

class Dog {

String name;

}

Dog dog1 = new Dog();

dog1.name = "Rex";

Dog dog2 = dog1;

dog2.name = "Max";

System.out.println(dog1.name); // Outputs "Max"?

I anticipated dog1.name to remain "Rex", similar to how a remained 5 in the earlier example. Unfortunately, the output was "Max" instead. This moment of realization revealed that objects operate differently from primitive types. What's happening with objects? In the case of objects, a variable doesn't store the object itself; it stores a reference (essentially an address) indicating the location where the object resides in memory.

When I executed Dog dog2 = dog1;, I didn't duplicate the Dog object. Instead, I replicated the reference. Consequently, both dog1 and dog2 were directed towards the identical object in memory. Modifying dog2.name indeed altered the sole Dog object present - the one both variables were pointing to. The analogy here is akin to copying the address on an envelope rather than duplicating the letter itself.

If you duplicate the address and a house at that address is repainted, both address copies now refer to the freshly painted house. The significance in practice This concept isn't merely theoretical; it has practical implications that can lead to bugs. A frequent issue arises when an object is passed into a method, modified within the method, and the original object unexpectedly changes. Here's an example:

public static void rename(Dog d) {

d.name = "Buddy";

}

Dog myDog = new Dog();

myDog.name = "Rex";

rename(myDog);

System.out.println(myDog.name); // Outputs "Buddy"

In this code, myDog is a reference, and passing it to the rename() method transfers a copy of the reference, not a duplicate of the object. Both myDog and the reference within the method refer to the same Dog object. Hence, modifications made inside the method impact the original object. The exception that further perplexed me involved Strings.

Despite being objects in Java, Strings exhibit unique behavior due to their immutability. Once established, a String's content cannot be altered. Thus, this code behaves as expected:

String s1 = "hello";

String s2 = s1;

s2 = "world";

System.out.println(s1); // Outputs "hello"

System.out.println(s2); // Outputs "world"

In contrast to the previous example, s2 = "world" doesn't modify the existing String; instead, it creates a new String object and assigns it to s2. The original String (and s1) remains unchanged. My conclusion The pivotal lesson I grasped is that primitives copy their value, whereas object variables copy their reference (the address), not the object itself.

When two variables point to the same object, altering the object via one variable will be reflected through the other. However, if the object is immutable, like Strings, "changing" it actually generates a new object instead. Understanding that object variables are akin to "sticky notes with an address on them" rather than "boxes holding values" significantly simplified the complexities of Object-Oriented Programming.

As a final-year software engineering student sharing my learning experiences, this distinction proved instrumental in my comprehension of OOP principles.