In AP Computer Science A, immutable means an object's state cannot be changed after it's created; the classic example is the String class, where methods like substring and concat never alter the original String but instead return a new String object.
Immutable describes an object whose internal state is locked in the moment it's constructed. You can read it, copy it, and call methods on it, but nothing can rewrite what's inside. If you want a "changed" version, you don't edit the original. You get a whole new object back.
In AP CSA, the star example is the String class. When you call str.substring(0, 3) or str.toUpperCase(), the original String sitting in memory is untouched. Java builds a fresh String containing the result and hands it to you. That's why a line like str.toUpperCase(); by itself does nothing useful. You have to capture the return value, like str = str.toUpperCase();, which makes the variable point to the new object. The old String didn't change. Your reference just moved.
Immutability shows up the moment you start using objects in Unit 2, because the CED's essential knowledge about the String class explicitly treats Strings as immutable. Every String method that looks like it "modifies" a String actually returns a new one. This single fact explains a huge family of tracing mistakes. If you forget it, you'll predict that s.concat("!") changed s, and you'll miss easy multiple-choice points. It also sets up a bigger idea you carry into Units 5-7: some objects (Strings, wrapper objects like Integer) are frozen, while others (arrays, ArrayLists, your own classes with mutator methods) can be changed in place. Knowing which is which tells you whether a method call can have side effects on the caller's data, which matters for writing and reading FRQ code.
String Class (Unit 2)
Strings are THE immutable object on the AP exam. Methods like substring, concat, and toUpperCase return new Strings, so the original never changes unless you reassign the variable to the result.
Final Keyword (Units 1 & 5)
These get mixed up constantly. final freezes a variable so it can't be reassigned to a different object, while immutable freezes the object itself. A final ArrayList variable can still have elements added to it, because the list object is mutable even though the reference is locked.
Mutable (Units 6 & 7)
Mutable is the direct opposite. Arrays and ArrayLists can be changed in place, so list.add(x) or arr[0] = 5 really does modify the original object. When a mutable object is passed to a method, changes inside the method stick. With an immutable String, they can't.
Immutability is mostly tested through String tracing in multiple choice. A classic stem gives you code like String s = "hello"; s.substring(0, 3); and asks what s holds afterward. The answer is still "hello", because substring returned a new String that was never stored. On FRQs, immutability shows up whenever you write string-building code. You can't edit a String in a loop, so the standard pattern is building up a result with reassignment, like result = result + nextPart; or result += word.substring(1);. Forgetting to reassign is one of the most common point-losing mistakes in string-manipulation FRQs. No released FRQ asks you to define "immutable" directly, but the concept is baked into nearly every question that touches Strings.
final and immutable lock different things. final locks the variable, meaning the reference can never be reassigned to point at a different object. Immutable locks the object, meaning its contents can never change. The two are independent. A final variable can point to a mutable ArrayList that you freely add to, and a non-final String variable can be reassigned all day even though each individual String object is immutable. Quick test: ask "can the object's contents change?" (immutability) versus "can the variable point somewhere new?" (final).
Immutable means an object's state cannot be changed after it is created, and in AP CSA the most important immutable class is String.
String methods like substring, concat, and toUpperCase never modify the original String; they return a brand-new String object.
Calling a String method without storing the result, like s.toUpperCase();, does nothing. You must reassign, like s = s.toUpperCase();.
Immutable is about the object, while the final keyword is about the variable. A final reference to a mutable object can still have its contents changed.
Arrays and ArrayLists are mutable, so methods can change their contents through a reference, which is impossible with an immutable String.
Immutable means an object cannot be changed after it's created. In AP CSA the key example is the String class, where every "modifying" method actually returns a new String instead of editing the original.
No. Since Strings are immutable, str += "x" creates a brand-new String containing the combined text and makes the variable str point to it. The original String object is never modified.
No. final means a variable can't be reassigned to a different object, while immutable means the object itself can't change. A final ArrayList can still have elements added or removed because the list object is mutable.
No, both are mutable. You can change an array element with arr[i] = value and modify an ArrayList with methods like add, set, and remove, all of which affect the original object.
Because Strings are immutable, substring builds and returns a new String containing characters 0 through 2 and leaves s untouched. To keep the result, write s = s.substring(0, 3); so the variable points to the new String.