Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

String Question

 
Fes D Gaur
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
public class Test{
public static void main(String r[]){
String a = "XYZ";
String b = "XYZ";
if(a == b){
System.out.println("true");
}

String x = new String("ABC");
String y = new String("ABC");
if(x == y){
System.out.println("true");
}
}//end of main
}//end of class

When this class is executed the first if prints true and the second if does not print true. I'm confused about the first if printing true because I have two references a and b pointing to two objects. Or is the case that since both are "XYZ" the JVM puts "XYZ" in the String pool and uses the same object for both references. If this is the case then were two objects created here:
String a = "XYZ";
String b = "XYZ";
or just one?

Thanks,
Fes
 
Srinivasa Raghavan
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right.
In the first case "XYZ" is already available in the string pool so the reference variable 'b' points to the already available string object.
How ever in the second case the String object is created using the new operator, so two new string objects are created for Strings "ABC"
[ July 15, 2005: Message edited by: Srinivasa Raghavan ]
 
Wei-ju Wu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "XYZ" is only one object within the string pool, a and b both reference the same object.
 
Fes D Gaur
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But then for the following:

String a = "XYZ";
String b = "XYZ";

are two objects created or one?

Thanks,
Fes
 
Srinivasa Raghavan
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One Object in the String pool a & b refers to that.
please chect this article .
[ July 15, 2005: Message edited by: Srinivasa Raghavan ]
 
Pedro Henrique Pereira de Andrade
Greenhorn
Posts: 3
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for my english, isn't good, but i'm tring.
rigth:

Try test the values witch ObjectString.equals(OtherObject) for obtain correct return, ok. see you later.
 
Antonio Giovanni
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, it is always a bad practice, to use

String a = "XYZ";

compared to

String a = new String("XYZ");
because String Literals are not eligible for garbage collection
at all..
 
Wei-ju Wu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not agree. Strings in the pool are shared and therefore one can avoid creating unnecessary little objects which the garbage collector would have to take care of.
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, the best practice would be to always use var = "string";, and for comparison always use var.equals() method.
It will provide you best memory uses and always correct results.
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

So, the best practice would be to always use var = "string";, and for comparison always use var.equals() method.
It will provide you best memory uses and always correct results.

That depends on the context. Granted, I often make broad sweeping statements like that without a stated context. I assume the context of 'the developer is striving for maintainability, clarity, ease of use, robustness and improved time to market". Within this implied context, I say things like "non-final classes implicitly violate requirements". Also granted, I don't provide the many steps in requirements analysis to arrive at this conclusion, however, I stand firmly behind the assertion. I also disagree that your statement holds true within what I would assume is the context - perhaps you'd like to state your context?
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The contaxt I am talking is Ease of development, performance of app and correctness of app.
The only point I am trying to assert is that if you are not explicitly asking JVM to create a new Object, JVM may return an existing object for you. This is done for improving performance. It's in your benefit to use this compiler smartness to improve performance of you app. And there is almost no downside as Strings are immutable objects, they can not change their states, once they are created. Only inconsistant behaviour happens when you use "==". I think 99% of time, there is no requirement to use "==" on String objects. Normally you intend to compare contant of String not the heap address and you use ".equals()" for this purpose.

Hope I am clear here.
 
Devender Thareja
Ranch Hand
Posts: 187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Barry Gaunt:
"DKT" please read our JavaRanch Naming Policy and change your displayed name (via the My Profile link) to comply with it. Failing to do so will mean that your profile will be disabled.

Thanks,
-Barry

(NR)



My New Name is Devender Thareja.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic