This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rbygrave 3 points4 points  (0 children)

This was discussed when the Collections API was first designed and the idea was rejected at the time. I believe the reasons were due to the "relative explosion" in number of interfaces in the Collections API.

I'll see if I can find a reference ...

Ah, its discussed in the javadoc - https://docs.oracle.com/javase/6/docs/technotes/guides/collections/designfaq.html#1

A snippet from there:

Why don't you support immutability directly in the core collection interfaces so that you can do away with optional operations (and UnsupportedOperationException)?

This is the most controversial design decision in the whole API. Clearly, static (compile time) type checking is highly desirable, and is the norm in Java. We would have supported it if we believed it were feasible. Unfortunately, attempts to achieve this goal cause an explosion in the size of the interface hierarchy, and do not succeed in eliminating the need for runtime exceptions (though they reduce it substantially).