Why only Strings are handled in a different kind of memory pool?

Hi all,

I have this question, may be this was answered so many times by you guys. but I hope to get a satisfactory answer again.

(1) Why only Strings are handled in a different kind of memory pool?
(2) why they are made immutable, and How Java has implemented immutability in Strings?
(3) How can we make an object immutable?

Thanks,
Pawan Chopra.

(1) Strings are not handled in a different kind of memory pool. The contents of String objects is stored on the heap, just like any other kind of object in Java. What you probably are referring to is the string pool, which is an optimization technique to reduce the amount of memory that Java programs use. The string pool is not a special kind of memory pool that's different from the heap or the stack.

(2) Read this article to understand what "immutable" means. String objects are immutable because of the way the String class is constructed. If String objects were not immutable, then an optimization technique like string pooling would not be possible.

(3) Read the article that I mentioned above. To make your own class immutable, don't provide any methods that change the state of an instance of your class after it has been created (so, don't provide any setter methods or other methods that change the internal state of the object).

For first question I am asking that why a different string pool for Strings only? why not for Double or any other object?

Integers can get pooled too, and Booleans should always attempt to use Boolean.TRUE and Boolean.FALSE, although that is not quite the same.

I think I am not able to explain my question. I know that we can also pool Integers and Doubles. But why Java has handled pooling for Strings only not for Integers or Doubles when they can be pooled?

Sorry If It is irritating you guys

Originally posted by pawan chopra:
I think I am not able to explain my question. I know that we can also pool Integers and Doubles. But why Java has handled pooling for Strings only not for Integers or Doubles when they can be pooled?

Because the difference in memory usage is much bigger for Strings.

But Java does have special treatment for Integer.valueOf(...)

Mutable and Immutable Objects

Discussing the immutable tricks from Strings is not so simple as it employs tricks we can only dream of. Feel free to browse the source code.

There can be a lot of memory chewed up by string usage, and there is a lot of value to be saved by pooling that memory. Especially given typical programmatic manipulation that occurs on strings.

Int/Double are of fixed size, and a lookup for all ints would be much less productive. You usually want to optimize processing speed when working with numbers, moreso than memory usage.

You easily could decided to use a similar scheme, but the Masters of Java� have weighed the pluses and minuses and not gone that direction.

Another thing that hasn't been mentioned here is that String object literals have been built into the Java language since day one: i.e., you write

System.out.println("Hello, World");

and this refers to a String object whose value is "Hello, World". If your code uses "Hello, World" a couple of times, it would be silly to create a separate String for each occurrence: thus the pool. You see how this fell naturally out of the language itself. Strings are special because there traditionally were no other kind of "invisible objects" like this, that appeared seemingly out of nowhere.

But since Java 5, we've had autoboxing, and so Integer, Double, etc objects can all be created invisibly. And so, in fact, there are pools for these too (as someone did point out above.) These new pools are accessed via the "valueOf()" methods in each wrapper class. Integer.valueOf(3) will return a pooled Integer object with value 3. Therefore the String pool is no longer unique.

As to immutability requiring "tricks we can only dream of", I'm not quite sure what that means. It's easy to make an immutable class: just don't provide any way to change the innards of the object!

[Jesper]: (1) Strings are not handled in a different kind of memory pool. The contents of String objects is stored on the heap, just like any other kind of object in Java. What you probably are referring to is the string pool, which is an optimization technique to reduce the amount of memory that Java programs use. The string pool is not a special kind of memory pool that's different from the heap or the stack.

That's what the documentation for String.intern() indicates, but it's not really true, at least for modern JVMs. Strings in the intern pool are in the heap, true, but it's a special part of the heap - the permanent generation. This is an area for objects that are assumed to stay around in memory for a long time - though contrary to the name, objects here aren't necessarily permanent, just very long-lived.

Additionally, the string intern pool consists of two components: the strings themselves, and a hash table that contains references to the strings. This hash table is part of the JVM infrastructure, implemented in native code, not a Java HashMap or other Java object. Not in the heap at all, really.