2

What is the difference between Integer.class, int.class and Integer.TYPE? I am kind of confused between the three.

Birendra
  • 121
  • 9

1 Answers1

6

Whether i is an int or an Integer:

  • Integer.class.isInstance(i) returns true
  • int.class.isInstance(i) returns false
  • Integer.TYPE.isInstance(i) returns false

Let's understand isInstance.

public boolean isInstance(Object obj)

Determines if the specified Object is assignment-compatible with the object represented by this Class.

It takes an Object as an argument, not a primitive type. Any int passed in will be boxed as an Integer so it can be passed to the method.

Integer.class is a class literal, and used with a reference type, that is a reference to the Class object for that class.

The Integer object that this method sees certainly is an instance of the Integer class, so Integer.class.isInstance(i) returns true.

However, int.class and Integer.TYPE each represent the int primitive type, not the Integer class, and an Integer is not an int, despite the fact that Java usually uses them interchangeably, due to boxing and unboxing. This explains the two false outputs from int.class.isInstance(i) and Integer.TYPE.isInstance(i).

Class literal history

According to the Javadocs for Integer, Integer.TYPE has been around since version 1.1.

But class literals have also been around since 1.1.

Java APIs which require class objects as method arguments are much easier to use when the class literal syntax is available.

The class literals made it tremendously easier to use reflection, which was also new in Java 1.1.

It is unclear why Integer.TYPE exists if int.class represents the int primitive type consistently with reference class literals. They are equivalent and == yields true when comparing them.

Community
  • 1
  • 1
rgettman
  • 176,041
  • 30
  • 275
  • 357
  • Thanks for the explanation. What is the use of int.class if we cannot get it by calling on an int variable. And i have read somewhere that Integer.TYPE defines the Class object for the wrapper classes of primitives. Then for wrapper Integer it should be Integer.TYPE. What is Integer.class then? – Birendra Sep 16 '15 at 17:08
  • 2
    @Birendra - First, note that `int.class == Integer.TYPE`. They are the same object. Second, `int.class` (or `Integer.TYPE`) is useful when dealing with reflection. Several methods of `Class` expect as arguments the `Class` objects representing the types of the arguments to constructors or methods. When the argument is an `int`, then `int.class` (or `Integer.TYPE`) is used to represent that argument. Finally, `Integer.class` represents the class of objects that are instances of `Integer` (not primitive `int` values). – Ted Hopp Sep 16 '15 at 17:23
  • maybe they couldn't make up their mind. `int.class` does look odd; not to mention `void.class` – ZhongYu Sep 16 '15 at 17:45
  • @Ted Hopp I was reading "Thinking in Java" where the author said that int.class is for the primitive type and Integer.TYPE is for the primitive wrapper type. – Birendra Sep 17 '15 at 05:26
  • 2
    @Birendra - I'm not sure why the author would say that. Perhaps he was mislead by the type of `Integer.TYPE` being `Class`. The [docs](https://docs.oracle.com/javase/8/docs/api/java/lang/Integer.html#TYPE) clearly say that `Integer.TYPE` is _"The `Class` instance representing the primitive type `int`."_. It is easy enough to write a program to test this: `int.class == Integer.TYPE` will be `true`; `i.getClass() == Integer.class` will be `true` for any `Integer` variable `i`; `Integer.class == Integer.TYPE` will be `false`. Also, `Integer.TYPE.isPrimitive()` will return `true`. – Ted Hopp Sep 17 '15 at 06:02
  • @Ted Hopp This is the reason i was confused in the first place. That is why i put this question in the first place. Thanks any way for helping me understand. – Birendra Sep 17 '15 at 06:08