Element-by-Element Array Copy

Before You Start

Check each box you can do from memory. A box you cannot check yet is not a problem; it points you to a quick refresher, not a grade.

• I can explain when a defensive copy is necessary versus when sharing a reference is safe. (See Immutable Fields Need No Defensive Copy.)
• I can identify the difference between copying an array’s outer container and copying the objects inside it.
• I can write a for loop that reads from one array and assigns into a corresponding index of a second array.
• I can explain what “mutable” means for a class and give an example of a mutation through a reference.

Try This First

The S20.Lab3.Book constructor receives an Author[] author parameter. The Book’s Javadoc says: “NOTE You will not just assign the passed in author array to the class level variable”. Before reading: why is this warning necessary? What would happen if the book did this.authors = author?

What You Need To Walk In With

The Insight: Defensive copy for arrays of mutable objects requires two levels: a fresh outer array AND fresh object instances at each position. Copying only the outer array (Arrays.copyOf) leaves the element references shared. This is called a shallow copy, and it only protects against someone replacing a slot (author[0] = x), not against someone mutating the object in a slot (author[0].setFirstName("x")). When elements are mutable, only a deep (element-by-element) copy provides true isolation.

If two levels of copying feels complex, break the work into two separate tasks. Task 1 allocates a fresh outer array. Task 2 loops over each position and allocates a new element object. Each task is a single line or a simple loop, and writing them separately makes each one easy to verify independently.

You can: explain why Arrays.copyOf is insufficient for mutable elements; write the two-step element-by-element copy; apply it correctly to S20.Lab3.Book’s Author[] field; and write the matching defensive copy in an accessor that returns the same field.

How It Works

The S20 Lab 3 pattern

From S20.Lab3.Book.java, the constructor body for Author[] authors:

this.authors = new Author[author.length];   // Step 1: fresh outer array
for (int x = 0; x < author.length; x++)    // Step 2: fresh element at each index
{
    String[] name = author[x].getName().split(",");
    String first  = name.length > 1 ? name[1].trim() : "";
    String last   = name[0].trim();
    this.authors[x] = new Author(first, last);   // new Author object
}

After this runs:

• this.authors is a different array object from the caller’s author.
• this.authors[0] is a different Author object from author[0].
• Neither the array nor any element is shared with the caller.

Why Arrays.copyOf is not enough

// INSUFFICIENT: shallow copy
this.authors = Arrays.copyOf(author, author.length);

// After this:
// this.authors[0] == author[0]  (same Author object!)
// author[0].setFirstName("Hacked")  -> also changes this.authors[0]

Arrays.copyOf creates a new array of the same length and copies the references. The elements (the Author objects) are not copied. Both arrays point to the same objects.

For immutable elements (String[], Integer[]), this is sufficient because the elements cannot be mutated. For mutable elements, it is not.

The defensive copy in the accessor

Bloch, Effective Java, Item 50 identifies a second location where defensive copy is needed: the return path. If getAuthors() returns this.authors directly, the caller receives a reference to the internal array. Mutations through that reference affect the Book’s internal state.

// WRONG: exposes internal array
public Author[] getAuthors() {
    return this.authors;
}

// CORRECT: defensive copy on the way out
public Author[] getAuthors() {
    Author[] copy = new Author[this.authors.length];
    for (int x = 0; x < this.authors.length; x++)
        copy[x] = new Author(this.authors[x].getFirstName(),
                             this.authors[x].getLastName());
    return copy;
}

From W17.Lab1.Sandwich.getToppings(): the same element-by-element copy is applied to String[] on both the constructor (copy in) and the accessor (copy out). String is immutable, so a shallow copy would suffice here, but the pattern is correct regardless.

Quick check

Worked Example: Predict Then Check

Author[] original = { new Author("Alice", "Smith"), new Author("Bob", "Jones") };

// Book A: shallow copy
// Book B: deep (element-by-element) copy

original[0].setFirstName("Hacked");

System.out.println("A[0]: " + bookA.getAuthors()[0].getFirstName());
System.out.println("B[0]: " + bookB.getAuthors()[0].getFirstName());

Predict the output for each book (assuming both getAuthors return the internal array directly for simplicity).

Common Misconceptions

Misconception 1: Arrays.copyOf is sufficient defensive copy for mutable elements

Wrong mental model: “Arrays.copyOf(author, author.length) creates a fresh copy of the array; the Book is isolated.”

Why it breaks: Arrays.copyOf copies only the array container (the slots), not the objects in the slots. For mutable element types, the caller can still mutate the shared element objects. The Book’s internal state changes without any assignment through the internal reference.

How to correct: For an array of mutable elements, loop and call new Element(...) at each index. This is the element-by-element deep copy.

Source: Bloch, Effective Java, Item 50; S20.Lab3.Book.java Javadoc warning.

Quick check

