Why don 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). Doug Lea, who wrote a popular Java collections package that did reflect mutability distinctions in its interface hierarchy, no longer believes it is a viable approach, based on user experience with his collections package. In his words (from personal correspondence) “Much as it pains me to say it, strong static typing does not work for collection interfaces in Java.” … When all was said and done, we felt that it was a sound engineering compromise to sidestep the whole [exploding interfaces] issue by providing a very small set of core interfaces that can throw a runti
Related Questions
- Why don you support immutability directly in the core collection interfaces so that you can do away with optional operations (and UnsupportedOperationException)?
- Would operations that directly support labs, such as machine shops, housekeeping, or building support be included under Subpart K?
- Can I directly pass on notification to the User Support Cell of my RVSM Operations approvals?
