Integer.class vs int.class

Solution 1:

Integer.class is, as you say, a reference to the Class object for the Integer type.

int.class is, similarity, a reference to the Class object for the int type. You're right that this doesn't sound right; the primitives all have a Class object as a special case. It's useful for reflection, if you want to tell the difference between foo(Integer value) and foo(int value).

Integer.TYPE (not Integer.type, mind you) is just a shortcut for int.class.

You can get a sense of this with a simple program:

public class IntClasses {
  public static void main(String[] args) {
    Class<Integer> a = int.class;
    Class<Integer> b = Integer.TYPE;
    Class<Integer> c = Integer.class;

    System.out.println(System.identityHashCode(a));
    System.out.println(System.identityHashCode(b));
    System.out.println(System.identityHashCode(c));
  }
}

Example output (it'll be different each time, but the first two will always be the same, and the third will virtually always be different):

366712642
366712642
1829164700

Solution 2:

From java.lang.Class.isPrimitive API

There are nine predefined Class objects to represent the eight primitive types and void. These are created by the Java Virtual Machine, and have the same names as the primitive types that they represent, namely boolean, byte, char, short, int, long, float, and double.

These objects may only be accessed via the following public static final variables java.lang.Boolean.TYPE, java.lang.Integer.TYPE etc