File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Integer Constant Pool ???? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Integer Constant Pool ????" Watch "Integer Constant Pool ????" New topic
Author

Integer Constant Pool ????

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
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
Ranch Hand

Joined: Aug 27, 2004
Posts: 411

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 ]

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.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
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.


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



Tony Morris
Java Q&A (FAQ, Trivia)
Joe Borderi
Ranch Hand

Joined: Oct 23, 2004
Posts: 151
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
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
That doesn't explain the output of true/false.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
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.


42
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
That doesn't explain the output of true/false either.
Joyce Lee
Ranch Hand

Joined: Jul 11, 2003
Posts: 1392
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,


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

Joined: Sep 24, 2003
Posts: 1608
3 chocolate cookies for you
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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
Thanks for the cookies, Tony. yum-yum
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
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
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
"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
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
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

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Integer Constant Pool ????