aspose file tools*
The moose likes Beginning Java and the fly likes String object ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "String object ?" Watch "String object ?" New topic
Author

String object ?

Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
In the code below, x1, x2 will point to different object ? I think because String is immutable, keep a string pool, x1, x2 should refer to same object , is it correct ?
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14688
    
  16

x1, x2 will point to different object ?

Yes, anything you instanciate using "new" will be a new instance.

I think because String is immutable, keep a string pool

This is true for x and y.

This journal article will help you.


[My Blog]
All roads lead to JavaRanch
manoj r patil
Ranch Hand

Joined: Jun 06, 2002
Posts: 181
"new" forces JVM to create new instance each time so x1 is not equal to x2. In the first case, if JVM finds the string literal in the heap, it points to that address location so you get the same pointers assigned to those objects.


love your job and not your company;
...because you never know when your company will stop loving you!
Monu Tripathi
Rancher

Joined: Oct 12, 2008
Posts: 1369
    
    1

mannoj patil wrote:.... In the first case, if JVM finds the string literal in the heap, it points to that address location so you get the same pointers assigned to those objects.


Constant string pool to be exact...


[List of FAQs] | [Android FAQ] | [Samuh Varta]
Embla Tingeling
Ranch Hand

Joined: Oct 22, 2009
Posts: 237
Edward Chen wrote:In the code below, x1, x2 will point to different object ? I think because String is immutable, keep a string pool, x1, x2 should refer to same object , is it correct ?


It has nothing to do with immutability or some "string pool".

It's very simple. in Java each different String literal, like "abc", is represented by exactly one String object. Each time you use "abc" you're in fact using the one and only unique object which represent it. Also in Java each time you use the new keyword a new object is created.

So what happens when you do this?

String x = "abc";
String y = "abc";

Here the reference to the unique String object which repesents "abc" is assigned to both x and y.

And when you do this?

String x1 = new String("abc");
String x2 = new String("abc");

Here the the reference to the unique String object which repesents "abc" is passed to a String constructor which uses it to create a brand new object which reference is assingned to x1. The same is once again repeated for x2.

So afterwards x and y hold the same reference which is different from the reference held by x1 which is different from the reference held by x2.
Monu Tripathi
Rancher

Joined: Oct 12, 2008
Posts: 1369
    
    1

uj nossnahoj wrote:
It has nothing to do with immutability or some "string pool".

It's very simple. in Java each different String literal, like "abc", is represented by exactly one String object. Each time you use "abc" you're in fact using the one and only unique object which represent it. Also in Java each time you use the new keyword a new object is created.


What you've explained is called "String interning". In Java, there is a "string intern pool" for the same. So, I think they are all related.
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3855

All literal strings and string-valued constant expressions are interned (maintained in a private pool).


SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Embla Tingeling
Ranch Hand

Joined: Oct 22, 2009
Posts: 237
Monu Tripathi wrote:
What you've explained is called "String interning". In Java, there is a "string intern pool" for the same. So, I think they are all related.


The Java language is best undertood at the Java language level. The relevant section is 3.10.5 String Literals in the JLS,

---
A string literal always refers to the same instance (§4.3.1) of class String.
---

It's my emphasis. This states that a certain String literal is represented by the same unique String object regardless of how many times the literal appears.

String literals behave like this for no other reason than that this is how Java defines them to behave. There's no further explanation for it. It is the way it is because that's the way the Java designers decided it should be.
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3855

uj nossnahoj wrote:
---
A string literal always refers to the same instance (§4.3.1) of class String.
---
This states that a certain String literal is represented by the same unique String object regardless of how many times the literal appears.

Yes. "The pool of String references", that's how it is achieved.
Embla Tingeling
Ranch Hand

Joined: Oct 22, 2009
Posts: 237
Vijitha Kumara wrote:
Yes. "The pool of String references", that's how it is achieved.


That's right.

