This is to some degree intentional since those ReflectionUtils methods implement strict signature checks (including parameter types) whereas the proxy-internal checks make simplified assumptions and just compare the method name if no same-named overloaded methods are to be expected. From that perspective, it seems sensible to retain the current simple checks in those places; I have yet to review whether the stricter checks might be applicable for certain code paths there.

Oh, I see. I can then revert illegal changes and keep at least those in ReflectionUtils as comparison of int is likely to be faster than call to Object.equals()

Damn, it seems I've force-pushed another branch into it... I'll rename PR then according to its purpose.

Here I've noticed that in numerous cases ClassUtils.toClassArray() is called with empty collection resulting in garbage Class[] allocations. This can be dodged in the similar way as we do in StringUtils.toStringArray()

I'm applying a part of this for 5.2.5 still, namely a private EMPTY_CLASS_ARRAY constant that we're using in toClassArray, aligning it with the recent revision of StringUtils.toStringArray in the 5.2 line.

As for the code in ExtendedEntityManagerCreator, I'd rather prefer to keep it aligned with the multi-interface case below. Also, since ClassUtils.hasConstructor would require a new public method and isn't really used in a common hot code path, I'd rather keep the regular version only.

Thanks for the extensive pull request, in any case!