Differencebetween Integer and Int in Java

What is the difference between Integer and int in Java?

int is a primitive type. Variables of type int store the actual binary value for the integer you want to represent. int.parseInt("1") doesn't make sense because int is not a class and therefore doesn't have any methods.

Integer is a class, no different from any other in the Java language. Variables of type Integer store references to Integer objects, just as with any other reference (object) type. Integer.parseInt("1") is a call to the static method parseInt from class Integer (note that this method actually returns an int and not an Integer).

To be more specific, Integer is a class with a single field of type int. This class is used where you need an int to be treated like any other object, such as in generic types or situations where you need nullability.

Note that every primitive type in Java has an equivalent wrapper class:

• byte has Byte
• short has Short
• int has Integer
• long has Long
• boolean has Boolean
• char has Character
• float has Float
• double has Double

Wrapper classes inherit from Object class, and primitive don't. So it can be used in collections with Object reference or with Generics.

Since java 5 we have autoboxing, and the conversion between primitive and wrapper class is done automatically. Beware, however, as this can introduce subtle bugs and performance problems; being explicit about conversions never hurts.

What is the difference between an int and an Integer in Java and C#?

In Java, the 'int' type is a primitive, whereas the 'Integer' type is an object.

In C#, the 'int' type is the same as System.Int32 and is a value type (ie more like the java 'int'). An integer (just like any other value types) can be boxed ("wrapped") into an object.

---

The differences between objects and primitives are somewhat beyond the scope of this question, but to summarize:

Objects provide facilities for polymorphism, are passed by reference (or more accurately have references passed by value), and are allocated from the heap. Conversely, primitives are immutable types that are passed by value and are often allocated from the stack.

int[] and Integer[] arrays - What is the difference?

There is a difference at run-time.

int[] is an array of primitive int values. Integer[] is an "object" array, holding references to Integer objects.

Most important practical difference: int[] cannot hold null values.

But I'm still confused: does int[] store just a primitive values? If so - doesn't it mean that primitive types can live on heap without being wrapped?

int[] does store primitive types. And the array itself lives on the heap. However, those primitives are allocated as part of the array. They are not stored separately elsewhere on the heap. This is very similar to how a primitive field is part of an object instance: The object is on the heap, and its field is an integral part of that object (whereas for a non-primitive field, only the reference is stored inside the object and the target instance that reference points at is stored separately on the heap).

You could say the int is "wrapped" inside the array.

Difference between 'int' and 'Integer' types

int is primitive data type where is Integer is a wrapper class (an Object).

If you need an object then Integer comes into picture and other int you know it already.

All the Collection class accepts only object in that case you can't use simple int primitive data type.

An int is a primitive. It is not an Object. An int is a high performance, streamlined beast for calculating numbers.

An Integer, is an Object that contains a single int field. An Integer is much bulkier than an int. It is sort like a box to contain the int.

For more info look at Primitive Data Types and Primitive wrapper class

Which one to use, int or Integer

Integer is a better option, as it can handle null; for int, null would become 0, silently, if resultSet.getInt(..) is used. Otherwise, it might throw some exception, something like, "Unable to set null to a primitive property".

Performance is of little concern here.

• if you choose int, you will end-up adding extra handling code; and that wouldn't benefit you much. Your code will not be clean and straight-forward, lot of boiler-plate code, and you wouldn't even gain performance.
• let me make it clear, for databases, null is not same as zero. Sometimes you end-up entering 0, where null was intended. Imagine the case where user submitted a form, and doesn't supply any value for int. You will end up getting 0 by default. It makes sense, or does that really, when that field is not null in the database.

int vs Integer comparison Java

i1 == i2

results in un-boxing and a regular int comparison is done. (see first point in JLS 5.6.2)

i2 == i3 

results in reference comparsion. Remember, i2 and i3 are two different objects. (see JLS 15.21.3)

int or Integer in java

You always use int, pretty much.

Integer should rarely be used; it is an intermediate type that the compiler takes care of for you. The one place where Integer is likely to appear is in generics, as int is simply not legal there. Here is an example:

List<Integer> indices = new ArrayList<Integer>();
int v = 10;
indices.add(v);

The above works: It compiles with no errors and does what you think it would (it adds '10' to a list of integer values).

Note that v is of type int, not Integer. That's the correct usage; you could write Integer here and the code works as well, but it wouldn't be particularly idiomatic java. Integer has no advantages over int, only disadvantages; the only time you'd use it, is if int is straight up illegal. Which is why I wrote List<Integer> and not List<int> as the latter is not legal java code (yet - give it a few versions and it may well be legal then, see Project Valhalla).

Note also that the compiler is silently converting your v here; if you look at the compiled code it is as if javac compiled indices.add(Integer.valueOf(v)) here. But that's fine, let the compiler do its thing. As a rule what the compiler emits and what hotspot optimizes are aligned; trust that what javac emits will be relatively efficient given the situation.

---

Related Topics