I was thinking that, instead of using a simple integer tag for each POJO in a Set, that you could incorporate the hash code (or part of it) along with a counter for objects that happened to have the same hash code, but not equal. For example, the Set.contains() method could be written as: | public boolean contains(Object o) | { | int hash = o.hashCode(); | Collection<Object> children = node.getChildrenNames(); | for (int i = 0; i < children.size(); i++) { | Long key = new Long((long)hash | ((long)i << 32)); | Object o2 = ...get(key); | if (o2 == null) | return false; | if (o.equals(o2)) | return true; | } | return false; | } | Worst-case performance is O(N), best is O(1). Set.remove() would mean more complication; you'd have to actually shift entries around to fix gaps, if there were any. I could contribute this as a patch if it made sense. One thing I wonder though is, does it hurt to use Integer in an FQN instead of a String? I didn't see any problems during tests... Long.toString() would be fine I guess but less efficient. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3982872#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...