String literal pool doubt

[saloni jhanwar]

BOOK->K&B 6->PAGE 434

Creating New Strings
Earlier we promised to talk more about the subtle differences between the various methods of creating a String. Let's look at a couple of examples of how a String might be created, and let's further assume that no other String objects exist in the pool:

String s = "abc"; // creates one String object and one
// reference variable

In this simple case, "abc" will go in the pool and s will refer to it.

String s = new String("abc"); // creates two objects,
// and one reference variable

In this case, because we used the new keyword, Java will create a new String object in normal (non-pool) memory, and s will refer to it. In addition, the literal "abc" will be placed in the pool.

As given statement in book,in my code new String("abc") will create object on heap as well as it would also place "abc" literal in pool because presently there is no "abc" literal, now as "abc" is already in pool so in next statement s2 should refer it hence s1==s2 should be true but it is false.

class Example2 
{
	public static void main(String[] args) 
	{
		String s1=new String("abc");  
		String s2="abc";
		
		System.out.println("s1==s2 ? "+s1==s2);//should be true
	}
}

F:\>java Example2
false

[Campbell Ritchie]

saloni jhanwar wrote:. . . hence s1==s2 should be true . . .

That is not what the article says at all.

[saloni jhanwar]

Campbell Ritchie wrote:

saloni jhanwar wrote:. . . hence s1==s2 should be true . . .

That is not what the article says at all.

new String("abc") creates two objects first on heap, another on pool now as there is a "abc" literal already on pool so s2 should refer it,and if this refers it then s1==s2 should be true.

[Ralph Cook]

Try thinking of it this way: s1 is an object that contains a reference to "abc". s2 is a reference to "abc".

The == operator only returns true if s1 and s2 point to the same object, and they do not. Both these objects do have the same value.

[Winston Gutkowski]

Campbell Ritchie wrote:That is not what the article says at all.

I have to admit, this business of caching Strings seems to cause more problems than it solves. People seem to read into it some license to use '==' rather than equals().

@saloni: DON'T. ALWAYS, ALWAYS, ALWAYS use equals() to compare objects. And Strings are objects.

(loud enough? )

Winston

[Rameshwar Soni]

saloni

[saloni jhanwar]

Ralph Cook wrote:Try thinking of it this way: s1 is an object that contains a reference to "abc". s2 is a reference to "abc".

The == operator only returns true if s1 and s2 point to the same object, and they do not. Both these objects do have the same value.

I know how equals and == works very well but question was something different.i was just asking meaning of last two lines which is quite unclear.new String("abc") will create two objects, it has also some sense here.

[Winston Gutkowski]

saloni jhanwar wrote:I know how equals and == works very well...

I'm afraid that clearly you don't, because new String("abc") is not == "abc" - ever - for the reasons that Ralph tried to explain.

Winston

[saloni jhanwar]

Rameshwar Soni wrote:saloni

You are wrong in in your post.

[saloni jhanwar]

Winston Gutkowski wrote:

saloni jhanwar wrote:I know how equals and == works very well...

I'm afraid that clearly you don't, because new String("abc") is not == "abc", for the reasons that Ralph tried to explain.
Winston

Ok now what i am getting i am writing here String s1=new String("abc") creates two objects first on heap another on pool and both objects haven't any relation except than same content.now String s2="abc" it will look for literal "abc" in pool as because of there is a literal "abc" in pool provided by first statement so s2 will refer that second object on pool not first object on heap.Am i correct ?

[Rameshwar Soni]

1) Try executing this code

class String_Check
{
	public static void main(String[] n)
	{
		String s1=new String("abc");
		String s2="abc";
		String s3="abc";
		if(s1==s2)
			System.out.println("s1==s2");
		if(s1==s3)
			System.out.println("s1==s3");
		if(s2==s3)
			System.out.println("s2==s3");
	}
}

So according to you s2 will not be created, so please execute the code.
The output is
C:\>javac String_Check.java
C:\>java String_Check
s2==s3
C:\>

So you can see s1!= s2, which means s2 is created.................
Also i don't know if there is some printing mistake (not sure) in book because here's a related thread
here

