Fqn hashCode() method

[bdueck]

After a quick scan of the Fqn implementation, I noticed that the hashCode() method doesn't use a cached implementation technique.

Is this done intentionally to allow the underlying objects that make up the Fqn instance to change their hash codes? I can see why this might be required to keep the contract with equals(). Or, is there some room for optimization here by caching the hash code of the Fqn and invaliding the cache when it changes?

Mind you it's not like I've put the code through a profiler or anything, but seemed to me like Fqn.hashCode() would probably get pretty hard, especially in a deeply nested tree structure (which is my case).

Regards,

Brian Dueck

[belaban]

It's because I haven't thought of caching the result :-)

If you can show me that a cached version improves performance (and send me the patch), I'll apply it.

[bdueck]

Bela;

I'll set-up a little test app to verify my hash code caching theory, and report the results back in a few days.

Brian.