Definition of a Java object

[Keith L]

Hi All,

I was wondering if there is anyone in here who could help me to understand a question in K&Bs guide to the SCJP exam. We've been discussing it in this thread in the SCJP forum. I'm trying to understand exactly what consititues an object in Java. Specifically, does placing a literal in the String Buffer pool constitute creating an object? If so, by what definition of an object.

Here is the question from the book. What definition of object is the basis for saying that line 13 creates two objects?

-------------------------------------------------------------------
Question

Given the following,
13. String x = new String("xyz");
14. y = "abc";
15. x = x + y;

how many String objects have been created?

A. 2
B. 3
C. 4
D. 5
-------------------------------------------------------------------

Answer

C. Line 13 creates two, one referred to by x and the lost String �xyz�. Line 14 creates one (for a total of three). Line 15 creates one more (for a total of four), the concatenated String referred to by x with a value of �xyzabc�.
--------------------------------------------------------------------

Thanks,
Keith
[ May 25, 2004: Message edited by: Keith Leng ]

[Stan James]

I think the 1 counted in line 14 is not the "abc" in the literal pool, but the new String that y is going to point to. If you're not sure y is pointing to a newly created string, imagine that y == null before and now it points to a string.

I resent being asked to think about the literal pool. This is an example of test authors trying to make you read the manuals late into the night.

That should be a JVM implementation decision. If we optimize code for JVM design a future JVM could do us real harm by changing some internal algorithm. When Mike Cowlishaw invented the REXX langauge he emphasized that developers should write code for human readability and let him optimize the interpreter, because if they tried to use knowledge of how he did things any change he made could have disasterous results. That's a proper attitude!

I do tell people not to write "x = new String("Y");" but just because it adds verbiage with no value to the reader. Write for humans.
[ May 25, 2004: Message edited by: Stan James ]

[Greg Reinl]

The constructor String("xyz") takes a String object as the argument and uses it to construct a new String object. So the literal "xyz" is the first String object and the object constructed by

 new String("xyz") 

is the second String object.

[Stefan Wagner]

In my feeling this is a literal String and not an Object.
The whole question is hairsplitting, but to take an String object as parameter in the constructor looks like this:

String str = ...
 
... = new String (str);

[ May 26, 2004: Message edited by: Stefan Wagner ]

[Tony Morris]

I agree with the answer given by the book.

String x = new String("xyz");
y = "abc";
x = x + y;

4 String objects are created.
A String literal is an object.

Consider the following:

  
String s = "xyz";
String x = new String(s);
y = "abc";
x = x + y;

This performs exactly the same operation with the addition of one reference (not object) called 's'. Attempting to argue that s, an object reference, is not referring to object will fail. An object reference can be; uninitialized (if it is local), referring to null, or referring to an object. Deciding which one of the three possibilities in your case is simple. I doubt that the JLS says something like "a String literal is an object", but a String literal, although, a compile-time constant, is still represented in memory somehow (as an String instance).

[Warren Dew]

Stan James:

I think the 1 counted in line 14 is not the "abc" in the literal pool, but the new String that y is going to point to. If you're not sure y is pointing to a newly created string, imagine that y == null before and now it points to a string.

I think they are the same: after line 14 y points to the string "abc" in the literal pool. In particular, I think that y == "abc" is true after line 14, while x == "xyz" is false after line 13. I think the reason why it's specified and not left an implementation detail is because doing the latter would break "write once run anywhere" since x == "xyz" would evaluate to different things under different JVMs.

I definitely agree that the reason to do the line 14 style assignment is legibility rather than efficiency.
[ May 26, 2004: Message edited by: Warren Dew ]