6

Ok, so I understand that Integer is simply a wrapper class. however my concern is that avoiding to use a "wrapper", there might be a micro-optimization in execution time when using primitive ints variables.

My question is regarding, is really Integer object the one we should prefer to use, specially in programs which are required to have great performance(with great I mean, heavy duty, O(N^n) algorithms, the ones that take days).

Also, same case for double vs Double, float vs Float , etc.

Jorch914
  • 3,465
  • 2
  • 16
  • 21
  • 5
    No, most of the time `int` is simpler to use than `Integer`. What makes you think you *should* use `Integer` all the time? – Jon Skeet May 11 '15 at 18:34
  • 4
    This question has already been answered [here](http://stackoverflow.com/questions/6474576/java-primitive-types-int-vs-integer) and [here](http://stackoverflow.com/questions/10623682/using-int-vs-integer) and [here](http://stackoverflow.com/questions/423704/int-or-integer) and [here](http://stackoverflow.com/questions/1570416/when-to-use-wrapper-class-and-primitive-type). – Kevin Workman May 11 '15 at 18:36
  • In fact I do prefer primitive types, is just that I started seen people using Integer objects, that and the fact that these Integer objects "exist" have been troubling me for a while. I thought there might be some explanation regarding how the jvm actually works or something. – Jorch914 May 11 '15 at 18:39
  • One thing to note: the whole point about O(f(n)) is that things like performance of a particular object are negligible in comparison to the algorithm itself for a large input. Optimizations like this won't mean anything if the algorithm itself is that bad. – RealSkeptic May 11 '15 at 18:45

3 Answers3

10

You should prefer using the primitives whenever you can. Otherwise they wouldn't exist. The developers of Java even made extra effort in developing (for Java 8) Streams that support primitive types (IntStream, LongStream, DoubleStream), so you won't have to pay the performance penalty of multiple boxings and unboxings that you pay when using Streams of reference types for wrapper classes.

The wrappers are only for cases in which you have no choice (for example, you can't put primitive types directly in a Collection).

Eran
  • 387,369
  • 54
  • 702
  • 768
3

A wrapper class instance takes more memory (wrapped value + reference), and generates some method calls where the primitive types only perform basic operations. However, some mechanisms tend to reduce this overhead (for example, Integer instances between -128 and 127 are kept in a pool if not declared using new). The difference is probably slight, but where you can use primitives, do it simply by principle : don't use classes that provide more features that you need.

Dici
  • 25,226
  • 7
  • 41
  • 82
1

Prefer int to Integer unless null is a valid value or it will be placed in a collection.

Steve Kuo
  • 61,876
  • 75
  • 195
  • 257
  • In old Java, yes, otherwise I think that an `Optional` is more expressive...and robust – Dici May 11 '15 at 18:47
  • With a primitive you'll get compile time guarantee that it's non-null. It appears (correct me if I'm wrong) that `Optional` is only runtime checking. – Steve Kuo May 11 '15 at 21:46
  • I thought that you were suggesting to use `Integer` when you want your integer value to be possibly absent (null), whereas `Optional` is the best fitted to handle the absence of any kind of value. – Dici May 11 '15 at 21:50
  • @Dici `Optional` is doubly perverted as you have two objects instead of one. As a bonus, it may be `null`, too. – maaartinus May 12 '15 at 17:26
  • @maaartinus your first argument is quite specious. Is a `Pair` evil because it's three objects instead of two ? What is important is the semantic of the program, not the number of objects during the execution, as long as it stays reasonible. Yeah, `Optional` can be `null`, but at least you know that is is **not intended** whereas using purposedly a wrapper type to use `null` to express the absence of value is saying that `null` is an acceptable value. That is very poor semantic, where the `Optional` immediately informs that they could be no value even in normal executions – Dici May 12 '15 at 21:44
  • @maaartinus As an example, I've seen mistakes such as `if (myBooleanInstance)` breaking when the `Boolean` where `null`, because the developer did not know enough context about the codebase to guess that `null` should be handled as a non-error case. With `Optional`, he should have written something like `if (myOptional.orElse(false))`. `Optional` forces at compile-time to take care of the particular case of the absence of value. There's no way it could be called *perverted* – Dici May 12 '15 at 21:51
  • No, `Pair` is only evil because it [conveys no semantics](https://code.google.com/p/guava-libraries/wiki/IdeaGraveyard), but unlike `Optional`, it has an added value. Concerning it, I fully agree with [this nice rant](https://groups.google.com/forum/#!msg/project-lombok/ROx9rGRb6lI/EF0lk8F0N10J). Moreover, its introduction has blocked the way to a sane `null` handling (e.g., the way Kotlin does). With some syntactic sugar, all what `Optional` gives could be achieved, and more. With Kotlin-like syntax `Boolean? myBooleanInstance` is a nullable type and can't be used as a condition. That simple. – maaartinus May 12 '15 at 21:57