Java Integer pool. Why?

Question

I've read everywhere that when you define an Integer between -128 to 127 in Java, instead of creating a new object it returns an object already created.

I don't see any point of doing this other than letting newbie programmers compare Integer objects with == to see if they are the same number, but I think this is bad because sure they think that they can compare any Integer with ==, and also is teaching a bad practice in any programming language: comparing the content of two 'different' objects with ==.

Is there any other reason on why this is done? Or is it just a bad decision when designing the language (In my point of view) like optional semicolon in JavaScript?

EDIT: I see here that they explain the behaviour: Why does the behavior of the Integer constant pool change at 127?

I'm asking why they designed it to have this behaviour, and not why is this behaviour happening.

Breathed

It feels a bit un-necessary to allocate new objects and take up memory when they're immutable anyway and can be shared. – Bertero

Maybe memory optimization is an answer, don't thought about it. – Jog

It save memory, is much faster and reduced pressure on the garbage collector. Reusing objects can be significantly faster and some options increase the Integer cache size to 10,000 or 20,000 for this reason. – Maximalist

Possible duplicate of Why does the behavior of the Integer constant pool change at 127? – Pastiness

Answer 1

It's called the Flyweight pattern and is used to minimize memory usage.

Those numbers are very likely to be used repeatedly, and autobox types like Integer are immutable (note this is done not just for Integer). Caching them makes it so there aren't lots of instances and reduces GC (Garbage Collection) work as well.

The JLS covers this in 5.1.7. Boxing Conversion specifically by saying:

If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.

Hainan

This was not the first answer, but is a more detailed answer. I don't like java optimizing sofware for me. I think that optimizing software belongs to the developer. I mean, they changed how objects should work just to optimize users software. If a developer wants to optimize that, they should work on it making their own Integer pool. But that's my opinion :P – Jog

And now I read about your Boxing Conversion edit and has more sense. Java works under millions of devices with really big hardware differences, so they had to think about reducing memory usage at any cost. Good work Java :P – Jog

I would argue that the entire point of a high level language like Java is hiding gory details from the end user when possible ;) But this in particular ... eh, I could go either way. – Hainan

Pooling is becoming less relevant these days, now that Java memory allocation is so cheap (ibm.com/developerworks/java/library/j-jtp09275/index.html). The JVM now supports escape analysis starting with Java 7 and Java SE 6u23, so the impact of temporary object creation is even less (docs.oracle.com/javase/7/docs/technotes/guides/vm/…). – Scutter

Answer 2

I think that creating any object takes more time than taking it from the symbol table. Moreover, if I am not mistaken, every object on the heap takes up 24 bytes of additional space for the header. Now, if a programmer writes his/her program, most of the operations are done on small ints (in this case, small Integers). So it allows to save a lot of space and to improve performance a little.

Beghard

I'm curious.. Why 24? On which JVM? – Effy

Yeah, now has more sense... Not thought about memory, what a shame lol :P Thank you. – Jog

I think on most of them. I dont know why exactly 24 for the header. I think there must be a signature or sth like that. + if the total memory is not divisible by 8, padding is also added (in case Integer is a wrapper for int - 24 (header)+ 4 (int) + 4 (padding)) – Beghard