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

Reply via email to