Misconception 2: defensive copy is only needed in the constructor

Wrong mental model: “I copied on the way in; the accessor can just return this.authors directly.”

Why it breaks: The accessor exposes the internal array. The caller can store the returned reference and mutate elements or replace slots:

Author[] exposed = book.getAuthors();
exposed[0].setFirstName("Hacked");   // affects book's internal state

How to correct: Apply defensive copy in the accessor too. Return a fresh copy of the array with fresh element copies. Alternatively, expose only indexed access (getAuthor(int i)) with no way to obtain the array reference.

Source: Bloch, Effective Java, Item 50.

Formal Definition and Interface Contract

From Bloch, Effective Java, Item 50:

If a class contains components that are mutable, you must defend against this mutation by making a defensive copy. [...] Note also that we did not use clone to make a defensive copy of a parameter whose type is a subclassable class, because we cannot guarantee that the clone method returns an object whose class is java.util.Date and not some untrusted subclass. [...] When in doubt, don’t use clone.

From S20.Lab3.Book.java Javadoc:

NOTE You will not just assign the passed in author array to the class level variable.

Mental Model

Think of a shallow copy as photocopying a phone directory. You get a new set of pages with the same phone numbers listed. If someone changes their phone number in the original directory, the copies’ entries still show the old number’s value... but wait: the “phone numbers” here are references to people (mutable objects). Changing a person’s name changes it through every directory that refers to them. A deep copy would also copy the people themselves, so each directory has its own independent people.

Connections

Within CSCD 210/211: S20.Lab3.Book and W17.Lab1.Sandwich both demonstrate the pattern. Sandwich.getToppings() applies element-by-element copy on the read path; Book’s constructor applies it on the write path.

Looking back: Immutable Fields Need No Defensive Copy covered when NOT to copy. This lesson covers the deepest form of copying: when the element type itself is mutable.

Looking ahead: The next topic covers multiple constructors. A class with arrays of mutable objects needs the same defensive copy pattern in each constructor that accepts the array.

Practice

Level 1

Write the element-by-element defensive copy for Author[] author into this.authors, given that Author has constructors Author(String firstName, String lastName) and getters getFirstName(), getLastName().

this.authors = new Author[author.length];
for (int x = 0; x < author.length; x++)
    this.authors[x] = new Author(author[x].getFirstName(), author[x].getLastName());

Level 2

Explain why this.authors = Arrays.copyOf(author, author.length) is insufficient and this.authors = author is wrong. Then write the correct form.

this.authors = new Author[author.length];
for (int x = 0; x < author.length; x++)
    this.authors[x] = new Author(author[x].getFirstName(), author[x].getLastName());

Level 3

Write public Author[] getAuthors() as a defensive copy accessor for the this.authors field. Explain why this accessor copy is also necessary.

public Author[] getAuthors()
{
    Author[] copy = new Author[this.authors.length];
    for (int x = 0; x < this.authors.length; x++)
        copy[x] = new Author(this.authors[x].getFirstName(),
                             this.authors[x].getLastName());
    return copy;
}

Go Deeper (optional)

Nothing in this section is needed to write correct code. It is here for curiosity, and you should feel good about the topic whether or not you read it.

Where this shows up in professional code. Shallow vs. deep copy is a standard technical interview topic and a recurring source of production bugs in real codebases. The professional pattern matches exactly what the lab teaches: apply defensive copy at both the write path (constructor) and the read path (accessor), and for every mutable type held in a collection or array. Missing the accessor copy is the more common omission in professional code because it is the less obvious of the two.

When the manual loop is not enough. Java provides Arrays.copyOf for shallow copy and nothing built-in for deep copy of objects. For simple flat classes like Author, the manual loop is correct and readable. For complex object graphs where each element itself holds mutable arrays or references, a single loop is insufficient: you need a recursive strategy or a serialization-based approach. Libraries such as Apache Commons Lang provide SerializationUtils.clone for this, but they require every class in the graph to implement Serializable and carry significant overhead. The manual loop in the lab is appropriate precisely because Author is flat: its fields are strings, and strings are immutable, so one level of element-by-element copy closes all the gaps.

The design alternative. One reason this two-level copy feels laborious is that Author is a mutable class. If Author were designed as immutable (all fields final, no setters), the problem disappears entirely: you would never need to deep-copy it, because no caller can mutate an Author object through any reference. This trade-off between designing types to be immutable versus writing defensive copy everywhere they appear is central to how the Java standard library and libraries like Guava approach API design. Bloch addresses this directly in Effective Java, Item 17 (“Minimize mutability”), arguing that immutable value types should be the default and mutable types the deliberate exception. The defensive-copy pattern you are practicing here is the correct answer when you inherit a mutable type you did not design.

Check Yourself

Close the notes and answer each one from memory, then reveal it. Pulling an idea back from memory is one of the strongest ways to make it stick.