Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sat, 24 Aug 2013 20:08:53 +0000 (UTC)
From: "Allon Mureinik (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12518333.1312908472207.28499.1377374933367@arcas>
In-Reply-To: <JIRA.12518333.1312908472207@arcas>
References: <JIRA.12518333.1312908472207@arcas>
Subject: [jira] [Commented] (LANG-739) ToStringBuilder leaks memory if
 toString method causes hash code to be changed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LANG-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749458#comment-13749458 ] 

Allon Mureinik commented on LANG-739:
-------------------------------------

I am wondering if this is not a misuse of HashCodeBuilder.

Wouldn't the right usage be to define toString as transient and use the overloaded HashCodeBuilder.reflectionHashCode(this, false)?
                
> ToStringBuilder leaks memory if toString method causes hash code to be changed
> ------------------------------------------------------------------------------
>
>                 Key: LANG-739
>                 URL: https://issues.apache.org/jira/browse/LANG-739
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.builder.*
>    Affects Versions: 2.3
>            Reporter: Philippe Renon
>
> We have the following abstract class:
> {code}
> public class AbstractMessageItem {
>     private String toString;
>     public boolean equals(final Object obj) {
>         return EqualsBuilder.reflectionEquals(this, obj);
>     }
>     public int hashCode() {
>         return HashCodeBuilder.reflectionHashCode(this);
>     }
>     public String toString() {
>         if (toString == null) {
>             toString = ToStringBuilder.reflectionToString(this);
>         }
>         return toString;
>     }
> }
> {code}
> We also have two concrete classes extending the above class and one of them has a reference to the other.
> Now, if we call toString() on the 1st one, this will in turn call toString() on the second one.
> The call to toString() on the second one will cause its hash code to be changed and as a consequence will also change the hashCode of the first one *while* computing its toString().
> This causes the _infinite loop avoidance_ mechanism (i.e. the registry) to fail to unregister some objects and memory will be leaked.
> I believe that this leak can be avoided by using the system identity hash code when registering objects (as is done in HashCodeBuilder) instead of the user hash code.
> I know the issue can be worked around by removing the toString field (and loosing a dubious "performance enhancement" hack) or by making it transient, but I think that other "mutating" toString() methods can happen in the field (sometimes for good reasons) and fixing ToStringBuilder can be of help in some cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira