Everyday List operations: find, copy, compare and remove

For this lesson, we'll focus on the list operations that show up in interviews and production reviews: find, copy, compare, remove and random selection. We'll use Java 21, so List is also a SequencedCollection and has getFirst, removeFirst and friends. Interviewers ask this because the code is short enough to write on a whiteboard, but the edge cases expose whether you understand equals, overloads, mutability and Big-O.

01Picture it first: a checkout counter with labels

Think of a List as a checkout counter with receipts laid out left to right. Finding by value means reading labels until one matches. Copying means making a second row of receipt references, not photocopying every receipt object. Removing by index means taking the receipt at slot 1; removing by value means looking for the receipt whose label equals 1.

Here is the overload trap I want you to draw before you code removals on an Integer list.

Fig. 1

A decision chart shows that list.remove(1) removes index 1, while list.remove(Integer.valueOf(1)) removes the value 1 after an equals search

The picture has one practical message: make the overload visible. If the list stores Integer, remove(1) is almost never the line you want unless you truly mean index 1.

02Finding an element under the hood

The simplest find methods are value-based scans. contains(x) answers yes or no, indexOf(x) returns the first index or -1, and lastIndexOf(x) searches from the end. All three use equals semantics, with special handling for null in mutable JDK lists such as ArrayList.

record Order(String id, int cents) { }

List<Order> orders = List.of(
    new Order("A-100", 4999),
    new Order("B-200", 1299),
    new Order("A-100", 4999)
);

Order target = new Order("A-100", 4999);
System.out.println(orders.contains(target));     // true, record equals compares components
System.out.println(orders.indexOf(target));      // 0
System.out.println(orders.lastIndexOf(target));  // 2

Order cheap = orders.stream()
    .filter(order -> order.cents() < 2000)
    .findFirst()
    .orElseThrow();                              // B-200

Notice three things:

• contains and indexOf depend on equals, not identity. A record gives you value equality by default.
• findFirst is still O(n) in the worst case, but it lets you search by a predicate such as price, status or timestamp.
• lastIndexOf is useful when the newest update was appended at the end and duplicates are possible.

Collections.binarySearch is different. It does not scan; it repeatedly checks the middle, so it is O(log n) on a random-access sorted list. But the list must already be sorted according to the same natural order or comparator you pass to the search.

List<String> sortedIds = new ArrayList<>(List.of("B-200", "A-100", "C-300"));
sortedIds.sort(Comparator.naturalOrder());       // [A-100, B-200, C-300]

int index = Collections.binarySearch(sortedIds, "B-200");
System.out.println(index);                       // 1

int missing = Collections.binarySearch(sortedIds, "B-250");
System.out.println(missing);                     // negative insertion-point encoding

If the list is unsorted, binary search gives undefined answers. It may return a wrong index, a negative value, or appear to work in a small test. The default I recommend is linear search until you already maintain sorted order for another reason.

03Copying a list: snapshot, mutable copy or overwrite

Copying a list is really three decisions: do you want the new list to be mutable, do you need a snapshot independent of future source changes, and do you need to copy the elements themselves? Most everyday copies are shallow snapshots: a new list object, same element references.

record LineItem(String sku, int quantity) { }

List<LineItem> source = new ArrayList<>(List.of(
    new LineItem("book", 1),
    new LineItem("pen", 3)
));

List<LineItem> copyByConstructor = new ArrayList<>(source); // mutable, shallow
List<LineItem> copyByAddAll = new ArrayList<>();
copyByAddAll.addAll(source);                                // mutable, shallow
List<LineItem> snapshot = List.copyOf(source);              // unmodifiable, shallow

source.add(new LineItem("bag", 1));
System.out.println(copyByConstructor.size());               // 2
System.out.println(snapshot.size());                        // 2

new ArrayList<>(source) is the everyday mutable copy. addAll is useful when the destination already exists or when you are merging multiple sources. List.copyOf (Java 10+) returns an unmodifiable list, rejects null elements, and may return the same instance if the input is already one of the JDK's unmodifiable lists.

Collections.copy(dest, src) is the odd one. It does not grow dest; it overwrites existing positions. The destination must already have at least src.size() elements.

List<String> src = List.of("read", "write", "admin");
List<String> dest = new ArrayList<>(Collections.nCopies(src.size(), ""));

Collections.copy(dest, src);
System.out.println(dest);                         // [read, write, admin]

List<String> tooSmall = new ArrayList<>();
// Collections.copy(tooSmall, src);               // IndexOutOfBoundsException

The trade-off is clarity. Use a constructor for a new mutable copy, List.copyOf for an unmodifiable snapshot at a boundary, and Collections.copy only when you intentionally overwrite a pre-sized list.

We cover shallow versus deep copying fully in Deep copy vs shallow copy in Java. For this lesson, remember the interview line: copying a List<Customer> usually copies customer references, not customer objects.

04Checking whether two lists are equal

List.equals is strict in the way most tests should be strict. Two lists are equal when they have the same size and each element at index i is equal to the element at index i in the other list. Order matters.

List<String> expected = List.of("created", "paid", "shipped");
List<String> actual = List.of("created", "paid", "shipped");
List<String> reordered = List.of("paid", "created", "shipped");

System.out.println(expected.equals(actual));     // true
System.out.println(expected.equals(reordered));  // false

Ignoring order is where bugs enter. The naive pattern is a.containsAll(b) && b.containsAll(a). That checks membership, not multiplicity, so [A, A, B] and [A, B, B] both pass.

static <T> Map<T, Long> frequencies(List<T> values) {
    return values.stream().collect(Collectors.groupingBy(
        Function.identity(),
        Collectors.counting()
    ));
}

List<String> left = List.of("A", "A", "B");
List<String> right = List.of("A", "B", "B");

System.out.println(left.containsAll(right) && right.containsAll(left)); // true, wrong
System.out.println(frequencies(left).equals(frequencies(right)));       // false

If elements are comparable and you are allowed to reorder copies, sorting copies is also fine: O(n log n) time and O(n) extra space. Frequency maps are O(n) expected time and O(u) space, where u is the number of distinct elements. For tests, AssertJ's containsExactlyInAnyOrder does the duplicate-aware thing; with plain JUnit, compare sorted copies or frequency maps using assertEquals.