> On Feb 7, 2015, at 2:23 AM, Michael Osipov <1983-01...@gmx.net> wrote:
>
>> Am 2015-02-06 um 19:21 schrieb Phil Steitz:
>>> On 2/6/15 10:16 AM, sebb wrote:
>>> The existing Pool2 implementations use equals() to decide if two
>>> objects are the same.
>>
>> As of pool 2.3.
>>>
>>> You have to make sure that your equals() implementation returns true
>>> if and only if the objects being compared are the same as far as your
>>> use of them is concerned.
>>> So for example two Integers are equal if they have the same integral
>>> value, but two different StringBuffer instances are never equal.
>>>
>>> Once you have determined what constitutes equality for your instances,
>>> make sure that the hash code is coded accordingly, i.e. two objects
>>> that are equal() must have the same hash code.
>>> If this requirment is not met, then the HashMap used internally by
>>> Pool2 will behave unpredictably.
>>
>> Also, hash codes should not change between the time that an object
>> is borrowed from the pool and subsequently returned. Again, for
>> pool 2.0-2.3 (latest as of this post), objects under management by
>> the pool are kept in a hashmap keyed on the objects themselves, so
>> mutability that changes hashcodes (and / or equality) can cause
>> problems. See the discussion on POOL-284.
>
> If this causes so many discussions and fuzz, it is worth filing another issue
> which should document how a pooled object should like. Required criteria.
> That would have spared me the searching.
>
Definitely fixing javadoc and web site doco will be part of resolution of
POOL-283/4.
Phil
> WDYT?
>
> 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
