When should I use primitives instead of wrapping objects?

Question

Actually here is a similar topic with little practical value. As far as I understand, primitives perform better and should be used everywhere except for the cases where Object-related features (e.g. null check) are needed. Right?

Postulate

Answer 1

Do not forget that, since creating a new wrapper for every boxing occurrence is quite expensive, especially considering it usually being used at a single scope of a method, Autoboxing uses a pool of common wrappers.

This is in fact an implementation of the flyweight design pattern. When a boxing occurs for a well-known value, instead of creating a new wrapper instance, a pre-created instance is fetched from a pool and returned.

One consequence is: it’s still not recommended to use autoboxing for scientific calculations. For example, the code d = a * b + c is using Integer classes for a, b, c and d, and the generated code is d.valueOf(a.intValue() * b.intValue() + c.intValue()). All these method invocations have their own overhead, so it’s usually recommended to use autoboxing when needed to store primitives in collections.

And even then, if you have a huge collection of Integer wrapping int, the overhead can implies longer execution times, up to 20 times longer, as reported in this article.

---

Jb adds this important comment:

Also Wrapper.valueOf(primitive) uses pool of wrappers. So prefer Integer.valueOf(5) to new Integer(5)

Aubree

it’s still not recommended to use autoboxing for scientific calculations? Yes, it is for performance problem only, is not it? – Urba

@Urba not sure: I wrote that more than 6 years ago. – Aubree

Answer 2

Primitives are faster when they are used, as objects need to be unboxed before use; thus there is an extra step for the VM to perform. For example, In order perform arithmetic on an Integer, it must first be converted to an int before the arithmetic can be performed.

In many business applications this probably rarely matters. But if you were writing something very numnber-crunching heavy like, say, a graphics transformation processor you are a lot more likely to care.

Pashalik

Answer 3

yes, primitives are faster than objects. Since java 5 you can even mix primitives and objects without manually converting one to another. The autoboxing mechanism takes care of just that.

this means that if you put a primitive in a collection, the compiler will not complain, and convert the primitive to an object implicitly.

Ethnocentrism

In what cases are they faster? passing references around is just as fast as passing primitives around. – Photographic

take an int for example. An Integer, is a Object that contains a single int field. An Integer is much bulkier than an int. It is sort like a Fedex box to contain the int. – Ethnocentrism

Answer 4

I would say you should be worried about using primitives over wrappers only when you profile your application and see that the autoboxing is a performance or memory issue. In my experience memory becomes an issue before CPU cycles when talking about primitives vs wrapping objects.

Noelnoelani

I disagree. Why wait for performance to become a problem when you can write efficient code in the first place? 9 times out of 10 you don't need the extra functionality that the wrapper class offers, so why use one? – Placement

9 out of 10 times you never need to optimize. Most of the times you benefit from the autoboxing functionality otherwise why on earth would they have added it? There is no reason to make your life hard harder when you will never notice. – Noelnoelani

There are many features of the Java language that I require only occasionally. That's not to say that they are not useful or that they should not have been added. Autoboxing is a useful feature in certain circumstances, but I think it unnecessary to use wrappers just for the sake of having them. – Placement

It is a simple matter of making the code more readable. Worry about performance when you have a problem. – Noelnoelani

In most cases primitives are more readable i prefer if(editable) to if(editable.booleanValue()) and if(foo<0) to if(foo!=null && foo.intValue() < 0). – Immuno

jb, go back and look at what autoboxing is because what you are saying you don't like is something you don't have to do. – Noelnoelani

You're right, sorry. Syntactically theyre equal. But I had such experiences in pre 1.5 projects that I was working with last year. – Immuno

By your logic, why not store everything as a string? You can parse when you need to do math with a value. Then go to numeric data types if profiling shows its a bottleneck. int/long/double are in the language. It's crazy not to use them, except for cases like collection entries. – Advent

John you are missing the point. They are their to make the code better. Why on earth are you saying to pre-optimize code? There is absolutely nothing wrong with using the wrappers. – Noelnoelani

I don't consider using int instead of Integer to be pre-optimization. It's the way this C-derived language was meant to be written. I see Integer, Float, etc as workarounds for the cases where you need an object. Not the primary data types for numeric values. – Advent

You are still missing the point. If you start off with an Integer and then think "I should use an int here instead for performance" then you have pre-optimized. I said nothing about using them everywhere, I said not to worry about it until you can prove it as a problem. – Noelnoelani

Answer 5

If you need store primitives in collections you might use commons-primitives.

I prefer using primitives to wrappers, only place that absolutely needs to have wrappers are entity classes. Databases support nulls, so entities should too.

I once worked on project that used primitives (and homebrew ORM) in database access:

 class Foo{
    int xxx = -1;
 ...
 }

And then you had:

 void persist(Foo foo){
     ...
     statement.setInt(15,foo.getXXX()==-1?null:foo.getXXX());
     ...
}

God it was evil.

Immuno