[saloni jhanwar]

If you read my last post then you dont confuse here definitely s1!=s2 because s2 pointing second object on pool not first object on heap.s1 creates two objects one on heap and another on pool.How both are same here? they are two different objects with same content but on different location heap and pool.

your doubt would be clear.

Read Kathy Sierra post https://coderanch.com/t/240553/java-programmer-SCJP/certification/Kathy-your-book

[Winston Gutkowski]

saloni jhanwar wrote:Ok now what i am getting i am writing here String s1=new String("abc") creates two objects first on heap another on pool and both objects haven't any relation except than same content.now String s2="abc" it will look for literal "abc" in pool as because of there is a literal "abc" in pool provided by first statement so s2 will refer that second object on pool not first object on heap.Am i correct ?

Well, first: All objects are created on the heap. The "pool" is simply a structure (very possibly a HashMap of some sort) that contains references to the literals defined in your source code. This is simply a convenience to so that duplicated literals don't result in multiple objects being created.

However, whenever you use the 'new' keyword, Java always creates a new object, regardless of type; and a new object will never be '==' to any other.

HIH

Winston

[saloni jhanwar]

Winston Gutkowski wrote:
Well, first: All objects are created on the heap. The "pool" is simply a structure (very possibly a HashMap of some sort) that contains references to the literals defined in your source code. This is simply a convenience to so that duplicated literals don't result in multiple objects being created.

However, whenever you use the 'new' keyword, Java always creates a new object, regardless of type; and a new object will never be '==' to any other.

Winston

Yes,I know pool is nothing else then a virtual area on heap but for better understanding it is good to treat them separate.

[Seetharaman Venkatasamy]

Winston Gutkowski wrote:

Campbell Ritchie wrote:That is not what the article says at all.

I have to admit, this business of caching Strings seems to cause more problems than it solves.

disagree, sorry . confusion will be there even at simple thing. if there is no pool concept, there could be a lot of redundant objects..
for example, String name = "";

[Campbell Ritchie]

saloni jhanwar wrote: . . . You are wrong in in your post.

So as to avoid any confusion caused by this discussion going on here and on that other thread referred to, I am closing that other thread. I might re‑open it if I remember.

[Winston Gutkowski]

Seetharaman Venkatasamy wrote:disagree, sorry . confusion will be there even at simple thing. if there is no pool concept, there could be a lot of redundant objects...

I'm not saying don't do it; just don't tell people about it.

After all, it's an implementation detail.

Winston

[Nitish Bijalwan]

Welcome to Java Ranch family saloni jhanwar.

Actually you didn't get what she[Kathy] had tried to said.
* First of all object in string pool is different from java object in heap.
* When we write String s ="abc" ,the string object is created in string pool
* when we write String s1 = new String("abc") a string object is create on java heap. So both refer to two different
object.
* Now if I write String S2 = new String("abc") another new object created but If i write
String s2 = "abc" then s2 will refer to the same object as s is refering.

class StringTest
{
	public static void main(String[] args){
		String s ="abc";
		String s1 = new String("abc");
		String s2 = "abc";
		String s3 = new String("abc");
		if(s==s1)
			System.out.println("s==s1");
		if(s==s2)
			System.out.println("s==s2");//Only this will be printed
		if(s1==s3)
			System.out.println("s1==s3");
	}
}

[Campbell Ritchie]

You need to be precise about your terminology. There are also things which are part of the implementation (as WG has said) and these may differ from one implementation to another.

Nitish Bijalwan wrote: . . . * First of all object in string pool is different from java object in heap.

Are you quite sure about that? A String in the constant pool and a String elsewhere on the heap are identical in everything except location.

* When we write String s ="abc" ,the string object is created in string pool

I think the String "abc" is loaded into the String pool when the class is loaded. The assignment to s occurs later, when the code is executed.

. . . If i write String s2 = "abc" then s2 will refer to the same object as s is refering.

This assumes s has not been re‑assigned. The compiler cannot check that s is not re‑assigned, but if s is marked final, it becomes a compile‑time constant.

