[concurrency-interest] Reference/IdentityMap toString

Gregg Wonderly gregg at cytetech.com
Mon Aug 23 10:10:24 EDT 2010


Tim Peierls wrote:
> On Fri, Aug 20, 2010 at 2:08 PM, Jason Mehrens 
> <jason_mehrens at hotmail.com <mailto:jason_mehrens at hotmail.com>> wrote:
> 
>     [Tim wrote:] While bijectivity is an attractive property for a
>     string representation function, it's not something anyone should
>     depend on.
>      
>     [Jason wrote:] Agreed.  A key toString implementation lacking
>     sufficient detail could cause AbstractMap.toString to lose that
>     property (at no fault of the map).
> 
> 
> I meant that because no one should be depending on toString being 
> bijective, there's not much point in striving for bijectivity in 
> toString implementations in the first place. So I don't think 
> AbstractMap.toString() can be fairly described as "broken", even for 
> identity maps.
> 
> As others have mentioned, if you have a specific need to preserve a 
> key's identity in a string representation -- e.g., debugging, logging -- 
> there are several approaches one could use that don't involve 
> complicating AbstractMap.toString.

I am not sure I understand the opposing views in this conversation, but I will 
say that more often then not, I do use object instance toString() variations so 
that I can see how many new instances of something are appearing within logging 
or debugging messages to the console.  I often do have things like

public String toString() {
	return prettyToString()+
		(logger.isLoggable( Level.FINE ) ? (":"+hashCode()) : "");
}

or some such on Object subclasses to do this.  This makes it trivial to see this 
kind of information when I need it, but for it to not be visible otherwise.

Gregg Wonderly


More information about the Concurrency-interest mailing list