The biggest gamble will be to ask a question whose answer you know in that it will challenge your theory | www.TechAspire.blogspot.in
Tim Driven Development | Test until the fear goes away
Hint: look at lines 7, 12 and 27.javac WordDemo.java
javap -c WordDemo
It's actually quite simple; you may get a hint from looking at lines 7 12 and 27 in my last example.Tim Cooke wrote: . . . I do not fully understand how it works and don't tend to concern myself too much as it's mostly academic. . . .
Hint: look at lines 7, 12 and 27.
Campbell Ritchie wrote:It's actually quite simple; you may get a hint from looking at lines 7 12 and 27 in my last example.
Tim Driven Development | Test until the fear goes away
Campbell Ritchie wrote:I meant 7 12 27 after running the javap -c call. Sorry if I wasn't clear.
Rajdeep Biswas wrote:
Sorry for late reply Campbell and others for late reply. This is going to be awesome learning, not now though, as nothing solid grasped.
string "length: " was created --> String pig's length was calculated ---> StringBuilder.append() object created and method attached and the int length passed ---> toString() --> "length: 10"
But can you explain more on the javap -c output, and relate this to the String pooling (some more insight)..
Thanks All,
Raj
PS. == was used intentionally to check the reference for stirring string pooling concepts in my mind.
Rajdeep Biswas wrote:Somewhere I learned that when we return a string from a method, it create a new string in memory.
But here, for dog, "length: " was present. 10 was calculated from method, and this was subjected to toString() method,
and that gave me "10" from 10.
now, after concatenating, i got "length: 10" and a same literal already exists for pig in the pool. so why a new object was created?
Edit: I think StringBuilder was used when I called the length() method and so a new object was created, and dog is referring to the newer one. pig refers to original "length: 10" literal only. Am I right?
Rajdeep Biswas wrote:
and this returns true:
?
No, you are mistaken on that point. The compile‑time literal Strings are worked out by the compiler at compile‑time, and you can see them in the bytecode. In that case "length: ", as in my line 7. Remember that bytecode has never been executed, so there is nothing loaded. Also the ...length() method has not been executed at that stage.Rajdeep Biswas wrote: . . .
"length: " was created in heap, say 1011 address, placed in pool.
String pig's length was calculated ---> StringBuilder.append() : object created and method attached and the int length 10 passed . . .
Rajdeep Biswas wrote:
Why this returns false:
Tim Driven Development | Test until the fear goes away
Campbell Ritchie wrote: although it is interned as a compile-time constant, it is not needed by this code.
Henry Wong wrote:And here is the interesting part, it is not clear if this string needs to be interned yet
manish ghildiyal wrote:
Henry Wong wrote:And here is the interesting part, it is not clear if this string needs to be interned yet
Does it mean that only those literals are interned which are reused in program?
So if my program consists of only:
String str = "abc";
....then "abc" won't be interned.
But if my program is as:
String str = "abc";
String str1 = "abc";
....now "abc" would be interned.
The biggest gamble will be to ask a question whose answer you know in that it will challenge your theory | www.TechAspire.blogspot.in
I'm sure glad that he's gone. Now I can read this tiny ad in peace!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|