valueOf

[Cathy Song]

Hi,
Can some please explain how this statement is valid?
System.out.println("12345 ".valueOf(54321));
Thanks,
Cathy.

[Alton Hernandez]

Originally posted by Cathy Song:
Hi,
Can some please explain how this statement is valid?
System.out.println("12345 ".valueOf(54321));
Thanks,
Cathy.

There's nothing strange here. "12345" is considered as a String object and the String class have a number of static methods called valueOf(). So it is perfectly legal to invoked it that way.
[ October 01, 2003: Message edited by: Alton Hernandez ]

[Marlene Miller]

System.out.println("12345 ".valueOf(54321));
valueOf is a static method of the String class. Usually we invoke a static method using the class name, String.valueOf(54321).
But we can also invoke a static method using a String variable, s.valueOf(54321), or reference to a String object, new String("12345").valueOf(54321) or "12345".valueOf(54321).
String a = String.valueOf(54321); //normal
String s1 = null;
String b = s1.valueOf(54321); // s1 is of type String
String s2 = �12345�;
String c = s2.valueOf(54321); // s2 is of type String
String d = �12345�.valueOf(54321); // �12345� is of type String
�12345� is String literal. A String literal represents a value. It is not an object, it is a reference to a String object.
[ October 01, 2003: Message edited by: Marlene Miller ]

[Barkat Mardhani]

Posted by Marlene:

�12345� is String literal. A String literal represents a value, not an object. It is a reference to a String object.

Did you say not an object?
I just do not want to lose my sanity over this string mumbo jumbo again...
My understanding is that:
1. String literals such as "12345" are String object.
2. It happens that jvm creates these objects at runtime in special memory pool called string constant pool.
3. This way all string constants can be shared by multiple references from different threads ( furthermore different parts of code ), to conserve memory at run time.
4. And because different references are sharing same string literal objects, it is wise to make them immutable.
Please let me know if there are any holes in my understanding. I really do not want to revisit this again.
Thanks
Barkat

[Marlene Miller]

Hi Barkat.
String s = new String(�12345�);
s is a variable. s holds a value. That value is a reference to a String object.
String t = �12345�;
t is a variable. t holds a value. That value is a reference to a String object.
�12345� is a value. It is a reference to a String object. The value of the variable t and the value �12345� refer to the same String object.
To be more precise, "12345" is the source code representation of a value.
[ October 02, 2003: Message edited by: Marlene Miller ]

[Barkat Mardhani]

Hi Marlene:

Hi Barkat.
String s = new String(�12345�);
s is a variable. s holds a value. That value is a reference to a String object.
String t = �12345�;
t is a variable. t holds a value. That value is a reference to a String object.
�12345� is a value. It is a reference to a String object. The value of the variable t and the value �12345� refer to the same String object.
To be more precise, "12345" is the source code representation of a value.
Learning is a spiral. You learn something. Then you revisit it and learn some more.

Thanks for your prompt response. If you are saying for:
String t = "12345";
1. t is a variable,
2. t holds a value "12345",
3. t and the value "12345" both reffer to String object that was created when above statement was executed.
Then my understanding is somewhat different:
1. t is a variable,
2. t holds a bit pattern (not related to literal "12345"),
3. this bit pattern holds a memory address
4. at that memory address a String object is created whose value is happens to be "12345".
Now let us assume for second that string objects are not immutable. And change the string to "678910". t is not changed. The bit pattern that t is holding does not change. Only object at that memory location is changed in a limited way.
Hope I am making my point clear enough?
Here is quote from K & B:

You might need to remind yourself what the value of a reference variable actually
is. A reference variable�s value�in other words, the bit pattern the variable holds�is
not an object. Just as the value of a primitive variable is the bit pattern representing
the primitive (for example, the bits representing the integer value 2), the value of
a reference variable is a bit pattern representing, well, a reference. We�re not using
�traditional� pointers in Java, but you can still think of it as a pointer (not necessarily
a pointer to an object, but a pointer to a pointer to�). A reference variable holds
bits that represent, in a platform-dependent format, a way to get to an object. That�s
really all we care about, and all we�re even allowed to know about reference variables
in Java, unless you happen to be one of the developers of a JVM.

[Dan Chisholm]

Barkat,
I don't think that Marlene suggested statement number 2.

String t = "12345";
1. t is a variable,
2. t holds a value "12345",
3. t and the value "12345" both reffer to String object that was created when above statement was executed.

I think that Marlene said the following.

t holds a value. That value is a reference to a String object.

I think that you and Marlene will both agree on that, but I think that Marlene will probably prefer to call that value a "reference" rather than use the term "memory address" as you have.

[Barkat Mardhani]

Hi Dan, Marlene:
I guess we a have language issue here:
When you see notation "12345" you see a reference to an object.
When I see notation "12345" I see the object.
If we go with your perception, then for:
String s = "12345";
s and "12345" represent same thing (... I mean reference... )
therefore we can write:
s.valueOf("ABC");
which is equivalent to:
"12345".valueOf("ABC");
This is great as long as we are talking string literals. If we move to string objects on the heap created with new operator such as:
String s2 = new String("12345");
Now s2 and "12345" are references alright but refferring to different objects; one on the heap and one in pool.
Barkat
[ October 02, 2003: Message edited by: Barkat Mardhani ]

