• Post Reply Bookmark Topic Watch Topic
  • New Topic

String initialization  RSS feed

 
Doug Fisher
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm pretty new to java and have a dumb question. I know I can use:


or:

to initialize a String, but is one preferred over the other or considered "more right". Is there any different in performance?
I know there must be something different happening, given the follow code:


This outputs "bar" because s1 is not the same object as s2, but I don't quite understand why they aren't the same object if s1 and s3 are.
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The preferred method would be the second - the direct assignment of the literal to the variable. This question is all about the String Literal Pool. To read more read this journal article.
 
Rohan Deshmkh
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Strings are immutable.What this means is that when a String object is created it's state cannot be changed.
For eg.
String s="Dennis"
s="Mark"

Now a common question that arises is if strings are immutable , then at this point if you print s how come s now prints Mark and not Dennis.SO the answer is:
Immutable means the state of object cannot be changed but what the reference variable points to can definitely be changed.
s is not an object, it is a reference variable that points to String object Dennis.When we write s="Mark" then a new object Mark is created and s starts pointing to it.

== generally checks if two objects point to same location or object.
So, if we have String s1 = "Foo"; and String s3 = "Foo"; then s1==s3 will return true because they refer to same objects.

So why do they refer to same objects?
There is a concept of String pooling.Whenever a String literal is created (this does not include string creation using new keyword),then the string is placed in that pool.After that whenever we create new String literal the jvm first checks if that String is present in that string pool.If present it simply returns a reference to it and no new object is created.So that's why s1==s3 returns true.

But when you create String s2=new String("Foo") then , a new object is created irrespective whether Foo is present in the string pool or not.That is why s1==s2 returns false.
Note that String objects created with the new operator do not refer to objects in the string pool but can be made to using String's intern() method.
 
subhod lagade
Greenhorn
Posts: 6
Hibernate Oracle Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Nicely explained concept of string mutable by Rohan Deshmkh.

Doug Fisher : we need to refer more on string pooling to understand string concepts in more detail.
 
Campbell Ritchie
Marshal
Posts: 56585
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rohan Deshmkh wrote: . . . == generally checks if two objects point to same location or object. . . .
You mean if two references point to the same location or object. If you use == on reference types, it always tests whether the two reference point to the same object. you should avoid == on reference types, as described here, except for enum elements.
 
Rohan Deshmkh
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Rohan Deshmkh wrote: . . . == generally checks if two objects point to same location or object. . . .
You mean if two references point to the same location or object. If you use == on reference types, it always tests whether the two reference point to the same object. You should avoid == on reference types, as described here, except for enum elements.

yes i meant references ,but i used object by mistake.So the correct one is:
== generally checks if two reference variables point to same object or not.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rohan Deshmkh wrote:
Campbell Ritchie wrote:
Rohan Deshmkh wrote: . . . == generally checks if two objects point to same location or object. . . .
You mean if two references point to the same location or object. If you use == on reference types, it always tests whether the two reference point to the same object. You should avoid == on reference types, as described here, except for enum elements.

yes i meant references ,but i used object by mistake.So the correct one is:
== generally checks if two reference variables point to same object or not.


No, not "generally". Always. The == operator always checks if its two operands have the same value. In particular, with reference expressions, it tests whether both references have the same value, which in turn implies that they either both point to the same object or both are null.
 
Angus Comber
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

No, not "generally". Always. The == operator always checks if its two operands have the same value. In particular, with reference expressions, it tests whether both references have the same value, which in turn implies that they either both point to the same object or both are null.


I wonder what happens under the hood. AFAIK you cannot get Java memory locations so I cant investigate easily. But the == operator possibly checks that the references are equal. In other words point to the same location in memory. (rather than bothering to check that the underlying objects are equal).

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Angus Comber wrote:

No, not "generally". Always. The == operator always checks if its two operands have the same value. In particular, with reference expressions, it tests whether both references have the same value, which in turn implies that they either both point to the same object or both are null.


I wonder what happens under the hood. AFAIK you cannot get Java memory locations so I cant investigate easily. But the == operator possibly checks that the references are equal. In other words point to the same location in memory. (rather than bothering to check that the underlying objects are equal).



Not sure what you're trying to say here, but technically, "same location in memory" has nothing to do with it (although in any normal implementation that's probably exactly what it does). It doesn't check for two objects being equal, and I certainly didn't say that it does. It simply tests whether two refrences point to the same object, or are both null.

http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.21.3
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
some time new String is preferred . read here http://www.coderanch.com/t/542489/java/java/when-string-literal-String-New

*not sure about java 7
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch Doug Fisher
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seetharaman Venkatasamy wrote:some time new String is preferred . read here http://www.coderanch.com/t/542489/java/java/when-string-literal-String-New

*not sure about java 7


The case discussed there--substring retaining the original backing array--is apparently no longer true in Java 7.

Even pre-7 it would only have an effect in a few rare cases. In particular, it would only matter when all of the following were true:

1. The original String was very large.
2. The new String was very small.
3. The new String was going to live on much longer than the original, or at least there would be a significant additional memory demand between when substring() was called and when the original became eligible for GC.

Unless all three of those were true, you wouldn't see any benefit from passing the result of substring() to a new String() constructor.

Right now, there should be no valid reason to ever invoke new String(String). The only case where I could see it mattering is if your code was paying attention to GC generations and you wanted a given reference to be in the eden generation rather than an older one, and that should only occur as a last resort after some serious profiling and refactoring, if ever.
 
Angus Comber
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Not sure what you're trying to say here, but technically, "same location in memory" has nothing to do with it (although in any normal implementation that's probably exactly what it does). It doesn't check for two objects being equal, and I certainly didn't say that it does. It simply tests whether two refrences point to the same object, or are both null.

http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.21.3


You can think of a reference as being a variable which stores the memory location of the actual object.

ie

String name = new String("Jeff");

The String object is stored in memory location 100 say.

variable called name is a variable storing the memory location 100 - this is the 'reference'.

If you now do:

String name2 = name;

then both name and name2 hold reference 100. So when you do

if(name == name2)

it is comparing the memory locations which are equal and so returns true.

I haven't examined the Java source code but I expect it works something like that.

Yes, what you were saying, points to the same object is effectively saying the same thing. I wasn't disagreeing with you.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Angus Comber wrote:

Not sure what you're trying to say here, but technically, "same location in memory" has nothing to do with it (although in any normal implementation that's probably exactly what it does). It doesn't check for two objects being equal, and I certainly didn't say that it does. It simply tests whether two refrences point to the same object, or are both null.

http://docs.oracle.com/javase/specs/jls/se5.0/html/expressions.html#15.21.3


You can think of a reference as being a variable which stores the memory location of the actual object.


Yes, I know that. We can think of it that way, and in some sense that's more or less how it's implemented in any standard JVM, but the spec is deliberately silent on those kinds of implementation details.

I just don't undesrtand what point you're trying to make. There's not really any debate though as to what == does. The JLS states quite clearly that it evaluates to true if both references point to the same object or both are null.

How exactly that's realized is up to the JVM implementation, but in any mainstream JVM, it probably comes down to some C++ code that says "if pointer 1 == ponter 2", which, as you suggest, compares whether two pointers point to the same location in memory.
 
Doug Fisher
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the warm welcome, and thanks everybody for the info, this makes perfect sense now.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!