Unsupported operations

Unsupported operations

It's possible to turn an array into a List with the static Arrays.toList( ) method:

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. You'll learn all about exceptions in the next chapter, but the short story is that the Collection interface, as well as some of the other interfaces in the new collections 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, 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 collection 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 new collections library: it is simple to learn and use. 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 new collections 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 Collection interface, 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 a class 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.

In the example above, Arrays.toList( ) produces a List that is backed by a fixed-size array. Therefore it makes sense that the only supported operations are the ones that don't change the size of the array. If, on the other hand, a new interface were required to express this different kind of behavior (called, perhaps, "FixedSizeList"), it would throw open the door to complexity and soon you wouldn't know where to start when trying to use the library.

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( ).