[saloni jhanwar]

Nitish Bijalwan wrote:Welcome to Java Ranch family saloni jhanwar.

Actually you didn't get what she[Kathy] had tried to said.
* First of all object in string pool is different from java object in heap.
* When we write String s ="abc" ,the string object is created in string pool
* when we write String s1 = new String("abc") a string object is create on java heap. So both refer to two different
object.
* Now if I write String S2 = new String("abc") another new object created but If i write
String s2 = "abc" then s2 will refer to the same object as s is refering.

class StringTest
{
	public static void main(String[] args){
		String s ="abc";
		String s1 = new String("abc");
		String s2 = "abc";
		String s3 = new String("abc");
		if(s==s1)
			System.out.println("s==s1");
		if(s==s2)
			System.out.println("s==s2");//Only this will be printed
		if(s1==s3)
			System.out.println("s1==s3");
	}
}

Do you understand importance of statements sequence ?
Do you think both are same thing ?

String s ="abc";
String s1 = new String("abc");

or

String s1 = new String("abc");
String s ="abc";

and by the way i got what she said but you did not get, first understand these sequence.

[Winston Gutkowski]

saloni jhanwar wrote:and by the way i got what she said...

Aaagh. Doesn't anybody understand what I'm saying?

The "pool" is an implementation detail (and, unfortunately, not the only one that has been made public), and seemingly only of interest to those that want to know whether you can use '==' instead of equals().

DON'T

Java is an Object-oriented language, so use it the way it was intentded.
Strings are what they are - an Object; if you want to learn how use them properly, read the documentation.

</end of rant>

Winston

[Campbell Ritchie]

saloni jhanwar wrote: . . . Do you understand importance of statements sequence ? . . ..

Don’t teach your grandmother to suck eggs.

As a general rule, [S; T]Q ≠ [T; S]Q, but the frames of the two statements are disjoint, so it just so happens that in the code you quoted, the two statement pairs do turn out to be equivalent to each other. In generalised substitution language, those two statement pairs can be reduced to the multiple assignment

s, s1 ≔ "abc", new String("abc") // This won't compile in Java

As I said, that only works because the frames of the two statements are disjoint, and they are in fact completely independent of each other. Were there any relation between the two statements, then changing the sequence would almost certainly not work. Because "abc" is a literal, its double use does not constitute a relationship between the two statements. In fact, in GSL, its very existence is not essential to the correct operation of those two statements. As Winston said, it is only an implementation detail.

[saloni jhanwar]

Campbell Ritchie wrote:

saloni jhanwar wrote: . . . Do you understand importance of statements sequence ? . . ..

Don’t teach your grandmother to suck eggs.

As a general rule, [S; T]Q ≠ [T; S]Q, but the frames of the two statements are disjoint, so it just so happens that in the code you quoted, the two statement pairs do turn out to be equivalent to each other. In generalised substitution language, those two statement pairs can be reduced to the multiple assignment

s, s1 ≔ "abc", new String("abc") // This won't compile in Java

As I said, that only works because the frames of the two statements are disjoint, and they are in fact completely independent of each other. Were there any relation between the two statements, then changing the sequence would almost certainly not work. Because "abc" is a literal, its double use does not constitute a relationship between the two statements. In fact, in GSL, its very existence is not essential to the correct operation of those two statements. As Winston said, it is only an implementation detail.

I am not getting that what are you all telling me which i did never ask till now.It is not bad to read previous posts to get current affair.The matter was how String objects are being created on pool and heap when these two statements execute in different order that's it.And these two statement will behave totally different while they will execute,and this matter i am telling him.Is anything wrong in it ?

String s ="abc";
String s1 = new String("abc");

String s ="abc"; statement will look first for "abc" literal on pool but as there is no any presently ,so it will create an object s on pool and will do place a "abc" literal on pool.Now when next statement String s1 = new String("abc") will execute then it will create object s1 on heap and it will look into pool also at same time but now as there is already "abc" literal present so it wont do place any duplicate.This story will the end here.

