Youll discover that only a portion of the Collection and List interfaces are actually implemented. The rest of the methods cause the unwelcome appearance of something called an UnsupportedOperationException. The Collectioninterfaceas well as some of the other interfaces in the Java containers librarycontain optional methods, which might or might not be supported in the concrete class that implements that interface. Calling an unsupported method causes an UnsupportedOperationException to indicate a programming error.

What?!? you say, incredulous. The whole point of interfaces and base classes is that they promise these methods will do something meaningful! This breaks that promise; it says that not only will calling some methods not perform a meaningful behavior, but they will stop the program! Type safety was just thrown out the window!

Its not quite that bad. With a Collection, List, Set, or Map, the compiler still restricts you to calling only the methods in that interface, so its not like Smalltalk (in which you can call any method for any object, and find out only when you run the program whether your call does anything). In addition, most methods that take a Collection as an argument only read from that Collectionall the read methods of Collection are not optional.

This approach prevents an explosion of interfaces in the design. Other designs for container libraries always seem to end up with a confusing plethora of interfaces to describe each of the variations on the main theme, and are thus difficult to learn. Its not even possible to capture all of the special cases in interfaces, because someone can always invent a new interface. The unsupported operation approach achieves an important goal of the Java containers library: The containers are simple to learn and use; unsupported operations are a special case that can be learned later. For this approach to work, however:

The UnsupportedOperationException must be a rare event. That is, for
most classes all operations should work, and only in special cases should an
operation be unsupported. This is true in the Java containers library, since the
classes youll use 99 percent of the timeArrayList,
LinkedList, HashSet, and HashMap, as well as the other
concrete implementationssupport all of the operations. The design does
provide a back door if you want to create a new Collection
without providing meaningful definitions for all the methods in the
Collectioninterface, and yet still fit it into the existing
library.

When an operation is unsupported, there should be reasonable
likelihood that an UnsupportedOperationException will appear at
implementation time, rather than after youve shipped the product to the
customer. After all, it indicates a programming error: Youve used an
implementation incorrectly. This point is less certain and is where the
experimental nature of this design comes into play. Only over time will we find
out how well it works.

Note that you can always pass the result of Arrays.asList( ) as a constructor argument to a List or Set in order to create a regular container that allows the use of all the methods.

The documentation for a method that takes a Collection, List, Set, or Map as an argument should specify which of the optional methods must be implemented. For example, sorting requires the set( ) and Iterator.set( ) methods, but not add( ) and remove( ).