>Do you have hard numbers for that claim? Are these checks used on a hot path? Just curious.
I can claim without any numbers that code instantiating objects and doing reflection operations will be slower than the code which just compares the object fields. And yes, this code is on the hot path. ASTMethod calls it during template merge. I think everybody wants his template to merge quicker.
> equals should at least do a if (o == this) return true; check. This short cuts the equals() method in case you test against yourself (set insert e.g.)
This object is never compared to itself. One first object is used as a key in the HashMap and new objects are instantiated every time to find the cached value.
> I'd love to have unit tests for hashCode() and equals().
This class was in code base before my changes. How it comes it was added without unit tests? Just curious.
To be serious: It is inner class with package visibility. What package should the unit tests be in?
> There is a potential NPE with params == null in hashCode() and equals()
This object is never instantiated with params == null. I'd rather add "assert params != null" to the code (if 1.4 syntax is allowed in codebase).