What prevents Java from having immutable primitive arrays?

Question

Java never had immutable primitive arrays. However Java does have an immutable List or Map or other collection classes and of course final primitive fields and variables. In Java if you try to make an Object or array final you only make the reference final. The reference will only point to the same actual object but this does not make the underlying object immutable.

One advantage of immutable arrays would be not needing to create defensive copies because the array could be immutable anyway and could be trivially implemented in syntax:

final int[final] array = new int[final]{1, 2, 3, 4};

Is there a particular technical reason for allowing primitives and references to be made immutable but not arrays? What are the specific less obvious implications to immutable arrays that caused them to be left out of Java and why do they apply to arrays specifically but not primitives? What language or implementation features or mechanics are incompatible with immutable arrays and how so? What other parts of the language would not 'add up' if there were immutable primitive arrays?

Answer 1

Arrays are "special" in Java. They are not implemented as a class with constructor and members. Instead array creation and array operations (like reading and writing elements) are compiled directly into special-purpose bytecode instructions.

This means there is no way to override array behavior to create variants with different behavior. It is not that immutability in particular was left out, it is that arrays are designed to not support any kind of customization or parameterization beyond the element type.

This is for performance reasons. Arrays are the internal data structure behind all other collection types, so performance is critical. Any runtime overhead on element access, like calling a virtual method (or just checking a "mutable" flag on the instance) would have a significant impact across the board.

The way to customize array behavior is to create a wrapper class which encapsulate all access to the the array - and this is what the immutable containers like ImmutableList<E> does. Arrays have some other drawbacks (they are not fully type safe) which means generic collections should be preferred to working directly with arrays anyway.

Answer 2

An array can be immutable (final) just like anything else. That doesn't mean the elements it holds are immutable.

That's no different from Collections. Just because a Collection is immutable doesn't mean its constituent elements are immutable.

Answer 3

You're treating arrays as something separate from "primitives and references". That's your problem right now... arrays are references... they're a special kind of object, but fundamentally they're still just objects allocated off the heap.

So declaring them final has exactly the same effect as on any other object reference... i.e. the reference cannot be re-assigned, but like any other object, the object's mutability depends on the object.