On 16/09/2008, Jörg Schaible <[EMAIL PROTECTED]> wrote: > Hi Simon, > > Simon Kitching wrote: > [snip] > > > One other concern is regarding garbage collection. From a > > brief look at > > the code, this thread-local registry object contains a set of Integer > > hashcodes. With this change, the set will now contain real hard > > references to objects, preventing them from being garbage-collected > > while they are in the set. Does this matter? > > > Good catch. I am quite sure this will matter, unfortunately. > HashCodeBuilder.reflectionHashCode(Object) is widely used and if a new lang > version suddenly keeps those values, we might prevent redeployments that > worked so far and causing memory leaks. Using a WeakReference instead? We're > getting slow :-/ > > - Jörg > > BTW: The current implementation of > HashCodeBuilder.reflectionHashCode(Object) is not wrong, its the class > implementation that uses EqualsBuilder.reflectionEquals(o, this) together > with it.
I disagree: the current implementation assumes that it can uniquely map objects to Integers. This assumption does not depend on the definition of equals. > We might therefore also create a new method > HashCodeBuilder.reflectionHashCodeRespectingEquals(Object) ... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
