Why do people still use primitive types in Java?

Question

Since Java 5, we\'ve had boxing/unboxing of primitive types so that int is wrapped to be java.lang.Integer, and so and and so forth.

I see

Answer 1

In Joshua Bloch's Effective Java, Item 5: "Avoid creating unnecessary objects", he posts the following code example:

public static void main(String[] args) {
    Long sum = 0L; // uses Long, not long
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

and it takes 43 seconds to run. Taking the Long into the primitive brings it down to 6.8 seconds... If that's any indication why we use primitives.

The lack of native value equality is also a concern (.equals() is fairly verbose compared to ==)

for biziclop:

class Biziclop {

    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5));
        System.out.println(new Integer(500) == new Integer(500));

        System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
    }
}

Results in:

false
false
true
false

_^EDIT Why does (3) return true and (4) return false?

Because they are two different objects. The 256 integers closest to zero [-128; 127] are cached by the JVM, so they return the same object for those. Beyond that range, though, they aren't cached, so a new object is created. To make things more complicated, the JLS demands that at least 256 flyweights be cached. JVM implementers may add more if they desire, meaning this could run on a system where the nearest 1024 are cached and all of them return true... #awkward

Answer 2

Couple of reasons not to get rid of primitives:

• Backwards compatability.

If it's eliminated, any old programs wouldn't even run.

• JVM rewrite.

The entire JVM would have to be rewritten to support this new thing.

• Larger memory footprint.

You'd need to store the value and the reference, which uses more memory. If you have a huge array of bytes, using byte's is significantly smaller than using Byte's.

• Null pointer issues.

Declaring int i then doing stuff with i would result in no issues, but declaring Integer i and then doing the same would result in an NPE.

• Equality issues.

Consider this code:

Integer i1 = 5;
Integer i2 = 5;

i1 == i2; // Currently would be false.

Would be false. Operators would have to be overloaded, and that would result in a major rewrite of stuff.

• Slow

Object wrappers are significantly slower than their primitive counterparts.

Answer 3

First and foremost, habit. If you've coded in Java for eight years, you accumulate a considerable amount of inertia. Why change if there is no compelling reason to do so? It's not as if using boxed primitives comes with any extra advantages.

The other reason is to assert that null is not a valid option. It would be pointless and misleading to declare the sum of two numbers or a loop variable as Integer.

There's the performance aspect of it too, while the performance difference isn't critical in many cases (though when it is, it's pretty bad), nobody likes to write code that could be written just as easily in a faster way we're already used to.

Answer 4

In addition to what others have said, primitive local variables are not allocated from the heap, but instead on the stack. But objects are allocated from the heap and thus have to be garbage collected.

Answer 5

Primitive types:

int x = 1000;
int y = 1000;

Now evaluate:

x == y

It's true. Hardly surprising. Now try the boxed types:

Integer x = 1000;
Integer y = 1000;

Now evaluate:

x == y

It's false. Probably. Depends on the runtime. Is that reason enough?

Answer 6

I agree with previous answers, using primitives wrapper objects can be expensive. But, if performance is not critical in your application, you avoid overflows when using objects. For example:

long bigNumber = Integer.MAX_VALUE + 2;

The value of bigNumber is -2147483647, and you would expect it to be 2147483649. It's a bug in the code that would be fixed by doing:

long bigNumber = Integer.MAX_VALUE + 2l; // note that '2' is a long now (it is '2L').

And bigNumber would be 2147483649. These kind of bugs sometimes are easy to be missed and can lead to unknown behavior or vulnerabilities (see CWE-190).

If you use wrapper objects, the equivalent code won't compile.

Long bigNumber = Integer.MAX_VALUE + 2; // Not compiling

So it's easier to stop these kind of issues by using primitives wrapper objects.

Your question is so answered already, that I reply just to add a little bit more information not mentioned before.