Jesper de Jong wrote:Suppose that it did, where would that return value then go to?
What do you think is calling the static initializer (and when)?
Ritesh raushan wrote:to initailize static state and at the time of loading the class.
and i also want to know where memory alocated for final variable and return value.
i think final variable in heap and return value in stack. am i write.please explain this also.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Ritesh raushan wrote:
i think final variable in heap and return value in stack. am i write.please explain this also.
Campbell Ritchie wrote:Which is why you won’t find such information in the JLS...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
It might not be there, either, if it is an implementation detail.Winston Gutkowski wrote: . . . It'll be in the JVM specification. . . .
Campbell Ritchie wrote:It might not be there, either, if it is an implementation detail.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Quite right, too. You have better things to think about. I need to know that sort of thing when I am writing my compiler in FORTH, but ordinary users of Java don’t need that info at all.Winston Gutkowski wrote: . . . I couldn't be fagged to find out whether it specifies where specific things like return values are put. . . .
Winston
Jeff Verdegan wrote:
Ritesh raushan wrote:
i think final variable in heap and return value in stack. am i write.please explain this also.
All local variables always go on the stack, whether they are final or not.
All object and all their member variables, all class definitions, all constant pools, go on the heap. The only exception to this is that starting at some point in Java 6, the JVM spec apparently allows objects to be created on the stack of escape analysis can prove that they won't live beyond the method invocation.
But, as already pointed out, that knowledge is not generally useful to a Java developer. In 14 years of Java development, that knowledge has never once affected how I write my code.
Campbell Ritchie wrote:Implementation details.
How do you think you could create two objects? Would you really create two heaps?
Ritesh raushan wrote:sorry to say.i think only instance variable go onto the heap
Ritesh raushan wrote:one heap created for one application mean if i create two object of same class then both object share heap or created two heap for two object.
Steve
Ritesh raushan wrote:
Jeff Verdegan wrote:
Ritesh raushan wrote:
i think final variable in heap and return value in stack. am i write.please explain this also.
All local variables always go on the stack, whether they are final or not.
All object and all their member variables, all class definitions, all constant pools, go on the heap. The only exception to this is that starting at some point in Java 6, the JVM spec apparently allows objects to be created on the stack of escape analysis can prove that they won't live beyond the method invocation.
But, as already pointed out, that knowledge is not generally useful to a Java developer. In 14 years of Java development, that knowledge has never once affected how I write my code.
sorry to say.i think only instance variable go onto the heap and one pointer in heap that points method area where all information about class(all method) is stored.
and i want to know where final instance variable is stored
and one heap created for one application mean if i create two object of same class then both object share heap or created two heap for two object.
Consider Paul's rocket mass heater. |