Why not break it into two interfaces? One for immutable and one with the mutable operations so that this is naturally expressible and checked by the type system?
Not every solution to every problem is worth it. Sometimes it's best to do nothing and spend the time on more worthwhile things, and perhaps a cheaper solution would present itself in the future.
And it’s been an issue since forever, and this is specifically introducing new super-interfaces, so why miss the opportunity again?
2. People are never going to migrate from List, and so we:
3. Must do the same exact thing again and again, to ensure:
4. That people are never going to migrate from List
> Add, put, and UnsupportedOperationException
At some point you have to stop playing with types and start coding.
Parent comment is right: throwing an exception is surprising behavior and the interface’s design breaks the Liskov substitution principle.
To tell mutable and immutable collections apart, you just need two separate interfaces, a feature available in Java for decades, and an approach widely and routinely used everywhere in the language.
Part of the problem might be that Java's existing interfaces for collections don't have that split. `List`, `Set`, and `Map` already declare mutators, and they're used pervasively.
On the other hand, the Java folks clearly recognize that mutability is the wrong default for modern programming languages, so why double down on the mistakes of the past? They might argue that it makes more sense to follow established patterns than it does to create new ones, because it creates less friction for Java developers.