This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The API for Map.Entry states: "These Map.Entry objects are valid only for the duration of the iteration; more formally, the behavior of a map entry is undefined if the backing map has been modified after the entry was returned by the iterator, except through the iterator's own remove operation, or through the setValue operation on a map entry returned by the iterator." But I haven't been able to reproduce any invalid behaviour in this program:
As you can see the pair is perfectly funtional after a modification of the map. Yes the iterator is fail-fast. I also tried with the remove method in the commented line and with a HasMap and the results were identical. Is the API guarging against future implementations or the invalidation of a Map.Entry object requires more hard work to be seen?
Something is undefined, which means it can do whatever, but don't count on it. Don't count that it does something wrong nor correct. This is a very important concepts: "Never use any undocumented feature, even you like it." It will be back to bite you at any time, and you cannot complain on it, since it told you so. SCJD Study Group has been moved to http://www.developergroup.org/ [This message has been edited by Roseanne Zhang (edited September 21, 2001).]
The API never says what exactly should happen to the Map.Entry if the underlying Map is altered. So just about any behavior is OK as far as the API is concerned. The fact that the Map.Entry is no longer "valid" doesn't mean that it's impossible to use - it means that you can't trust the results you get. Different implementations of Map may do different things. To see this run the following program, and see how HashMap and TreeMap react differently. <pre>import java.util.*;