[Marlene Miller]

According to JLS 3.10.5

Each string literal is a reference (�4.3) to an instance (�4.3.1, �12.5) of class String (�4.3.3).

According to JVMS 5.1

The Java programming language requires that identical string literals (that is, literals that contain the same sequence of characters) must refer to the same instance of class String.

Clue #1:

class Test {
   void m() { String t = "12345";  }
}
Method void m()
   0 ldc #2 <String "12345">
   2 astore_1
   3 return

ldc index
The index is an unsigned byte that must be a valid index into the runtime constant pool of the current class (�3.6).
the runtime constant pool entry must be a reference to an instance of class String representing a string literal (�5.1). A reference to that instance, value, is pushed onto the operand stack.
----
Clue #2: According to JVMS 5.1
A string literal (�2.3) is derived from a CONSTANT_String_info structure (�4.4.3) in the binary representation of a class or interface. The CONSTANT_String_info structure gives the sequence of Unicode characters constituting the string literal.
To derive a string literal, the Java virtual machine examines the sequence of characters given by the CONSTANT_String_info structure.
o If the method String.intern has previously been called on an instance of class String containing a sequence of Unicode characters identical to that given by the CONSTANT_String_info structure, then the result of string literal derivation is a reference to that same instance of class String.
o Otherwise, a new instance of class String is created containing the sequence of Unicode characters given by the CONSTANT_String_info structure; that class instance is the result of string literal derivation. Finally, the intern method of the new String instance is invoked.

[Marlene Miller]

We write �12345� in our source code. The compiler stores the 5 characters 12345 in a symbol table in the class file, and uses the byte-code ldc (push reference from run-time constant pool onto the stack).
At run-time, the first time the ldc instruction is executed, a String object is created and a reference is returned.
All references in the run-time constant pool of a class are initially symbolic. I don't have this next part entirely sorted out. I think the reference to the String object somehow replaces the symbol 12345.
A String object has a field char[] value. That field refers to an array object that holds a length field and the five 16-bit Unicode characters for 1 2 3 4 5.
[ October 02, 2003: Message edited by: Marlene Miller ]

[Alton Hernandez]

Originally posted by Marlene Miller:
�12345� is String literal. A String literal represents a value. It is not an object, it is a reference to a String object.

When I was answering this post, I almost made the mistake of calling "12345" as a String literal although I know that it is more accurate to call it that. That is why my sentence is a little bit on the safe side i.e. I use the word "considered" and never calling "12345" a literal or an object. Because if I did, I will be opening myself up for more questions.
But I do agree with Marlene, and this is how I can simply explain it. "12345" is a String literal. But that literal will be used to create a String object. And when you use it to perform a String function, say "12345".substring(), you are asking Java to substring() an object that was created from that String literal. So in effect, that String literal is the reference to an object.

Originally posted by Barkat Mardhani:
Now s2 and "12345" are references alright but refferring to different objects; one on the heap and one in pool.

I believe it is incorrect to say that there are objects in the constant pool. Objects lives in the heap. The constant pool is simply a table of symbols. There are no objects there.

[Marlene Miller]

1. int[] a = { 1,2,3 };
a is a reference to an array object. The array object has 3 variables of type int. The variables hold the values 1,2,3.
2. class C {} class B extends C {}
C[] c = { new C(), new B() };
c is a reference to an array object. The array object has 2 variables of type C. The first variable holds a reference to a C object. The second variable holds a reference to a B object.
3. String[] s = { new String(��), �12345� }
s is a reference to an array object. The array object has 2 variables of type String. The first variable holds a reference to a String object. The second variable holds a reference to a String object.
new String(��) returns a reference to a String object.
�12345� is a reference to a String object.
[ October 02, 2003: Message edited by: Marlene Miller ]

[Jose Botella]

Now s2 and "12345" are references alright but referring to different objects; one on the heap and one in pool.

Both objects lives in the heap. No object inhabits the contant pool. The difference is that the object pointed to by "12345" has been interned; and the one by s2 hasn't.
__________________________________________________________________________

All references in the run-time constant pool of a class are initially symbolic. I don't have this next part entirely sorted out. I think the reference to the String object somehow replaces the symbol 12345.

The Constant Pool of a class or interface holds (among other things) symbolic references to other types used by the class or interface. Linking in Java is made at runtime, and involves the resolution of such references to direct ones. "Direct ones" means native pointers to memory addresses. For instance, the CONSTANT_Class_info entry in the constant pool should be resolved to the address were the data for a class or interface was loaded by the JVM.
JVM implementations may take different approaches about the time it resolves the entries in the constant pool: it might resolve all of them in the orginal class and the subsequent types loaded before main was called. This is called early resolution. It is likely that another approach is used, late resolution, in which entries are linked right before its first used.
Once a constant pool entry has been resolved any access to it will use the direct reference. Thus I think it is very likely that symbolic references are replaced by direct ones, instead of just adding the direct reference to the "runtime constant pool".