• Post Reply Bookmark Topic Watch Topic
  • New Topic

String Query  RSS feed

 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Quick question about Strings. The example below has me slightly confused as it shows what seems like an inconsistency in approach to handling the contents of a String:



When run this returns:

Match1
Match2
Match3
Match4
Not Bob!
Not Bob!
Bob!
Not Bob
!

Where I'm slightly confused is why within the try/catch loop code I NEED to use the String.equals when I don't in any of the first four examples. It's as if the earlier examples get a helping hand i.e. s1List[0] is in theory a String object ref variable, not a string value. However, it works without HAVING to use s1List[x].equals.

Just wondered why the difference in what seems to be the same thing i.e. checking the contents of a String object.

Cheers,

PaulC.
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, forgot to say that the file bobs.txt contains a single line of:

Bob/Joe
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clements wrote:
Just wondered why the difference in what seems to be the same thing i.e. checking the contents of a String object.


In the first case, you are seeing the effects of the string pool. And specifically, due to the fact that generated code uses it for compile time constants. In the second case, there is no use of the string pool via loading from files.

Henry
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:In the first case, you are seeing the effects of the string pool. And specifically, due to the fact that generated code uses it for compile time constants. In the second case, there is no use of the string pool via loading from files.

Henry

Ok, thanks, Henry. I'll go and Google that :-)
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm, clearly the idea of a String pool was swept under the carpet in the beginners book I'm reading. However, had a look at some articles on the web and I think I can maybe see what it's about i.e. not storing the same value twice if it can be avoided.

Looking at my code in the opening post:

Does the above actually create TWO entries (contstants) in the String pool i.e.

"Bob" - accessed by s1 AND s1List[0]
"Joe" - accessed by s1List[1]

Whereas in the later piece of code:

The string pool is not impacted by this statement and so you have to treat the entries in the BobList array as objects and therefore use .equals?
 
Knute Snortum
Sheriff
Posts: 4281
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
so you have to treat the entries in the BobList array as objects and therefore use .equals?

The elements in BobList are always objects, regardless.  obj1 == obj2 is almost never right, as it compares references, not the contents of the objects.  Always use obj1.equals(obj2).
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Knute Snortum wrote:
so you have to treat the entries in the BobList array as objects and therefore use .equals?

The elements in BobList are always objects, regardless.  obj1 == obj2 is almost never right, as it compares references, not the contents of the objects.  Always use obj1.equals(obj2).

Oh, of course. I understand that. My query was why DON'T you need to use .equals in the earlier String array example. The answer I am happy to accept is that it is because the first example takes advantage of the String pool, whereas the second (file read) doesn't.
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now that I am aware of String pools. Can I ask a follow up?

In this code:

The result will clearly be "Two Bobs". My question is why? Is it because:

1. s1 and s2 are both resolved to "Bobs". "Bobs" = "Bobs" so the "==" succeeds.
2. s1 and s2 both point to the same constant in the String pool. Therefore by implication they must be the same, so the "==" succeeds.

My guess would be 2 i.e. that we are comparing where s1/s2 reference, not what they reference. The fact that they reference the same thing is enough to mean they are equal.
 
Paul Clements
Ranch Hand
Posts: 99
1
Chrome Eclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Post above should say:

1. s1 and s2 are both resolved to "Bob". "Bob" = "Bob" so the "==" succeeds.

I can't edit posts!!
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clements wrote:Hmmm, clearly the idea of a String pool was swept under the carpet in the beginners book I'm reading. However, had a look at some articles on the web and I think I can maybe see what it's about i.e. not storing the same value twice if it can be avoided.


In my opinion, most books on the Java language do not discuss the string pool, because it is an implementation detail -- and not part of the language.

Henry
 
Knute Snortum
Sheriff
Posts: 4281
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe the second answer is correct, but don't rely on this behavior.  As Henry says, it's an implementation detail.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!