Java Array Copies: A New Array Does Not Always Mean Independent Objects

Copying an array can protect its structure without protecting the mutable objects inside it. That distinction matters when code passes data between components and expects one component’s changes to remain isolated.

The useful question is not simply whether an array was copied. It is which parts of the data now have independent storage and which references are still shared.

Start with the outer container

Arrays.copyOf creates an array with the requested length. For an object array, values at corresponding positions are preserved; additional positions are filled with null when the requested length is larger.

Consider:

StringBuilder[] original = {
    new StringBuilder("draft")
};

StringBuilder[] copy =
    Arrays.copyOf(original, original.length);

The two arrays are separate containers. However, their first elements refer to the same StringBuilder.

This is a direct consequence of copying reference values. The method has no application-specific instruction to construct a new version of every referenced object.

Distinguish replacement from mutation

These operations have different effects:

copy[0].append("-reviewed");

This changes the shared builder, so observing original[0] also reveals the changed content.

By contrast:

copy[0] = new StringBuilder("approved");

This replaces a reference in the copied array. It does not replace the reference stored in the original array.

This small example is a useful review tool because it separates two questions: “Can the caller change an array entry?” and “Can the caller change an object reached through an entry?”

A defensive copy of the container addresses the first question. It does not automatically answer the second.

Define copying around the domain

If independent mutable elements are required, construct them deliberately:

StringBuilder[] independent =
    new StringBuilder[original.length];

for (int i = 0; i < original.length; i++) {
    independent[i] = new StringBuilder(original[i]);
}

This example assumes every element is non-null. Production code must define the intended behavior for null entries rather than accidentally failing on them.

More complex domain objects require more careful decisions. Should a copied order share its customer record? Should it retain the same identity? Should nested collections also be copied?

There is no universal answer hidden inside the phrase “deep copy.” The application needs a policy describing which relationships remain shared.

Test ownership through observable behavior

A useful test changes the copied container and checks that the original container is unaffected. A second test changes an element and checks whether the original element should or should not change.

Both tests are necessary when mutable objects are involved.

Multidimensional arrays deserve similar attention because their elements can themselves be arrays. Copying only the outer structure does not establish independence for every nested level.

Choose names that communicate intent, such as snapshotValues or copyReferences, when they clarify a public API. Document whether callers may modify returned data and what those modifications affect.

The strongest protection comes from an explicit ownership model. Array-copying methods are useful building blocks, but the application must decide what independence actually means.

Sources: Oracle: Arrays API and copyOf