Hi Louis, hanks! I thought I had seen it somewhere but I couldn't recall where. That's exactly what I need to answer the guys who asked me for a doc reference.
Thanks, Kris On Friday, July 17, 2015, Louis Wasserman <[email protected]> wrote: > The Javadoc of Map already specifies: > > > Note: great care must be exercised if mutable objects are used as map > keys. The behavior of a map is not specified if the value of an object is > changed in a manner that affects equals comparisons while the object is a > key in the map. *A special case of this prohibition is that it is not > permissible for a map to contain itself as a key. While it is permissible > for a map to contain itself as a value, extreme caution is advised: the > **equals and hashCode methods > are no longer well defined on such a map.* > > (emphasis added) > > On Fri, Jul 17, 2015 at 12:11 PM Krystal Mok <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi Vitaly, >> >> I can buy that argument. It wasn't hard for me to recognize it when I saw >> it in real world. >> >> But apparently whoever asked me about it couldn't wrap his head around it >> to understand why... >> >> Maybe it's a case for a Pitfalls book instead of for JavaDocs. >> >> Thanks, >> Kris >> >> On Friday, July 17, 2015, Vitaly Davidovich <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> <javascript:_e(%7B%7D,'cvml','[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>');>> wrote: >> >> > IMHO, this doesn't warrant any special wording -- if someone hits this, >> I >> > think it's fairly evident what the issue is. You can get the same >> problem >> > with adding an ArrayList to itself and calling hashCode(). >> > >> > On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> >> > wrote: >> > >> >> Hi everyone, >> >> >> >> I'm sure somebody has seen this stack overflow before. My question is: >> is >> >> it expected (which should be documented to warn people not to do >> this), or >> >> is it considered a bug (which should be fixed)? >> >> >> >> Example: >> >> https://gist.github.com/rednaxelafx/930f8979473185cfc0a0 >> >> >> >> import java.util.*; >> >> >> >> public class HashMapStackOverflow { >> >> public static void main(String[] args) throws Exception { >> >> HashMap<String, Object> map = new HashMap<>(); >> >> map.put("self", map); >> >> System.out.println(map.hashCode()); >> >> } >> >> } >> >> >> >> $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow >> >> Exception in thread "main" java.lang.StackOverflowError >> >> at java.util.AbstractMap.hashCode(AbstractMap.java:505) >> >> at java.util.Objects.hashCode(Objects.java:98) >> >> at java.util.HashMap$Node.hashCode(HashMap.java:296) >> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507) >> >> at java.util.Objects.hashCode(Objects.java:98) >> >> at java.util.HashMap$Node.hashCode(HashMap.java:296) >> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507) >> >> at java.util.Objects.hashCode(Objects.java:98) >> >> at java.util.HashMap$Node.hashCode(HashMap.java:296) >> >> at java.util.AbstractMap.hashCode(AbstractMap.java:507) >> >> ... >> >> >> >> This will cause a stack overflow because HashMap.hashCode() is >> inherited >> >> from AbstractMap, which sums the hash code of each entry, while one of >> the >> >> entries is itself so it goes recursive. >> >> >> >> Thanks, >> >> Kris >> >> >> > >> > >> >
