{
  "id": 26331,
  "title": "Java References vs Values: The Mistake That Confused Me",
  "url": "https://urgent.news/2026/08/02/java-references-vs-values-the-mistake-that-confused-me",
  "topic": "culture",
  "section": "Culture",
  "published": "2026-08-02T04:14:57.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/majin-dev/java-references-vs-values-the-mistake-that-confused-me-a46"
  },
  "original_language": "en",
  "account": "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:\n\nint a = 5;\nint b = a;\nb = 10;\nSystem.out.println(a); // Outputs 5\nSystem.out.println(b); // Outputs 10\n\nIn this scenario, modifying b does not alter a. The concept is straightforward. However, when dealing with objects, the situation differs considerably:\n\nclass Dog {\nString name;\n}\n\nDog dog1 = new Dog();\ndog1.name = \"Rex\";\nDog dog2 = dog1;\ndog2.name = \"Max\";\nSystem.out.println(dog1.name); // Outputs \"Max\"?\nI 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:\n\npublic static void rename(Dog d) {\nd.name = \"Buddy\";\n}\nDog myDog = new Dog();\nmyDog.name = \"Rex\";\nrename(myDog);\nSystem.out.println(myDog.name); // Outputs \"Buddy\"\n\nIn 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:\n\nString s1 = \"hello\";\nString s2 = s1;\ns2 = \"world\";\nSystem.out.println(s1); // Outputs \"hello\"\nSystem.out.println(s2); // Outputs \"world\"\n\nIn 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.",
  "summary": "Java references and values can be a source of confusion for beginners in object-oriented programming. When dealing with primitive types, assignment creates a copy, just as expected. However, with objects, the situation changes. Assigning one object reference to another does not create a copy of the object itself, but rather a copy of the reference (an address) to the object in memory. Consequently, both references point to the same object. Modifying the object through one reference affects the original object, as demonstrated in the provided example with the Dog class. This behavior differs from strings, which are also objects in Java but are immutable, leading to expected behavior when reassignment occurs. Understanding this distinction is crucial to avoid bugs and unexpected outcomes in Java programming.",
  "key_points": [
    "Primitive types in Java behave predictably when assigned to variables",
    "Object variables store references to objects in memory, not the objects themselves"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}