The fact that the String class internally maintains a pool (see Sun's API documentation to the intern() method of String) doesn't explain the behaviour of String literals. Their behaviour is explained solely by how they're defined to behave in the JLS, nothing else.
Monu Tripathi
Rancher

Joined: Oct 12, 2008
Posts: 1369
    
    1

And when I said:
Monu Tripathi wrote:What you've explained is called "String interning". In Java, there is a "string intern pool" for the same. So, I think they are all related.
I was commenting on:
uj nossnahoj wrote:It has nothing to do with immutability or some "string pool".


I was trying to bring to your notice that the very same feature you talked about in the rest of your post is implemented using this common pool and that interning IS related to immutability.


Monu Tripathi
Rancher

Joined: Oct 12, 2008
Posts: 1369
    
    1

The fact that the String class internally maintains a pool (see Sun's API documentation to the intern() method of String) doesn't explain the behaviour of String literals. Their behaviour is explained solely by how they're defined to behave in the JLS, nothing else.


Point taken; abstraction is bliss!
karimkhan pathan
Ranch Hand

Joined: Jul 14, 2008
Posts: 86



output :
The hashcode for S 96354
The hashcode for K 96354
The new hashoce 96354


Can i now why it is showing the same hashcode when i try to use the new operator .


karim
Embla Tingeling
Ranch Hand

Joined: Oct 22, 2009
Posts: 237
karimkhan pathan wrote:
Can i now why it is showing the same hashcode when i try to use the new operator .


Yes you can. The result of hashCode of String is based on object content, not object reference (and this is true for all classes which override the hashCode method of the Object class).

So all String objects containing "abc" will return the same hashCode regardless of object reference.

In fact you can even know how the hash code is calculated. Have a look at the hashCode method of String in the documentation to the Sun API for example.
Vivek Singh
Ranch Hand

Joined: Oct 27, 2009
Posts: 92
Lets do this:-



Well the output is :-
The hashcode for S 96354
The hashcode for K 96354
The new hashcode for M 96354
The new hashcode for O 96354

So the hascode():- Returns a hash code for this string("abc"). The hash code for a String object is computed as
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] thats why its same for all.


Embla Tingeling
Ranch Hand

Joined: Oct 22, 2009
Posts: 237
Monu Tripathi wrote:I was trying to bring to your notice that the very same feature you talked about in the rest of your post is implemented using this common pool and that interning IS related to immutability.


Possibly, but Java is not defined by how it's implemented. Java is defined by the JLS.

It's important to understand this. Explanations as to how Java "works" based on observed behaviour and possible implementations are misleading and confusing. Java works the way it does because it's defined to work that way.
karimkhan pathan
Ranch Hand

Joined: Jul 14, 2008
Posts: 86
The hash code for a String object is computed as
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] thats why its same for all.


This means that String class overrides the hash code method of the Object class.

Vivek Singh
Ranch Hand

Joined: Oct 27, 2009
Posts: 92
karimkhan pathan wrote:
The hash code for a String object is computed as
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] thats why its same for all.


This means that String class overrides the hash code method of the Object class.


Well Object class is Super of all classes.This Expression s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1] is used to calculate hashcode
Embla Tingeling
Ranch Hand

Joined: Oct 22, 2009
Posts: 237
karimkhan pathan wrote:
This means that String class overrides the hash code method of the Object class.


That's right. The Object class is the implicit superclass of every other class so every class automatically inherits the methods of Object and are free to override them if they want to.

The hashCode method of Object uses object references to calculate the hash code. And also the equals method of Object uses object references to decide whether objects are equal.

Classes which want to instead base equality on object content should override the equals and the hashCode methods together. (consult the documentation to these methods in the Sun API for example). Most "standard" classes like String, Integer, Date, etcetera do that.
karimkhan pathan
Ranch Hand

Joined: Jul 14, 2008
Posts: 86
Thanks a lot ..that was helpful ..
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: String object ?