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?

  • 1
  • 1
  • 56,576
  • 33
  • 147
  • 165

5 Answers5


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)

Keshaw Kumar
  • 317
  • 1
  • 4
  • 15
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • it’s still not recommended to use autoboxing for scientific calculations? Yes, it is for performance problem only, is not it? – grep Mar 08 '15 at 16:39
  • 1
    @grep not sure: I wrote that more than 6 years ago. – VonC Mar 08 '15 at 17:16

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.

  • 35,194
  • 20
  • 73
  • 86

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.

  • 4,691
  • 5
  • 35
  • 55
  • In what cases are they faster? passing references around is just as fast as passing primitives around. – OJ. Oct 27 '08 at 11:05
  • 1
    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. – nkr1pt Oct 27 '08 at 11:09

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.

  • 5,751
  • 3
  • 24
  • 25
  • 1
    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? – alexmcchessers Oct 27 '08 at 11:39
  • 2
    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. – carson Oct 27 '08 at 11:51
  • 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. – alexmcchessers Oct 27 '08 at 12:00
  • 1
    It is a simple matter of making the code more readable. Worry about performance when you have a problem. – carson Oct 27 '08 at 12:05
  • 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). – jb. Oct 27 '08 at 12:26
  • 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. – carson Oct 27 '08 at 13:44
  • You're right, sorry. Syntactically theyre equal. But I had such experiences in pre 1.5 projects that I was working with last year. – jb. Oct 27 '08 at 13:57
  • 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. – John M Oct 27 '08 at 15:07
  • 1
    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. – carson Oct 27 '08 at 15:28
  • 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. – John M Nov 17 '08 at 18:59
  • 1
    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. – carson Nov 18 '08 at 22:00

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){

God it was evil.

  • 23,300
  • 18
  • 98
  • 136