monis raza wrote:
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 (nonpool) memory, and s will refer to it. In addition, the literal "abc" will
be placed in the pool.
Afraid not.monis raza wrote: . . . am i deciphering it correctly ?
Campbell Ritchie wrote:When do you mean they are created? Do you mean at run time or are you including class loading time? The answer will be different.
Please go through the code and count all the object references and see which point to the same object and which point to different objects on the heap.
You do realise this is pointless code which is only of use for passing exams and has no real‑life use. This sort of question appears here frequently, so please search this forum and you will find similar questions.
Campbell Ritchie wrote:You can find the JavaRanch journal article by clicking the underlined text in my previous post.
Campbell Ritchie wrote:
Afraid not.monis raza wrote: . . . am i deciphering it correctly ?
In this case, we actually end up with a slightly different behavior because of the keyword "new." In such a case, references to the two String literals are still put into the constant table (the String Literal Pool), but, when you come to the keyword "new," the JVM is obliged to create a new String object at run-time, rather than using the one from the constant table.
In such a case, although the two String references refer to String objects that contain the same data, "someString", they do not refer to the same object. That can be seen from the output of the program. While the equals() method returns true, the == operator, which checks for referential equality, returns false, indicating that the two variables refer to distinct String objects.
Once again, if you'd like to see this graphically, it would look something like this. Note that the String object referenced from the String Literal Pool is created when the class is loaded while the other String object is created at runtime, when the "new String..." line is executed.
Ulf Dittmer wrote:Note that the answer could also be "hundreds" or possibly "thousands", because the JVM will create a great many objects on its own while it runs this code.
Campbell Ritchie wrote:Runtime only? That is easy enough. But it isn't 3 and it isn't 5.
Ulf Dittmer wrote:Just to confuse matters further: Given that the code does not do anything with any of the strings, it may well be that that all the code is optimized away by the compiler, so that no String objects are created at all.
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, Line X
// and one reference variable
In this case, because we used the new keyword, Java will create a new String object
in normal (nonpool) memory, and s will refer to it. In addition, the literal "abc" will
be placed in the pool.
Campbell Ritchie wrote:That is not clear. If you put those two lines together, their behaviour is different. In the case of the line marked X, there can only be two objects if it is executed by a different JVM from that which executes the earlier line. You need to be clear. If you execute all those lines together that line X will not create two objects. What is more, if you assume that the first line creates one String object and the second two String objects, and apply it to your example, you will get a completely wrong answer.
Let us get back to your original posting. Let us confine ourselves to String objects which can be seen in the code. Tell us how many such String instances are created on the heap when that code is loaded, as opposed to the many objects which are created as parts of the JVM. Then tell us how many String objects are created when the code is executed.
Campbell Ritchie wrote:Wrong. At class loading time there is one String object, because all the String literals are identical.
At runtime each of the new String(...) calls will create one object, making another two. Now you have three.
Prajakta Acharya gave the correct answer yesterday and you appear to have overlooked it.
I think you are correct.Mike Simmons wrote:When did "loading time" become something separate from "runtime"? That's very confusing. Loading is part of run time. Different classes can be loaded at different times, all during run time.
I think it would be more useful to say that one instance is created when the class loads, and two more are created when the main() method is executed. All of which occurs during run time.
I am not a spy. Definitely. Definitely not a spy. Not me. No way. But this tiny ad ...
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|