12

There are instances where a method expects a primitive type double and you pass a Double object as a parameter.

Since the compiler unboxes the passed object will this increase memory usage or decrease performance?

Petter Friberg
  • 21,252
  • 9
  • 60
  • 109
simranNarula
  • 641
  • 3
  • 9
  • 14

5 Answers5

9

This is what Java Notes says on autoboxing:

Prefer primitive types

Use the primitive types where there is no need for objects for two reasons.

  1. Primitive types may be a lot faster than the corresponding wrapper types, and are never slower.
  2. The immutability (can't be changed after creation) of the wrapper types may make their use impossible.
  3. There can be some unexpected behavior involving == (compare references) and .equals() (compare values). See the reference below for examples.
  • 1
    Specific unexpected behavior includes NullPointerExceptions when unboxing. – Ryan Schipper Sep 30 '11 at 13:00
  • autoboxing surprises: http://www.theserverside.com/news/thread.tss?thread_id=27129 –  Sep 30 '11 at 13:07
  • yep, but the question was about 'autoboxing'. If he would ask 'should I use primitives over the wrapper classes' then of course you are right, otherwise the autoboxing itself doesn't affect performance on the modern JVM's - at least from what I know. – Kris Sep 30 '11 at 13:11
  • @Kris: He asks if autoboxing should be avoided, which I answered with "Prefer Primitive Types". To his remark about "heaviness", I answered with my first bullet point. –  Sep 30 '11 at 13:14
  • @0A0D: true again, but you are still talking about heaviness of wrapper classes vs. primitives and not about heaviness of autoboxing itself :) – Kris Sep 30 '11 at 13:18
  • "For two reasons" - lists 3 haha :-) – Ascalonian Mar 13 '19 at 03:58
6

The rule of thumb is: always use primitives if possible.

There are cases where this is not possible, like collections, so use wrappers only then.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
5

It's a design-choice and not trivially answered for every case.

There are several items that could influence your decision:

Advantages:

  • Auto-boxing and auto-unboxing can make your code easier to read:

    Leaving out all the unnecessary .doubleValue() and Double.valueOf() reduces the visual noise and can make your code easier to read.

  • Auto-boxing allows you to easily use collections of primitive values (such as a List<Double>, ...)

Disadvantages:

  • excessive, unnecessary auto-boxing and auto-unboxing can hinder your performance.

    For example, if you have an API that returns a double and another API that expects a double, but you handle the value as a Double in between, then you're doing useless auto-boxing.

  • auto-unboxing can introduce a NullPointerException where you don't expect it:

    public void frobnicate(Double d) {
      double result = d / 2;
      // ...
    }
    
  • using collections of auto-boxed values uses a lot more memory than a comparable double[] for example.

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
3

You don't have to avoid autoboxing if talking about performance, JVM should handle that. The only thing you should consider is a readability of your code.

Kris
  • 5,714
  • 2
  • 27
  • 47
0

Autoboxing should be avoided. It can lead to errors because of overloading and it has some performance impact. Nonetheless it may not be an issue in your application. But be aware of the impact.

keiki
  • 3,260
  • 3
  • 30
  • 38