StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3279052
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
6
CommunityOwnedDate
CreationDate
2010-07-19T07:10:40.610
FavoriteCount
0
LastActivityDate
2010-07-20T06:37:50.590
LastEditDate
2010-07-20T06:37:50.590
LastEditorUserId
100836
OwnerUserId
100836
ParentId
3278865
PostTypeId
2
Score
4
ViewCount
0
LastEditorDisplayName
text
Body
<blockquote> "The verifier rejects code that uses the new object before it has been initialized." </blockquote> In bytecode verification, since the verifier works at link-time, the types of local variables of methods are inferred. The types of method arguments are known as they are in the method signature in the class file. The types of other local variables are not known and are inferred, so I assume the "uses" in the above statement relates to this. EDIT: The section 4.9.4 of the <a href="http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9839" rel="nofollow noreferrer">JVMS</a> reads: <blockquote> The instance initialization method (<a href="http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#12174" rel="nofollow noreferrer">§3.9</a>) for class myClass sees the new uninitialized object as its this argument in local variable 0. 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. </blockquote> This assignment of fields in the above statement is the "initial" initialization of the instance variables to default initial values (like int is 0, float is 0.0f etc.) when the memory for the object is allocated. There is one more "proper" initialization of instance variables when the virtual machine invokes the instance initialization method(constructor) on the object. The <a href="http://scala-programming-language.1934581.n4.nabble.com/Object-initialization-order-in-Scala-td1987968.html" rel="nofollow noreferrer">link</a> provided by John Horstmann helped clarify things. So these statements dont hold true. "This DOESNOT mean that in an <code><init></code> method, <code>getfield</code> and <code>putfield</code> are allowed before another <code><init></code> is called." The <code>getfield</code> and <code>putfield</code> instructions are used to access (and change) the instance variables(fields) of a class (or instance of a class). And this can happen only when the instance variables(fields) are initialized." From the JVMS : <blockquote> Each instance initialization method (§3.9), except for the instance initialization method derived from the constructor of class Object, must call either another instance initialization method of this or an instance initialization method of its direct superclass super before its instance members are accessed. However, instance fields of this that are declared in the current class may be assigned before calling any instance initialization method. </blockquote> When the Java Virtual Machine creates a new instance of a class, either implicitly or explicitly, it first allocates memory on the heap to hold the object's instance variables. Memory is allocated for all variables declared in the object's class and in all its superclasses, including instance variables that are hidden. As soon as the virtual machine has set aside the heap memory for a new object, it immediately initializes the instance variables to default initial values. Once the virtual machine has allocated memory for the new object and initialized the instance variables to default values, it is ready to give the instance variables their proper initial values. The Java Virtual Machine uses two techniques to do this, depending upon whether the object is being created because of a clone() invocation. If the object is being created because of a clone(), the virtual machine copies the values of the instance variables of the object being cloned into the new object. Otherwise, the virtual machine invokes an instance initialization method on the object. The instance initialization method initializes the object's instance variables to their proper initial values. And only after this can you use <code>getfield</code> and <code>putfield</code>. The java compiler generates atleast one instance initialization method(constructor) for every class it compiles. If the class declares no constructors explicitly, the compiler generated a default no-arg constructor that just invokes the superclass no-arg constructor. And rightly so doing any operation on an instance field before a call to <code>super()</code> or <code>this()</code> results in a compilation error. An <code><init></code> method can contain three kinds of code: an invocation of another <code><init></code> method, code that implements any instance variable initializers, and code for the body of the constructor. If a constructor begins with an explicit invocation of another constructor in the same class (a <code>this()</code> invocation) its corresponding <code><init></code> method will be composed of two parts: <ul> <li>an invocation of the same-class <code><init></code> method</li> <li>the bytecodes that implement the body of the corresponding constructor</li> </ul> If a constructor does not begin with a <code>this()</code> invocation and the class is not Object, the <code><init></code> method will have three components: <ul> <li>an invocation of a superclass <code><init></code> method</li> <li>the bytecodes for any instance variable initializers</li> <li>the bytecodes that implement the body of the corresponding constructor</li> </ul> If a constructor does not begin with a <code>this()</code> invocation and the class is Object(and Object has no superclass), then its <code><init></code> method cant begin with a superclass <code><init></code> method invocation. If a constructor begins with an explicit invocation of a superclass constructor ( a <code>super()</code> invocation), its <code><init></code> method will invoke the corresponding superclass <code><init></code>method. I think this answers your first and second question. Updated: For example, <pre><code> class Demo { int somint; Demo() //first constructor { this(5); //some other stuff.. } Demo(int i) //second constructor { this.somint = i; //some other stuff...... } Demo(int i, int j) //third constructor { super(); //other stuffff...... } } </code></pre> Heres the bytecode for the above three constructors from the compiler(javac): <pre><code>Demo(); Code: Stack=2, Locals=1, Args_size=1 0: aload_0 1: iconst_5 2: invokespecial #1; //Method "<init>":(I)V 5: return Demo(int); Code: Stack=2, Locals=2, Args_size=2 0: aload_0 1: invokespecial #2; //Method java/lang/Object."<init>":()V 4: aload_0 5: iload_1 6: putfield #3; //Field somint:I 9: return Demo(int, int); Code: Stack=1, Locals=3, Args_size=3 0: aload_0 1: invokespecial #2; //Method java/lang/Object."<init>":()V 4: return </code></pre> In the first constructor, the <code><init></code> method begins with calling the same-class <code><init></code> method and then executed the body of the corresponding constructor. Because the constructor begins with a <code>this()</code>, its corresponding <code><init></code> method doesnot contain bytecode for initializing the instance variables. In the second constructor, the <code><init></code> method for the constructor has <ul> <li>super class <code><init></code> method, ie, invocation of the superclass constructor(no arg method), the compiler generated this by default because no explicit <code>super()</code> was found as the first statement.</li> <li>the bytecode for initializing the instance variable <code>someint</code>.</li> <li>bytecode for rest of the stuff in the constructor body. </li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POClarifications on Bytecode and objects
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USZaki
UserOwnerUserId
1. USZaki
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.