In AP Computer Science A, a mutable object is an object whose internal state (its instance variables) can be changed after it's created, like an ArrayList or an array. This contrasts with immutable objects like String, whose state can never change once constructed.
A mutable object is an object you can change after it exists. If a method or assignment can alter the values stored inside the object (its instance variables), the object is mutable. An ArrayList is the classic example. You can call add, remove, or set on it all day, and it's still the same object in memory, just with different contents. Arrays work the same way, since you can reassign any element.
The flip side is an immutable object, where the state is locked in at construction. String is the big one in Java. When you "change" a String with something like concat or substring, you actually get a brand new String object back; the original never changes. Mutability matters so much in AP CSA because of references. When you pass a mutable object to a method or constructor, you're passing a reference to the same object, not a copy. Anyone holding that reference can reach in and change the object, which is exactly the kind of side effect well-designed classes try to prevent.
Mutability shows up the moment you start using objects and never goes away. It's central to writing classes, where encapsulation is the headline design principle. If a constructor stores a mutable object (like an ArrayList) that was passed in as a parameter without copying it, outside code still has a reference to that same object and can modify your class's private data from the outside. That's a hole in encapsulation, and it's why the standard practice is to copy mutable parameters in the constructor (for an ArrayList, usually new ArrayList<>(original) or copying elements in a loop). The same reasoning explains classic exam behaviors, like why a method that modifies an array parameter changes the caller's array, but a method that reassigns a String parameter doesn't affect the caller's String. If you can trace what happens to mutable versus immutable objects through method calls, a whole category of tricky multiple-choice questions becomes predictable.
Keep studying AP Computer Science A Unit 3
Immutable Object (Units 1-2)
The direct opposite. String is immutable, so methods like substring return a new String instead of changing the original. ArrayList is mutable, so add and set change the actual object. Knowing which is which tells you whether a method call can have side effects.
Object's State (Unit 2)
Mutability is literally a question about state. An object's state is the set of values in its instance variables, and a mutable object is just one whose state can change after construction. Setter methods exist precisely to mutate state in a controlled way.
Encapsulation and Writing Classes (Unit 5)
This is where mutability becomes a design issue. Storing a mutable parameter directly in a private instance variable leaks a reference to the outside world. Copying it in the constructor keeps your class in full control of its own data.
Arrays and ArrayLists (Units 6-7)
The mutable objects you'll work with most. Because they're passed by reference, a method that sorts or modifies an array parameter changes the caller's array too. This is the source of countless "what does this print?" MCQ traps.
You won't get a question that just asks "define mutable object," but the concept is baked into both sections. Multiple-choice questions test whether you can trace references, like predicting what prints after a method modifies an array or ArrayList parameter, or recognizing that a String passed to a method can't be changed by it. Practice questions hit this from the design side too, asking why a mutable object passed to a constructor should be copied, what risk you take by not copying it, and how copying affects encapsulation. On the FRQs, especially the class-design question, you're expected to apply this yourself. If your constructor takes an ArrayList and you store the reference directly, you've created exactly the encapsulation leak graders are trained to spot. Copy the mutable parameter and you're safe.
A mutable object's state can change after creation (ArrayList, arrays). An immutable object's state cannot (String). The confusion comes from code like str = str.substring(1), which looks like the String changed. It didn't. A new String was created and the variable was pointed at it. With an ArrayList, list.add(x) genuinely changes the existing object, so every variable referencing it sees the change. Ask yourself one question to tell them apart. Did the object change, or did the reference change?
A mutable object is one whose instance variables can be changed after the object is created, like an ArrayList or an array.
String objects are immutable, so String methods never change the original String; they return a new one instead.
Passing a mutable object to a method passes a reference, so the method can change the original object and the caller will see it.
Constructors should copy mutable objects passed as parameters, because storing the original reference lets outside code modify your private data and breaks encapsulation.
To copy an ArrayList in a constructor, create a new ArrayList and copy the elements, rather than assigning the parameter directly to an instance variable.
On trace-the-code questions, first decide whether the object being passed around is mutable, because that determines whether method calls can have side effects.
A mutable object is an object whose state (its instance variables) can be modified after it's created. ArrayLists and arrays are the main mutable objects in AP CSA, while String is the main immutable one.
No. String is immutable, meaning its state never changes after construction. Methods like substring and concat return a brand new String object, and the original is untouched.
Because the parameter is just a reference to the original object. If you store that reference directly, code outside your class can still modify the object, which means your private data isn't really private. Copying it (for example, new ArrayList<>(param)) preserves encapsulation.
A mutable object's contents can change after creation (calling list.add(x) changes the actual ArrayList), while an immutable object's contents are fixed forever (any "change" to a String creates a new object). The practical difference on the exam is side effects, since methods can permanently alter mutable arguments but not immutable ones.
Yes. Arrays are mutable and passed by reference, so when a method modifies elements of an array parameter, it's modifying the caller's actual array. Reassigning the parameter variable itself, though, has no effect on the caller.