Now if we change the order of statements

String s1 = new String("abc");
String s ="abc"; 

String s1 = new String("abc"); will create s1 object on heap and will look into pool but as there is no "abc" literal present so it will create another new object "abc" on pool and this "abc" literal would be place there.So now when next statement String s ="abc"; will execute it wont create any new object on pool because there is already "abc" literal is present.This story the end here.

[Aniruddh Joshi]

Campbell Ritchie wrote:

saloni jhanwar wrote: . . . Do you understand importance of statements sequence ? . . ..

Don’t teach your grandmother to suck eggs.

[saloni jhanwar]

Campbell Ritchie wrote:

saloni jhanwar wrote: . . . Do you understand importance of statements sequence ? . . ..

Don’t teach your grandmother to suck eggs.

Yes, i know you are grandmother but you should look carefully i did quote a greenhorn not you grandmother.

[Henry Wong]

Aniruddh Joshi wrote:

Campbell Ritchie wrote:

saloni jhanwar wrote: . . . Do you understand importance of statements sequence ? . . ..

Don’t teach your grandmother to suck eggs.

saloni jhanwar wrote:

Campbell Ritchie wrote:

saloni jhanwar wrote: . . . Do you understand importance of statements sequence ? . . ..

Don’t teach your grandmother to suck eggs.

Yes, i know you are grandmother but you should look carefully i did quote a greenhorn not you grandmother.

FYI.... Campbell is from the UK. And that is just an idiom that they use there. Please avoid trying to interpret the meaning -- just look it up instead.

Henry

[Aniruddh Joshi]

Apologies. I didn't interpret it wrong, actually I found Campbell's comment an example of efficient moderation.

[Stuart A. Burkett]

saloni jhanwar wrote:The matter was how String objects are being created on pool and heap when these two statements execute in different order that's it.And these two statement will behave totally different while they will execute,and this matter i am telling him.Is anything wrong in it ?

As Campbell has said, those two lines will behave exactly the same. A String object containing the value "abc" will be created in the String pool when the class is loaded. That string will exist even if those two lines of code are never executed.
Therefore the line

String s ="abc";

will simply cause s to reference the already existing String from the pool and the line

String s1 = new String("abc");

will create a new String object which will be referenced by s1 and will have the same value as the String in the pool.
Therefore the order of excution is irrelevant

[saloni jhanwar]

Stuart A. Burkett wrote:

saloni jhanwar wrote:The matter was how String objects are being created on pool and heap when these two statements execute in different order that's it.And these two statement will behave totally different while they will execute,and this matter i am telling him.Is anything wrong in it ?

As Campbell has said, those two lines will behave exactly the same. A String object containing the value "abc" will be created in the String pool when the class is loaded. That string will exist even if those two lines of code are never executed.
Therefore the line

String s ="abc";

will simply cause s to reference the already existing String from the pool and the line

String s1 = new String("abc");

will create a new String object which will be referenced by s1 and will have the same value as the String in the pool.
Therefore the order of excution is irrelevant

Stuart A. Burkett wrote:That string will exist even if those two lines of code are never executed.

Did i say they will not exist ?.i don't know what are you explaining here another different story.

when the class is loaded

s1 and s are not static variables here so they will load when class will load.and if order is irrelevant then you can explain both order if you know and you should read properly there are only two lines not four lines in same program.I am not getting why you are not getting very simple two different cases.if you will treat all code in same source file then you will end up with confusion

[Gaurangkumar Khalasi]

I think there is a misinterpretation of the statement: " Java will create a new String object(for String s = new String("abc");) in normal (non-pool) memory, and s will refer to it. In addition, the literal "abc" will be placed in the pool"; given in the K&B.

If you will read it carefully, you can realize that s will only refer to the object created at normal(heap) memory and not to the literal placed in the pool.

So, for the following example:

