I am writing a Bytecode instrumenter. Right now, I am trying to find out how to do that in the presence of objects. I would like some clarifications on two lines I read in the JVMS (section 4.9.4):
1) “The verifier rejects code that uses the new object before it has been
initialized.”
My question is, what does “uses” mean here? I’m guessing that it means: passing it as a method attribute, calling GETFIELD and PUTFIELD on it, or calling any instance method on it. Are their other forbidden uses? And I believe that it follows that other instructions such as DUP, LOAD and STORE are allowed.
2) “Before that method invokes another instance initialization method of
myClass or its direct superclass on
this, the only operation the method
can perform on this is assigning
fields declared within myClass.”
Which means that in an <init> method, GETFIELD and PUTFIELD are allowed before another <init> is called. However, in Java, doing any operation on an instance field before a call to super() or this() results in a compilation error. Could someone clarify this?
3) I have one more question. When does an object reference becomes initialized, and hence, ready to be freely used? From reading the JVMS, I came up with the answer that whether an object is initialized or not, is up to each method. At a certain point in time, the object can be initialized for a method but not for the other. Specifically, an object becomes initialized for a method when <init> called by that method returns.
For example, consider that the main() method created an object and called <init> which then called the superclass’s <init>. After returning from super(), the object is now considered initialized by <init> , but is not yet initialized for main(). Does this mean, in <init> after super(), I can pass the object as a parameter to a method, even before returning from to main().
Could someone confirm that this whole analysis is true? Thank you for your time.
ps: I have actually posted the same question to the Sun forums but with on response. I hope I’ll have more luck here. Thank you.
Update
First thank you for your answers and time. Although I didn’t get a clear-cut answer (I had many questions and some of them were a bit vague), your answers and examples, and the subsequent experiments, were extremely useful for me in understanding more deeply how the JVM works.
The main thing I discovered is that the Verifier’s behavior differ with different implementations and versions (which makes the job of bytecode manipulation much more complicated). The problem lies in either a non-conformity to the JVMS, or a lack of documentation from the verifier’s developers, or the JVMS has some subtle vagueness in the verifier’s area.
One last thing, SO Rocks!!! I posted the same question in the official Sun JVM Specifications forum, and I still got no answer till now.
I suggest that you download a copy of the OpenJDK sources and look at what the verifier is actually checking. If nothing else, that may help you understand what the JMV specification is saying.
(However, @Joachim is right. Relying on what the verifier implementation does rather than what the specification says is rather risky.)