How to meaningfully define hashCode and equals for a java.lang.Class<T>?

Question

If one needs to use a Class<T> as part of a key of a Map what is the proper way to define the hashCode and equals?
A Class<T> inherits the ones from Object which check for reference equality and return the memory address as the hashcode but in my mind it is not clear what is the meaningful definition of equals and hashCode definition of a Class<T>.
Should I use theClass.getClass().hashCode(); for example (where we have Class<T> theClass;) to use the actual instance's methods?
But this does not seem to be the correct thing to do.
For example in the javadoc for Class<T>:

Every array also belongs to a class that is reflected as a Class object that is shared by all arrays with the same element type and number of dimensions

So it seems in some cases the same Class<T> is shared among objects? So what would be the way to follow? Perhaps use theClass.hashCode() and theClass.equals() to use reference equality? Not sure at all here.

Answer 1

The implementation of hashCode and equals java.lang.Class inherits from java.lang.Object is meaningful and usually appropriate, as all instances of a class are guaranteed to return the same Class object from getClass(), i.e.

new Integer(2).getClass() == new Integer(3).getClass();

This is somewhat buried in the docs; the javadoc of getClass() writes:

Returns:

The Class object that represents the runtime class of this object.

See Also:

Literals, section 15.8.2 of The Java™ Language Specification.

That section writes:

A class literal evaluates to the Class object for the named type (or for void) as defined by the defining class loader (§12.2) of the class of the current instance.

and section 12.2 writes:

Well-behaved class loaders maintain these properties:

• Given the same name, a good class loader should always return the same class object.
• ...

A malicious class loader could violate these properties. However, it could not undermine the security of the type system, because the Java virtual machine guards against this.

And yes, if the same class definition is loaded by different class loaders, the class objects will not be equal. As the runtime treats these as independent classes (who just happen to share the same name, but need not otherwise be similar, let alone binary compatible), this is usually desired.