Calling getClass on a variable of type Class

[cushon]

Original issue created by fixpoint@google.com on 2013-11-22 at 02:32 AM

---

Have just encountered an instance of this (some details changed):

@Provides boolean provideEligibility(Class<? extends Action> action) { return actionClass.getClass().getAnnotation(IsEligible.class) != null; }

Calling getClass() on a Class can be substituted with Class.class for practically all cases with an improvement of readability.

[cushon]

Original comment posted by fixpoint@google.com on 2013-11-22 at 02:34 AM

---

Sorry, a fragment from a fix creeped into the code. It was like this:

@Provides boolean provideEligibility(Class<? extends Action> action) { return action.getClass().getAnnotation(IsEligible.class) != null; }

[cushon]

Original comment posted by fixpoint@google.com on 2013-11-22 at 02:40 AM

---

Just to clarify: calling getClass() on an instance of Class is very likely a mistake, and if it's not, the Class.class would be a better way to express that anyway.

[cushon]

Original comment posted by cpovirk@google.com on 2013-11-25 at 08:54 PM

---

I see 48 instances in Google-internal code (CL 57244074 if you're curious).

• Most appear in the construction of error messages -- say, "Can't create proxy for type " + type.getClass(). (Admittedly some of these might lead to a very frustrating debugging session in which someone wonders how on earth he's passing Class.class to such a method.)
• About four of the remainder were Logger.getLogger calls.
• Another one documented that he wanted the class object for Class; apparently the writer didn't know about Class.class.
• Another really did want Class.class, but the code amounted to "writeType(foo.getClass()); write(foo); writeType(clazz.getClass()); write(clazz);" so it made sense to treat clazz.getClass() symmetrically to foo.getClass().
• The remaining third of the 48 look like "real" bugs.

I personally like the sound of this check a lot.