Hi Dale,
Dale Ellis wrote:
> I was having a look in the JConsole at the stack of the hanging thread, I
> think the issue is to do with my abstractEntity class (which all the JPA
> entity objects extend) overrides the hascode with this...
>
> public int hashCode() {
> if(getId() != null)
> {
> return new HashCodeBuilder().append(getId()).toHashCode();
> }
> else
> {
> return HashCodeBuilder.reflectionHashCode(this);
> }
>
> When I remove this, the fromXML() works
The reflectionHashCode is a *very* dangerous tool (I don't give a bad mouth
here, I am committer to Apache Commons Lang myself). In your case you might
even break the hashCode contract. The hashCode is meant to be a *constant*
unique identifier, i.e. if you use your object as key in a HashMap, the hash
value should never change afterwards. Is getId() a pure getter or will it
also access other complex objects in the graph to get one?
>From the XML structure I can see that some of your objects deep down in the
object graph contain back references to parents or siblings. A reflection-
based hash code builder will normally silently introduce an endless
recursion here - it just works, because the Apache implementation keeps
track of the accesses objects. However, this calculation is in any case
expensive.
BTW: Are you also sure you fullfill another hash code contract, i.e. equal
equal objects (calling equals()) means also equal hash codes (the reverse is
not guaranteed though)?
Apart from this, I still wonder, why TreeMap.putAll adds all elements
individually instead of using the optimized method that does not sort the
elements again and therefore omit all calls to compareTo ... :-/
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
