This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
create a class: app.java compile it: javac app.java Is this order good? JVM loads class app.java. Static members are initialized.(vars,blocks,methods) JVM goes to the main method. Object is declared in main: App myApp; Object creation: myApp = new App(); New is envoked. New operator allocates memory. Instance variables are initialized to their defaults. New operator calls the super ctor. New operaator calls the original ctor. Constructor creates the "object." Constructor body is not yet executed though. Constructor initializes all instance variables to 0,null or false. Constructor body is now executed. Is this a good "loose" interpretation? [ March 15, 2003: Message edited by: donald rieck ]
Howdy, the only thing I wanted to clarify is with the order in which constructors are called and variables initialized. Starting with... * Constructor is invoked * instance variables are given default values (0, null, false, etc.) * super constructor is invoked * super constructor completes * instance variables are now give their explicit initialization values (values assigned when the variables are declared) * constructor completes The key scary thing in there is the Schroedinger's cat state the object is in when the super constructor is running. You cannot, for example, pass instance variables to your super constructor, or invoke instance methods as part of the call to super. You should also avoid calling any non-final or non-private instance methods from within the constructor. Because let's say your super constructor is running, and it makes a call to a method (a method of the superclass, in other words, a method in the same class as the constructor that's now running). Now imagine that YOU have overridden that method... your overridden version will be called, even though YOUR constructor has not yet run! In other words, polymorphism is still alive and kicking, causing a virtual method invocation of the overridden method, yet that overridden method probably uses instance variables, which have not yet received their "real" initial values! 99% of the time, that half-alive-half-not-alive state won't be noticed, as long as you don't try to call potentially overridable instance methods from a constructor. cheers, Kathy