• Post Reply Bookmark Topic Watch Topic
  • New Topic

constructors in class hierarchy  RSS feed

 
N Sam
Ranch Hand
Posts: 77
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I remember reading that a super() call to parent no-argument constructor is automatically inserted by compiler. So, if i have a chained hierarchy of classes (starting at top, with Object), will there be a chain of super() calls, going from bottom to top in the chain ? Will a super() call be inserted in child, if i provide a no-argument constructor for this class ?
 
Tushar Goel
Ranch Hand
Posts: 934
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, if i have a chained hierarchy of classes (starting at top, with Object), will there be a chain of super() calls, going from bottom to top in the chain ?

Yes there will be.

Will a super() call be inserted in child, if i provide a no-argument constructor for this class ?


Yes if you have inserted no argument constructor then super calls and also if you dont have any constructor then compiler itself insert default constructor and calls super.
But if you have any parametrized constructor in parent class and you have not inserted any no argument constructor yourself then while calling from super() gives
compilation error.
 
N Sam
Ranch Hand
Posts: 77
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tushar Goel wrote:
So, if i have a chained hierarchy of classes (starting at top, with Object), will there be a chain of super() calls, going from bottom to top in the chain ?

Yes there will be.


One interesting side effect of this chaining would be the visibility of variables at the top of the chain, to the classes at the bottom of the chain.

Will a super() call be inserted in child, if i provide a no-argument constructor for this class ?


Yes if you have inserted no argument constructor then super calls ....


You mean that the compiler will insert a super() at the top of the child constructor() i have written.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
N Sam wrote:One interesting side effect of this chaining would be the visibility of variables at the top of the chain, to the classes at the bottom of the chain.

Not quite sure why. Would you care to elaborate?

You mean that the compiler will insert a super() at the top of the child constructor() i have written.

If you don't put one in yourself (or a call to a this([...]) constructor): Yup.

Winston
 
N Sam
Ranch Hand
Posts: 77
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perhaps the visibility of public/protected/default variables that are in the top of the chain (to the very bottom of the chain), is because the classes themselves are chained and visible as parents/grand parents (to the child at bottom). I meant the relationship between the chaining and the effect of the entire chain of variables becoming visible to the very bottom child. The constructors in the chain only will assign default values to all the variables in the chain.

Another point that i infer from my test code : the super() call is inserted by compiler at top of all the constructors of the child ( not only the no-argument constructor, but also into the constructors with arguments).
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
N Sam wrote:Perhaps the visibility of public/protected/default variables that are in the top of the chain (to the very bottom of the chain), is because the classes themselves are chained and visible as parents/grand parents (to the child at bottom). I meant the relationship between the chaining and the effect of the entire chain of variables becoming visible to the very bottom child. The constructors in the chain only will assign default values to all the variables in the chain.

There's no "perhaps" in computing. Things either happen or they don't; and if they do, it will be for a specific reason.

The fact is that visibility is NOT affected by constructor chaining, although a variable that you can't see might be set by one (quite different).

Another point that i infer from my test code : the super() call is inserted by compiler at top of all the constructors of the child ( not only the no-argument constructor, but also into the constructors with arguments).

You need to be careful not too infer too much from what you see. The effect is that the compiler appears to add a no-args superclass constructor if you don't, but whether that it is in fact what happens I have no idea (perhaps some others might). There's often a big difference between appearance and the actual mechanics.

Winston
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Another point that i infer from my test code : the super() call is inserted by compiler at top of all the constructors of the child ( not only the no-argument constructor, but also into the constructors with arguments).

You need to be careful not too infer too much from what you see. The effect is that the compiler appears to add a no-args superclass constructor if you don't, but whether that it is in fact what happens I have no idea (perhaps some others might). There's often a big difference between appearance and the actual mechanics.

The no-args super will be inserted in any constructor that doesn't have a an explicit super constructor call or a call to a different constructor in the same class (i.e. this()). The side effect is that a super constructor will always be called, but it might not be the default on if a different one is explicitly called.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:The no-args super will be inserted in any constructor that doesn't have a an explicit super constructor call...

Yup. I just wasn't sure whether this is actually physically done by the compiler or not. I guess it would be simple enough to find out by comparing .class files, but it's never seemed to me to be a big priority.

My point was more that just because you see an effect, you can't necessarily infer a cause or a specific mechanism.

Winston
 
N Sam
Ranch Hand
Posts: 77
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To test this chaining and inheritance from grand-parent, i wrote a little test program, and getting error at runtime. Can i not define the type of grand-child to be Employee ? The intention is to see the visibility of empid at grandchild (intern) level. Here is the prog:



The error i am getting is Exception in thread "main" java.lang.RuntimeException: Uncompilable source code - Erroneous sym type: initprocess.Programmer.<init> at initprocess.Intern.<init>
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
N Sam wrote:
The error i am getting is Exception in thread "main" java.lang.RuntimeException: Uncompilable source code - Erroneous sym type: initprocess.Programmer.<init> at initprocess.Intern.<init>



http://www.coderanch.com/how-to/java/FixAllCompilerErrorsBeforeRunningTheApplication

Henry
 
N Sam
Ranch Hand
Posts: 77
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks henry. Im still new to Netbeans. Clean and compile yields a different error at the first constructor in line :

error: constructor Programmer in class Programmer cannot be applied to given types;
public Intern(String name) {
required: String
found: no arguments
reason: actual and formal argument lists differ in length


NOTE - I fixed the syntax error at toString in the original prog. It has been changed to Integer.toString(empid).
I understand the meaning of the error message above, but i am at a loss to find the error. I also found that removing the parameter of constructor and making it just
Programmer() {........} compiles the above program successfully. Why is supplying an argument to this constructor results in above error ?
Why am i being forced to supply a no-argument constructor to the parent (Programmer) ? If i supply a no-argument constructor Programmer(), then everything works fine, and i can see empid being inherited from grand-parent to child. My guess is that it is a java rule that 'if i supply a constructor with arguments, then i must also provide a no-argument constructor for that class'; But i don't remember reading such a rule in my OCA book.


 
Campbell Ritchie
Marshal
Posts: 56527
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
N Sam wrote:Thanks henry. Im still new to Netbeans. . . .
Since you apear to be new to Java, too, I suggest you stop using NetBeans of other IDEs. Use the command line. Regard IDEs as being for experienced people. Which you will be before the Summer ends
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
N Sam wrote:Why am i being forced to supply a no-argument constructor to the parent (Programmer) ? If i supply a no-argument constructor Programmer(), then everything works fine, and i can see empid being inherited from grand-parent to child. My guess is that it is a java rule that 'if i supply a constructor with arguments, then i must also provide a no-argument constructor for that class';


You almost have the rule. Here is what happens:

If you do not provide a Constructor, a no-args constructor is created. If you do provide a constructor the default no-args constructor is not created.

Then in the child class, you need to call a super constructor. If you don't call one explicitly, then the no-arg constructor is called (because how is the compiler supposed to know what argument to pass?). But the no-arg constructor in Programmer() doesn't exist. Result: compile time error as the compiler tries to link to a no-args constructor but can only find a one-arg constructor.

So there are two solutions if you provide a constructor that takes an argument: 1) also create a no-arg constructor so subclasses can call it implicitly, or 2) explicitly call the super constructor which takes an argument from the child:
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Luke wrote:If you don't call one explicitly, then the no-arg constructor is called (because how is the compiler supposed to know what argument to pass?).

Seems to me that they could have saved a lot of this faffing about by simply saying: you supply the constructor chain call (superclass's or this(...)). ALWAYS.

It seems doubly odd, since the ethos of Java early on was to keep things simple.

Winston
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:Seems to me that they could have saved a lot of this faffing about by simply saying: you supply the constructor chain call (superclass's or this(...)). ALWAYS.

True, that would be simpler. But I guess it would be yet more boilerplate added to every constructor and Java is wordy enough as it is. So maybe more complicated rule for simpler code? maybe
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
p.s. All the gory details can be read from the Java Language Specification (JLS), in sections 8.8.7 and 8.8.9: http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.8.7 JLS is terribly hard to read, but this section isn't as bad as many others...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!