Integer Constant Pool ????

[ankur rathi]

Is there any term like Integer Constant Pool . I am asking because I read in K&B that Integer object are also immutable . So It is like that

Integer i = new Integer(1);

1 is Integer constant object in ICP & one object has its reference & reffered by i .

please help .
thanks .

[Jay Pawar]

Original Post Rathiji:
Is there any term like Integer Constant Pool ?

I don't think there is something like Integer Constant Pool.
Integer object is immutable because the data passed in the constructor is stored in a private variable called as value, which cannot be modified by any other instance method.There is no setter method which will allow you to modify the value.

[ January 21, 2005: Message edited by: Jay Pawar ]

[Tony Morris]

The short answer is "no, there is no Integer constant pool in the same way as there is no String literal pool - they are abstract concepts only."
JLS 15.28 can help you out there if I remember erectly.
e.g.

final int x = 7;
boolean b = "blah" + 7 == "blah7"; // true
// Nothing was "plucked from a pool".

On a similar topic, here's some fun:
What is the output and why?:

import java.util.Map;
import java.util.IdentityHashMap;
 
public final class X
{
private X()
{
 
}
 
public static void main(String... args)
{
Map<Integer, Integer> m = new IdentityHashMap<Integer, Integer>();
m.put(7, 8);
System.out.println(m.containsKey(7));
System.out.println(m.containsKey(new Integer(7)));
}
}

[Joe Borderi]

Here's the why:

public class IdentityHashMap<K,V>extends AbstractMap<K,V>implements Map<K,V>, Serializable, Cloneable

"This class implements the Map interface with a hash table, using reference-equality in place of object-equality when comparing keys (and values). In other words, in an IdentityHashMap, two keys k1 and k2 are considered equal if and only if (k1==k2). (In normal Map implementations (like HashMap) two keys k1 and k2 are considered equal if and only if (k1==null ? k2==null : k1.equals(k2)).)

This class is not a general-purpose Map implementation! While this class implements the Map interface, it intentionally violates Map's general contract, which mandates the use of the equals method when comparing objects. This class is designed for use only in the rare cases wherein reference-equality semantics are required."

[Tony Morris]

That doesn't explain the output of true/false.

[Jeroen Wenting]

If you check compareTo and equals on Integer they just compare the values, which is why 2 Integer instances with the same numeric value return true on comparing them.

[Tony Morris]

That doesn't explain the output of true/false either.

[Joyce Lee]

System.out.println(m.containsKey(7));

The output is true. That's because according to JLS3 5.1.7 Boxing Conversion rule:

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

Meaining,

Integer i1 = 1; // autobox 1 to Integer
Integer i2 = 1; // autobox 1 to Integer
i1 == i2 is true; 

This is achieved by using whatever caching mechanism. And it only supports the range between -128 and 127.

Integer i1 = 128;
Integer i2 = 128;
i1 = i2 is false

But,

Integer i1 = new Integer(1);
Integer i2 = 1;
i1 == i2 is false

System.out.println(m.containsKey(new Integer(7)));

And that's why the second output is false.

A slight change to m.put(new Integer(7), 8) would cause the output to become false false.

[Tony Morris]

3 chocolate cookies for you

[Jim Yingst]

[Tony]: The short answer is "no, there is no Integer constant pool in the same way as there is no String literal pool - they are abstract concepts only."

I'm not sure what's so abstract about the String literal pool - or more properly, the String intern pool, which includes String literals as well as anything that's been intern()-ed. Its existence is explicitly required by the String API (see the intern() method). What's so abstract about it?

Each class also has its own runtime constant pool which has info on all compile-time constants used by a given class - including ints. Which sounds similar enough to the original question that I thought it worth mentioning - though it's not an integer constant pool.

[Joyce Lee]

Thanks for the cookies, Tony. yum-yum

[Tony Morris]

I mean that the "literal pool" is only an aid for conceptualising - it does not physically exist (necessarily).

The JLS is ambiguous in section 3.10.5 where it suggests that the same String literal are all the same object, however, this is not the case in the Sun implementation - two String literals that are in different scopes may be two different instances (or may not be depending on the garbage collector).

[Jim Yingst]

Hmmm. Ignoring the actual implementation for the moment - what's ambiguous in JLS 3.10.5, on this point? I see a number of statements indicating that identical string literals in different packages / classes will refer to the same object. What am I missing that indicates otherwise?

[Tony Morris]

"Literal strings within the same class (�8) in the same package (�7) represent references to the same String object (�4.3.1)."

However,

class X
{
    void m()
    {
        {
            String s1 = "blah";
        }
 
        {
            String s2 = "blah";
        }
    }
}

It cannot be guaranteed that s1 and s2 are referring to the same object, at least, in the Sun implementation. There is ambiguity in that I can't be sure if the JLS actually ackowledges this, or not.
[ January 23, 2005: Message edited by: Tony Morris ]

[Jim Yingst]

To me, that doesn't sound like ambiguity - it sounds like an error in the Sun implementation. Or if you prefer, it's an inconsistency between the spec and the implementation. Taking the JLS by itself, is there anything within the spec that is ambiguous about this?

[Joyce Lee]

Tony: It cannot be guaranteed that s1 and s2 are referring to the same object, at least, in the Sun implementation. There is ambiguity in that I can't be sure if the JLS actually ackowledges this, or not.

I tested using the following the code, both variables s1 and s2 from different scopes are referencing to the same object.

public class Test {
    public static void main(String[] args) {
        String temp;
 
{
    String s1 = "Blah";
    temp = s1;
}
 
{
    String s2 = "Blah";
    System.out.println(temp == s2); // output is true
}
    }
}

It cannot be guaranteed that s1 and s2 are referring to the same object, at least, in the Sun implementation.

Did you get a result of s1 and s2 pointing to different objects?
[ January 24, 2005: Message edited by: Joyce Lee ]

[Tony Morris]

Or if you prefer, it's an inconsistency between the spec and the implementation.

That is one conclusion. Another is that the specification assumes that there is no possible way to determine if two String literals that are outside the scope of each other are referring to the same object. This is where I call it an ambiguity (which one is correct?).

Of course, if you maintain a reference to the instance as in the case that Joyce provided, you are guaranteed to have it the same instance. You'll note that in the test case I provided, the instance becomes eligible for GC when it goes out of scope (and thus, if it is GC'ed, the instance in the next block will be a different one).

This assumption by the specification (assuming it is an assumption, and not an error) is false however - it can be proven - hint: System.identityHashCode