Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

what is the scope of the string pool?

 
Stu Thompson
Hooplehead
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, so if I have the below code:

String foo = "stu";
String bar = "stu";

I can grasp that foo == bar evaluate to true. "stu" ends up in the string pool as a single object that both foo and bar reference.

Question is, with what scope, if any, does that become false? E.g.: If foo was declared in as a member variable but bar was a local? Or different classes? Or???

tia,

Stu

[ August 17, 2006: Message edited by: Stu Thompson ]
[ August 17, 2006: Message edited by: Stu Thompson ]
 
Joanne Neal
Rancher
Posts: 3742
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why don't you write some code and experiment. Post the results. Comparing String references in classes loaded using different ClassLoaders should be interesting.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To the best of our knowledge, foo == bar will always evaluate to true, assuming both foo and bar were assigned using equivalent constant string expressions, or using the intern() method on an equivalent string. Even if they're from different classes, classloaders, whatever. The JVM has exactly one string intern pool, outside any classloader, and it retains at most one instance of any given string content.

The only known exception is achieved by reformulating the question a bit and comparing two interned strings which are not in the JVM at the same time. That is, it's possible to load a string into the intern pool, then cause it to be unloaded, then intern another string with the same content, and determine that the new string is different than the original, using System.identityHashCode().

To do this with string constants, this requires you to use one classloader to load a class containing the constant, then make the class and classloader eligible for GC, then hope that GC successfully removes the classloader, class, and interned string, then use a new classloader to load a class with an equivalent constant. This may sound like a rare occurrance, but it can happen quite easily in an environment like a web app server. However since the two interned strings cannot be in the JVM at the same time (else the intern pool would resolve them to a single instance), it's impossible to compare them directly usign either == or equals(), or compareTo() or most other tests that might detect that the instances are different. Accordingly, this doesn't actually affect people very often; it's somewhat similar to debating how many angels can stand on the head of a pin.
 
Stu Thompson
Hooplehead
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim,

Thank you very much for the detailed answer...exactly what I was hoping for.

For better and worse, I'm the kind of coder who needs to know how it works behind the scenes...I don't blindly remember facts very well. So just discussing angles and pin heads leads to a better understanding of both even if the conversation is pointless.

And...this is silly of me...but this is my first Java question ever to break out of 'beginner' so I guess all my time on Java Ranch is beginning to show.

Thanks again,

Stu
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can see that it could be interesting to know about what's going on with the string pool. But I am surprised how often questions about it come up.

I've been programming Java for about 7 years without ever writing a piece of code that depended on the string pool. And I think that writing a piece of code that depends on the string pool's behaviour is bad; it's far too unobvious, and unobvious code is unmaintainable and rots quickly.

The only feature of the string pool that I allow myself to depend on is that it makes it OK, from a memory consumption point of view, to have several repetitions of the same String literal in my code. But even that is something which one would generally want to avoid; if you're repeating a particular String literal, you might want to assign it to a named constant, so it can be changed in a single place, if it ever needs to change.
 
Stu Thompson
Hooplehead
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter,

Well, I've been coding Java (like really programming...not school or tinkering) for a whopping two months. I didn't know that two identical string literals compiled into a single item in the string pool until this morning. (I was stunned to see (foo == bar) evaluate to true in the above example.) When I learned this it seemed like 'magic'...and years of programming in other languages has made me very cautious of things that happen magically.

So I came to JR.

So don't fret...I am not going to go out and code string stuff in a manner that would upset you.

Stu
[ August 17, 2006: Message edited by: Stu Thompson ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only time I use == in my code is between primitives. Even when I have otherwise guaranteed 'equals' equals '=='.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mr. C Lamont Gilbert:
Only time I use == in my code is between primitives. Even when I have otherwise guaranteed 'equals' equals '=='.


There is a common philsophy among many people who share an interest in the field that using the == operator on reference types implies a type of defect. This can be mathematically expressed, but I'll bet you can also find some articles "out there" from those who claim to be experts.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic