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.

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.

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.