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 ]

Cheers,<br />Jay<br /> <br />(SCJP 1.4)<br />Heights of great men were not achieved in one day, they were toiling day and night while their companions slept.

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.

"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."

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,

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

But,

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]: 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.

"I'm not back." - Bill Harding, Twister

Joyce Lee
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392

posted Jan 23, 2005 17:51:00

0

Thanks for the cookies, Tony. yum-yum

Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

posted Jan 23, 2005 19:42:00

0

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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671

posted Jan 23, 2005 22:01:00

0

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
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

posted Jan 23, 2005 22:28:00

0

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

However,

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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671

posted Jan 23, 2005 22:40:00

0

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
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392

posted Jan 24, 2005 01:55:00

0

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.

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
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

posted Jan 24, 2005 15:00:00

0

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