The corollary is that if you can't provide a valid (and sufficiently efficient for your purposes) implementation for an abstract method in AbstractMap, then you should NOT be extending AbstractMap. Rather you should be implementing the Map interface from scratch.
It doesn't matter whether I inherit from AbstractMap or not - I am, in fact, but it's irrelevant to the discussion at hand, because the code that's causing a problem is in HashMap, not AbstractMap, and it applies when a Map of my type is passed to putAll() on a HashMap.
The problem is that, while I could implement the size() method correctly on my Map type, it would be very slow, and hence all the algorithms which "optimize" by using size() instead of hasNext()* are pessimizations instead. And performance is important for my usage.
Stuart.
* Does anyone actually have a single example of a case where hasNext() is slow? Seems to me that it can never be significantly slower than size() because if it were, it could be implemented as "return counter < size()".
-- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath