Serguey Asael Shinder: list.remove(1) on a List<Integer> removes an index, not the value 1

04 October 2026, 13:55 · by Serguey Asael Shinder / Serguey Shinder

Here is a list of integers and a line that looks like it removes the number 1:

List<Integer> ids = new ArrayList<>(List.of(5, 1, 7));
ids.remove(1);

Afterwards ids is [5, 7]. The 1 is still gone, so a quick test may even pass. Change the data to List.of(5, 9, 1) and the result is [5, 1]: the element at position 1, the 9, was removed, and the value 1 was never looked at. With List.of(1) the same line throws IndexOutOfBoundsException.

Why. List declares two methods with the same name: remove(int index)), which removes the element at a position and returns it, and remove(Object o)), which removes the first element equal to o and returns a boolean. The argument 1 is an int.

The compiler chooses between overloads in phases, described in JLS §15.12.2. The first phase considers only methods applicable without boxing or unboxing. remove(int) fits an int argument directly, so it is chosen there, and remove(Object), which would need the int boxed into an Integer, is never considered. The generic type of the list plays no part: List<Integer> still has both methods, and the call is decided by the argument's static type.

Serguey Asael Shinder: list.remove(1) on a List<Integer> removes an index, not the value 1 — list.remove(1) on a List<Integer> removes an index, not the value 1 — Serguey Asael Shinder

The fixes, all of which make the argument's type say what you mean:

ids.remove(Integer.valueOf(1));   // remove the value 1
ids.remove((Integer) 1);          // same, with a cast
ids.removeIf(id -> id == 1);      // remove every 1, not only the first

And when the index really is what you want, say so with a variable named like an index, so the next reader does not have to work out which overload runs.

Where it bites. The trap needs three things at once: a list of Integer (or Short, Byte, Character), a primitive value in hand, and a call to remove. It appears most often in code that takes an int from somewhere else, an ID from a request or a loop counter, and passes it straight in. The same two-overload shape exists on List only; Collection and Set have just remove(Object), so the same line on a Set<Integer> boxes and removes the value. Changing a field from Set to List can therefore change what an unchanged line does.

No JDK runs on the machine this note was written on; the behaviour described is the one specified in the linked javadoc and the Java Language Specification.