class Example2 
{
	public static void main(String[] args) 
	{
		String s1=new String("abc"); 
//s1 points to the newly created heap object and as literal "abc" is not available into the pool, 
//it will be created but no one will refer to it.  
//::::So two objects created here.
		String s2="abc";
//Here, s2 will points to the literal already avaiable into the pool. ::: No objects created.
		System.out.println("s1==s2 ? "+s1==s2);//should be true
//Operator "==" used to check referential equality. 
//and as we can see s1 points to the heap object and s2 points to the literal pool's object, it will results in false. 
	}
}

and for another case

class Example1 
{
	public static void main(String[] args) 
	{
	 String s2="abc";
//Here, s2 will points to the literal created into the pool. ::: One object created.
	
	String s1=new String("abc"); 
//s1 points to the newly created heap object and as literal "abc" is available into the pool, it will not be created.  
//:::: One object created here.
	
		System.out.println("s1==s2 ? "+s1==s2);//should be true
//And as we can see s1 points to the heap object and s2 points to the literal pool's object, it will results in false. 
	}
}

[saloni jhanwar]

Gaurangkumar Khalasi wrote:I think there is a misinterpretation of the statement: " Java will create a new String object(for String s = new String("abc");) in normal (non-pool) memory, and s will refer to it. In addition, the literal "abc" will be placed in the pool"; given in the K&B.

If you will read it carefully, you can realize that s will only refer to the object created at normal(heap) memory and not to the literal placed in the pool.

So, for the following example:

class Example2 
{
	public static void main(String[] args) 
	{
		String s1=new String("abc"); 
//s1 points to the newly created heap object and as literal "abc" is not available into the pool, 
//it will be created but no one will refer to it.  
//::::So two objects created here.
		String s2="abc";
//Here, s2 will points to the literal already avaiable into the pool. ::: No objects created.
		System.out.println("s1==s2 ? "+s1==s2);//should be true
//Operator "==" used to check referential equality. 
//and as we can see s1 points to the heap object and s2 points to the literal pool's object, it will results in false. 
	}
}

and for another case

class Example1 
{
	public static void main(String[] args) 
	{
	 String s2="abc";
//Here, s2 will points to the literal created into the pool. ::: One object created.
	
	String s1=new String("abc"); 
//s1 points to the newly created heap object and as literal "abc" is available into the pool, it will not be created.  
//:::: One object created here.
	
		System.out.println("s1==s2 ? "+s1==s2);//should be true
//And as we can see s1 points to the heap object and s2 points to the literal pool's object, it will results in false. 
	}
}

if you are answering of first question then it is waste now topic has been changed,whatever you are telling is old i knew it.

[Stuart A. Burkett]

saloni jhanwar wrote:s1 and s are not static variables here

Irrelevant.

You said

saloni jhanwar wrote:String s ="abc"; statement will look first for "abc" literal on pool but as there is no any presently ,so it will create an object s on pool and will do place a "abc" literal on pool.

That is wrong.
If the classloader finds any String literals (which is what "abc" is) in the class code when it loads it, it will create a String object in the string pool during the loading of the class. Therefore before any line of code that uses the literal "abc" is excuted, the String will already exist in the string pool.

[saloni jhanwar]

Stuart A. Burkett wrote:

saloni jhanwar wrote:s1 and s are not static variables here

Irrelevant.

You said

saloni jhanwar wrote:String s ="abc"; statement will look first for "abc" literal on pool but as there is no any presently ,so it will create an object s on pool and will do place a "abc" literal on pool.

That is wrong.
If the classloader finds any String literals (which is what "abc" is) in the class code when it loads it, it will create a String object in the string pool during the loading of the class. Therefore before any line of code that uses the literal "abc" is excuted, the String will already exist in the string pool.

so what i were saying ? are you telling something different ? and what is wrong you are also saying same thing. and it doesn't make any sense that it will create at loading phase or not.that is irrelevant.

[Henry Wong]

saloni jhanwar wrote:

Stuart A. Burkett wrote:

saloni jhanwar wrote:s1 and s are not static variables here

Irrelevant.

You said

saloni jhanwar wrote:String s ="abc"; statement will look first for "abc" literal on pool but as there is no any presently ,so it will create an object s on pool and will do place a "abc" literal on pool.

