Or not implement them at all since this is exactly what the Object class will do for you.
On Sunday, February 8, 2015, sebb <[email protected]> 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 <[email protected] > <javascript:;>> wrote: > > You aren't guaranteed for them not to collide. So, yes, it could happen. > > > > On Saturday, February 7, 2015, Michael Osipov <[email protected] > <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: [email protected] > <javascript:;> > >> For additional commands, e-mail: [email protected] > <javascript:;> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected] > <javascript:;> > >
