A DESCRIPTION OF THE REQUEST :
I can't for the life of me see why .class is allowed after a class name but not a reference. Instead you have to type the incantation myObject.getClass().

Here's an example I just came across:

public boolean equals(Object other) {	if (other.getClass() == Bananas.class) { // check it's not a subclass		// ...blah...}

How much clearer and more consistent if we could write:

if (other.class == Bananas.class) { // check it's not a subclass

In effect Object would be acknowledged as having the following field:
public final Class<? extends Object> class;

...just as arrays have the following field:

public final int length;

In fact the above code could be made even clearer and more portable, since you wouldn't have to name the current class (Bananas) directly:

if (other.class == this.class) { // check it's not a subclass


JUSTIFICATION :
This would be more consistent with the use of .class after a class name. It is not clear why the 'static' use of .class is allowed but not the 'non-static'.

It would also acknowledge, in the language, the existence of a 'field' which all moderately advanced developers are already aware of. Anybody, for instance, who uses reflection knows that an object has access to its own class. (Maybe anybody who uses 'virtual' methods or instanceof.)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
myRef.class should be equivalent to myRef.getClass() for any reference myRef.
this.class should also be allowed - see above example.
Possibly super.class could be supported, equivalent to this.class.getSuperclass(), but there might be arguments against it.

I am explicitly not proposing that java.lang.Class.getFields() simulates the existence of this class 'field'.

CUSTOMER SUBMITTED WORKAROUND :
Use Object.getClass().