• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Integer Constant Pool ????

 
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 .
 
Ranch Hand
Posts: 411
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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 ]
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?:

 
Ranch Hand
Posts: 151
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That doesn't explain the output of true/false.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That doesn't explain the output of true/false either.
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
3 chocolate cookies for you
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[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
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the cookies, Tony. yum-yum
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"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
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic