But Maneesh is right, in that a constructor is only called when a new object is created and vice versa.
The keyword this on its own refers to the current object, as does this. with a dot. The statement this( . . . ); however is rather different. It means "call the other constructor on the current object and do part of the construction in that other constructor."
rajesh tarte wrote: . . .
As this is the reference to current object say Child
The only class with no superclass is java.lang.Object. So all other classes implicitly have java.lang.Object as a superclass.
then if there is no object for parent
then what Super represents?
I presume you can still work out how many objects are created?
The creation process is described in the Java™ Language Specification. It is very simple and easy to understand (and if you believe that you'll believe anything ).
Grossly simplified version: the JVM creates an object and each constructor call initialises part of the object.
rajesh tarte wrote:I know what is meant by this
My question was what Super represents if superclass object is not created?
The keyword super (as the first statement in a constructor) is simply a call to another method -- it's a call to the constructor with the matching signature in the super class. (Similarly, the keyword "this" as the first statement in a constructor calls another constructor within the class.) Since you must call super, Java guarantees that programmer-specified initialization occurs for the entire hierarchy your class subclasses.
Again: Super and this have two distinct meanings. It's stupid that the Java designers used the same key word.
My view is second case where these are treated as references.
If there is refrence either it is null or referencing not null object
we can define same variable both in parent and child class
if we directly used the variable in child class it refers the child class version and when we use super.variable_name it looks for varible of parent although it is overriden
In fact if we do not create a same variable name we can use "this" to refer a varible from parent class provided that it is not private
This means along with the inherited properties and methods in child class some of the things are not accessible using "this" thats why we need super, is it so?
And there is no object other than child class is created
one more thing two object of type Class are created
This is what is my understanding
please correct me if I m wrong
Any Class objects are loaded by the class loader program from the .class files on your drive. And at least three Class objects are loaded: the superclass, the subclass and java.lang.Object.
The super. reference is intended for use in an overriding method to gain access to the overridden version, and add functionality to that. If you are trying to give completely different functionality to a method, then you are not really overriding it (Google for "Liskov substitution principle" for more details).
rajesh tarte wrote:I am not interesed in thease keywords are used as methods.
If there is refrence either it is null or referencing not null object we can define same variable both in parent and child class if we directly used the variable in child class it refers the child class version and when we use super.variable_name it looks for varible of parent although it is overriden
Yes, the term for that is "shadowing", and you're right -- the way to reference the variable the superclass variable from the subclass is via "super.variableName". If you define an instance field in the ancestor, and another instance field of the same name in the subclass, then instances of the subclass have two variables allocated to it. One referenced via this.variableName in the ancestor and one referenced via this.variableName in the subclass.
Shadowing usually indicates a mistake, where the property is accidentally being re-implemented who doesn't notice the property has already been implemented in the ancestor. Shadowing can cause insidious bugs where two similar looking getters will reference two different variables depending on whether the getter is in the ancestor or subclass.