{"title":"Reference Types","description":"","content":"Primitives store values directly, but most things in Java are objects, and objects live somewhere else. This lesson covers what a reference type is, how reference variables connect to objects in memory, what `null` actually means, and why `==` doesn't compare contents when used with objects. We'll keep the running shop example small so the memory picture stays clear.\n\n---\n\n# What Counts as a Reference Type\n\nJava has exactly 8 primitive types: `int`, `long`, `short`, `byte`, `float`, `double`, `char`, and `boolean`. Everything else is a reference type. That includes `String`, every array (`String[]`, `int[]`, anything with `[]`), and every class you define yourself.\n\nThe key difference shows up in what the variable actually holds:\n\n- A primitive variable holds the value itself. `int price = 10;` and the slot for `price` literally contains `10`.\n- A reference variable holds the address of an object that lives somewhere else in memory. `String name = \"Sara\";` and the slot for `name` contains a reference (you can think of it as a pointer) to a `String` object stored on the heap.\n\nA tiny program that uses both:\n\n\n```java\npublic class CustomerInfo {\n public static void main(String[] args) {\n int loyaltyPoints = 250;\n String customerEmail = \"sara@example.com\";\n\n System.out.println(\"Points: \" + loyaltyPoints);\n System.out.println(\"Email: \" + customerEmail);\n }\n}\n```\n\n\nFrom the outside, both variables look similar. You assigned a value, you printed it. The difference is invisible until you pass variables around, compare them, or one of them is empty.\n\n---\n\n# Stack vs Heap: Where Variables Live\n\nJava splits memory into two regions that matter for this lesson: the **stack** and the **heap**. The stack holds local variables for the method that's currently running. The heap holds objects.\n\nWhen you write `int price = 10;` inside `main`, Java carves out a slot on the stack for `price` and writes `10` into it. The value sits inside the slot, end of story.\n\nWhen you write `String customerName = \"Sara\";`, two things happen:\n\n1. A `String` object holding the characters `S`, `a`, `r`, `a` is created on the heap.\n2. A slot for `customerName` is carved out on the stack, and the address of that heap object is written into the slot.\n\nThe variable doesn't contain `\"Sara\"`. It contains a reference that points to where `\"Sara\"` lives.\n\n\n```mermaid\nflowchart LR\n subgraph Stack\n P[\"price
10\"]:::cyan\n N[\"customerName
(ref)\"]:::orange\n end\n\n subgraph Heap\n S[\"String object
Sara\"]:::teal\n end\n\n N -- points to --> S\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe `price` slot is self-contained. The `customerName` slot is a pointer.\n\nYou don't manage this layout by hand. The JVM decides where things go and the garbage collector cleans up heap objects no one references anymore. What matters is knowing which kind of variable you're holding when you look at a line of code.\n\n\n```java\npublic class StackVsHeap {\n public static void main(String[] args) {\n int orderCount = 3;\n String shippingAddress = \"221B Baker Street\";\n\n System.out.println(\"orderCount lives on the stack: \" + orderCount);\n System.out.println(\"shippingAddress points to a heap object: \" + shippingAddress);\n }\n}\n```\n\n\n---\n\n# Creating Objects with `new`\n\nMost reference values are created with the `new` keyword. When you write `new SomeType(...)`, three things happen:\n\n1. The JVM allocates space for a new object on the heap.\n2. The constructor runs to initialize the object's fields.\n3. The expression evaluates to a reference pointing at the new object.\n\nA small example using an array, which is a reference type with a slightly different `new` syntax:\n\n\n```java\npublic class NewExample {\n public static void main(String[] args) {\n String[] cartItems = new String[3];\n cartItems[0] = \"Wireless Headphones\";\n cartItems[1] = \"Phone Charger\";\n cartItems[2] = \"Laptop Stand\";\n\n System.out.println(\"First item: \" + cartItems[0]);\n System.out.println(\"Cart size: \" + cartItems.length);\n }\n}\n```\n\n\n`new String[3]` allocates a fresh array object on the heap big enough to hold 3 references. The variable `cartItems` then points to that array.\n\n`String` is a special case because Java lets you skip `new` for string literals. Writing `String customerEmail = \"sara@example.com\";` produces a `String` object too, but the literal goes through a separate mechanism called the String Pool. For now, treat string literals as if they create an object on the heap.\n\nEvery `new` allocates fresh memory. In a tight loop, building objects you don't actually need creates pressure on the garbage collector. Reuse objects or use primitives when you can.\n\n---\n\n# `null`: The Absence of a Reference\n\nA reference variable doesn't have to point at anything. `null` is the value that means \"this reference points to no object.\" You assign it explicitly, or you read it from a field that hasn't been initialized.\n\n\n```java\npublic class NullExample {\n public static void main(String[] args) {\n String customerName = null;\n System.out.println(\"Name: \" + customerName);\n }\n}\n```\n\n\nPrinting a `null` reference shows the text `null`. No crash. The trouble starts when you try to use the reference for anything other than passing it around or comparing it.\n\n**What's wrong with this code?**\n\n\n```java\npublic class NullCrash {\n public static void main(String[] args) {\n String customerName = null;\n System.out.println(customerName.length());\n }\n}\n```\n\n\nThe variable holds no reference, so the JVM can't follow it to call `.length()`. You get a `NullPointerException` (often shortened to NPE):\n\n\n```shell\nException in thread \"main\" java.lang.NullPointerException:\n Cannot invoke \"String.length()\" because \"customerName\" is null\n at NullCrash.main(NullCrash.java:4)\n```\n\n\n**Fix:** Check for `null` before using the reference, or assign a real value:\n\n\n```java\npublic class NullSafe {\n public static void main(String[] args) {\n String customerName = null;\n if (customerName != null) {\n System.out.println(customerName.length());\n } else {\n System.out.println(\"Customer name not set\");\n }\n }\n}\n```\n\n\nA second place `null` appears without explicit assignment: reference-type fields default to `null` when a class is created, the same way primitive fields default to `0` or `false`. The defaults are summarized below.\n\n\n| Field type | Default value |\n| ---------- | ------------- |\n| `int`, `long`, `short`, `byte` | `0` |\n| `double`, `float` | `0.0` |\n| `boolean` | `false` |\n| `char` | `''` |\n| Any reference type (`String`, arrays, classes) | `null` |\n\n\nLocal variables (the ones inside a method) don't get defaults. The compiler forces you to assign a value before reading them, which catches a lot of accidental nulls early.\n\n---\n\n# Assigning One Reference to Another\n\nAssigning one reference variable to another does not copy the object. Both variables end up pointing to the same object on the heap.\n\n\n```java\npublic class SharedCart {\n public static void main(String[] args) {\n String[] cartA = new String[3];\n cartA[0] = \"Wireless Headphones\";\n cartA[1] = \"Phone Charger\";\n cartA[2] = \"Laptop Stand\";\n\n String[] cartB = cartA;\n cartB[0] = \"Smart Watch\";\n\n System.out.println(\"cartA[0]: \" + cartA[0]);\n System.out.println(\"cartB[0]: \" + cartB[0]);\n }\n}\n```\n\n\nWe only changed `cartB[0]`, but `cartA[0]` changed too. That's because `cartB = cartA` copied the reference, not the array. After that line, both variables point at the same array object on the heap. Writing through one of them is visible through the other.\n\nCompare with primitives, where assignment really does copy the value:\n\n\n```java\npublic class PrimitiveCopy {\n public static void main(String[] args) {\n int priceA = 100;\n int priceB = priceA;\n priceB = 200;\n\n System.out.println(\"priceA: \" + priceA);\n System.out.println(\"priceB: \" + priceB);\n }\n}\n```\n\n\n`priceA` keeps its original value because primitive assignment hands `priceB` its own slot containing a fresh `100`. Changing one slot doesn't touch the other.\n\nThe reference-sharing behavior matters a lot once methods enter the picture: if you pass a reference into a method and the method mutates the object, the caller sees the change.\n\n---\n\n# `==` vs `.equals()` for References\n\nComparison is the other place where the reference model leaks into your code. The `==` operator compares whatever sits inside the variable. For primitives that means values. For references it means addresses.\n\n\n```java\npublic class EqualityCheck {\n public static void main(String[] args) {\n String emailA = new String(\"sara@example.com\");\n String emailB = new String(\"sara@example.com\");\n\n System.out.println(\"emailA == emailB: \" + (emailA == emailB));\n System.out.println(\"emailA.equals(emailB): \" + emailA.equals(emailB));\n }\n}\n```\n\n\nTwo separate `new String(...)` calls produce two separate objects on the heap. The contents are the same, but the addresses are different, so `==` returns `false`. The `equals` method on `String` compares character by character, so it returns `true`.\n\nA rule of thumb:\n\n- `==` answers \"do these two variables point at the same object?\"\n- `.equals()` answers \"do these two objects have the same contents?\" (when the class defines a meaningful `equals` method, which `String` does).\n\nThere's one catch with string literals when using `==` on strings:\n\n\n```java\npublic class LiteralEquality {\n public static void main(String[] args) {\n String a = \"sara@example.com\";\n String b = \"sara@example.com\";\n System.out.println(a == b);\n }\n}\n```\n\n\nThis prints `true` because string literals share storage through the String Pool. Two literals with the same characters end up referencing the same pooled object, so `==` happens to work. That's a quirk of how the pool optimizes memory, not a general rule about strings. If even one side uses `new String(\"...\")`, you're back to `false`. Use `.equals()` when you care about contents.\n\nThe takeaway here is just the mental model: `==` for \"same object\", `.equals()` for \"same contents.\"\n\n`.equals()` on `String` scans both strings, so it's O(n) in the length. `==` is a single pointer comparison. For very hot code paths comparing pooled or interned strings, `==` can be faster, but it's almost always wrong for general use.\n\n---\n\n# Primitives vs References Side by Side\n\nThe whole lesson reduces to a few practical differences.\n\n\n| Aspect | Primitive | Reference |\n| ------ | --------- | --------- |\n| What the variable holds | The actual value | An address (a reference to an object on the heap) |\n| Where the data lives | Stack slot for the variable | Object lives on the heap; the variable on the stack holds the reference |\n| Default field value | `0`, `0.0`, `false`, `''` | `null` |\n| Can be `null` | No | Yes |\n| `==` behavior | Compares values | Compares references (same object?) |\n| Assignment (`a = b`) | Copies the value | Copies the reference; both point to the same object |\n\n\n\n```java\npublic class PrimitiveVsReferenceDemo {\n public static void main(String[] args) {\n int copiesA = 5;\n int copiesB = copiesA;\n copiesB = 10;\n System.out.println(\"copiesA stays: \" + copiesA);\n\n String[] cartA = { \"Headphones\", \"Charger\" };\n String[] cartB = cartA;\n cartB[0] = \"Speaker\";\n System.out.println(\"cartA[0] changed too: \" + cartA[0]);\n }\n}\n```\n\n\nOne assignment copied a value, the other copied a reference. Same syntax, very different effect.","pageType":"java"}

Reference Types

Get Premium