On 8 February 2015 at 20:38, Michael Osipov <1983-01...@gmx.net> wrote: > Am 2015-02-08 um 14:34 schrieb sebb: >> >> Why don't you just implement equals() and hashCode() as noted here [1] ? >> >> This will allow the use of Pool2 and guarantee that different >> instances are treated as different, regardless of mutabiity. >> >> No need to generate unique ids for each instance. >> >> Pool2 needs an equals() method that returns true for objects that >> really are equal. >> >> Also equals() and hashCode() must be stable for a given object, and >> objects which are the same under equals() must have the same >> hashCode(). >> >> These are standard requirements for using a HashMap (which is what >> Pool2 uses currently). >> >> [1] >> https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 > > > The offered solution adds another superfluous wrapper which can be avoided.
I did not mean to imply that you needed to use a wrapper. Since you have control over the class, you can just write the equals()/hashCode() methods as per the wrapper. Or omit them entirely if the class inherits its equals()/hashCode() methods from Object. > the artificial id helps here. I don't see how. It's not needed by Pool2 if you use the Object EQ/HC methods either by inheritance or by definition in the class. > > Michael > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
