I was recently reading Java Concurrency in Practice and was exposed to the Collections.unmodifiableMap(...) method for the first time. The method creates a read-only wrapper around an existing Map and any attempts to modify the returned Map will (according to the Javadocs) result in an UnsupportedOperationException being thrown. Similar methods exist for other collection classes.
This made me quite concerned since an unmodifiableMap() still returns a Map, but does not support all relevant methods. The fact that it also throws exceptions on write operations means it cannot substitute a "proper" Map in most applications.
I am a student and am not yet confident in my ability to recognize design flaws, but aren't these violations of the Interface segregation and Liskov substitution principles, respectively?
The Map interface documents that implementations may choose not to support all of its methods, which makes Collections.unmodifiableMap return an implementation that satisfies the interface contract.
While it's unusual for an interface to make implementing its methods "optional" in this way, it's a design compromise that works just fine in practice. Most collections should be written only once and then read from again and again, so code that modifies a map is usually the code that created it and knows that it is mutable.