That is wrong.
If the classloader finds any String literals (which is what "abc" is) in the class code when it loads it, it will create a String object in the string pool during the loading of the class. Therefore before any line of code that uses the literal "abc" is excuted, the String will already exist in the string pool.

so what i were saying ? are you telling something different ? and what is wrong you are also saying same thing. and it doesn't make any sense that it will create at loading phase or not.that is irrelevant.

Saloni,

Stuart is just trying to correct you -- admittedly on a subtle point, but he is correct.

And whether or not you are / were saying the same thing, your previous post did come across as otherwise.

Henry

[saloni jhanwar]

Henry Wong wrote:

saloni jhanwar wrote:

Stuart A. Burkett wrote:

saloni jhanwar wrote:s1 and s are not static variables here

Irrelevant.

You said

saloni jhanwar wrote:String s ="abc"; statement will look first for "abc" literal on pool but as there is no any presently ,so it will create an object s on pool and will do place a "abc" literal on pool.

That is wrong.
If the classloader finds any String literals (which is what "abc" is) in the class code when it loads it, it will create a String object in the string pool during the loading of the class. Therefore before any line of code that uses the literal "abc" is excuted, the String will already exist in the string pool.

so what i were saying ? are you telling something different ? and what is wrong you are also saying same thing. and it doesn't make any sense that it will create at loading phase or not.that is irrelevant.

Saloni,

Stuart is just trying to correct you -- admittedly on a subtle point, but he is correct.

And whether or not you are / were saying the same thing, your previous post did come across as otherwise.

Henry

Ok i got that what he was saying but i am not asking when literal will load and how they will load, topic was different about two object creations through new keyword one on heap and another on pool.

[Stuart A. Burkett]

So do you have your answer ? If not, you may want to ask it again (possibly in a new thread) as it seems to have got lost in this thread.

[saloni jhanwar]

Stuart A. Burkett wrote:So do you have your answer ? If not, you may want to ask it again (possibly in a new thread) as it seems to have got lost in this thread.

I just got answer.Because no one is explaining both thing together.Some people telling difference between == and equals ,Some people telling half story blah blah.and unfortunately you are also telling half story.

but i would like to tell whole story.

String s1="abc";
String s=new String("abc");

you told when class loader will find any String literal in class then class loader will load that literal on pool and an object would be instantiate.fine

but what about second half story about next statement ? no one is telling second half.You all are repeat half story.

When second statement will execute it will create object on heap, now as "abc" literal is already loaded so it wont place any duplicate.and important thing is here that these both statements will execute together at same time not only literal statement.

[Winston Gutkowski]

saloni jhanwar wrote:...and important thing is here that these both statements will execute together at same time not only literal statement.

No they won't. They will be executed sequentially, and in the order they appear. What's almost certain though is that "abc" will be loaded into the pool before either statement is executed (indeed, very possibly before anything is initialized).

Winston

[saloni jhanwar]

Winston Gutkowski wrote:

saloni jhanwar wrote:...and important thing is here that these both statements will execute together at same time not only literal statement.

No they won't. They will be executed sequentially, and in the order they appear. What's almost certain though is that "abc" will be loaded into the pool before either statement is executed (indeed, very possibly before anything is initialized).

Winston

Yes, Constructor should run after that literal loading.

[Stuart A. Burkett]

saloni jhanwar wrote:but i would like to tell whole story.

String s1="abc";
String s=new String("abc");

you told when class loader will find any String literal in class then class loader will load that literal on pool and an object would be instantiate.fine

but what about second half story about next statement ? no one is telling second half.You all are repeat half story.

I believe I gave you the whole story in my first post. If not then you need to explain what you you still don't understand.

Stuart A. Burkett wrote:A String object containing the value "abc" will be created in the String pool when the class is loaded. That string will exist even if those two lines of code are never executed.
Therefore the line

String s ="abc";

will simply cause s to reference the already existing String from the pool and the line

String s1 = new String("abc");

will create a new String object which will be referenced by s1 and will have the same value as the String in the pool.
Therefore the order of excution is irrelevant