On 8 February 2015 at 15:09, James Carman <ja...@carmanconsulting.com> wrote: > Or not implement them at all since this is exactly what the Object class > will do for you.
Yes, that is true for the sample RawSession class shown at the start of the thread. However if the class were changed to inherit from a class that overrides equals/hasCode then it would need to re-define the methods in order to get the same behaviour. > On Sunday, February 8, 2015, sebb <seb...@gmail.com> wrote: > >> 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 >> >> >> On 8 February 2015 at 12:12, James Carman <ja...@carmanconsulting.com >> <javascript:;>> wrote: >> > You aren't guaranteed for them not to collide. So, yes, it could happen. >> > >> > On Saturday, February 7, 2015, Michael Osipov <1983-01...@gmx.net >> <javascript:;>> wrote: >> > >> >> Am 2015-02-06 um 17:14 schrieb James Carman: >> >> >> >>> Try UUID.randomUUID().toString() rather than RandomStringUtils if you >> >>> really want unique keys. >> >>> >> >> >> >> Aren't both pseudo random? >> >> >> >> I won't have more than 30 sessions in parallel. Do you think that a >> >> collision might happen? >> >> >> >> Michael >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> <javascript:;> >> >> For additional commands, e-mail: user-h...@commons.apache.org >> <javascript:;> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org <javascript:;> >> For additional commands, e-mail: user-h...@commons.apache.org >> <javascript:;> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org