Member Avatar for Sailor_Jerry

For example
Class A does not have a default constructor.
Class B extends A

Any reason/benefits to do this?

public class B extends A
{
   public B()
   {
      super();
   }
}
  • 3 Contributors
  • 4 Replies
  • 200 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by proghelper

Dani AI

Generated

Good question, — and good points from and . The practical truth is that explicitly writing a no-arg constructor or an explicit super(...) call is mostly about correctness and clarity, not about a JVM speed win. There are a few important rules and common traps worth calling out so you know when you must write a constructor and when the compiler is doing work for you.

If a class declares no constructors at all, the compiler silently supplies a no-argument (default) constructor for you. If you declare any constructor yourself, the compiler will not add that default one. Also: if a constructor body does not begin with an explicit this(...) or super(...), the compiler implicitly inserts super() as the first statement — so a superclass no-arg constructor is assumed. That implicit insertion is why everything in simple examples works, but it’s also the source of the typical compile error when the superclass provides only parameterized constructors.

A common failure pattern and quick fix:

class Parent {
    Parent(int x) { /* no no-arg constructor */ }
}

class Child extends Parent {
    Child() {
        // implicit super() is inserted here -> compile error
        // fix: call the existing parent constructor explicitly:
        // super(42);
    }
}

If you see an error like “Implicit super constructor Parent() is undefined. Must explicitly invoke another constructor,” either add a matching no-arg constructor to the superclass or make the subclass constructor call an existing super(args) as its first statement. Best practice: be explicit in public APIs (declare the constructors you expect callers to use), use this(...) to centralize overloaded constructors, and prefer explicit super(...) calls only when you need to pass arguments or make initialization intent clear. There’s no measurable runtime advantage to writing super() yourself; the compiler produces the necessary invocation either way.

Recommended Answers

All 4 Replies

Member Avatar for server_crash

All classes have a default constructor. If it's not present, then it's implicit.

The call to super is also implicit if it's not present. The benifit of calling super is good design practice. Each constructor calls it's super class until it reaches the top of the heiarchy(most likey Object class).

Calling super() yourself just means that the JVM won't have to worry about doing all that themeselves.

Member Avatar for Sailor_Jerry

Ahh I see.
So it’s good design practice.
If this is done throughout a large program, would this have a positive impact on performance?
Since the JVM won’t have to worry about it.

Thanks

Member Avatar for server_crash

No not really. I don't think there's a performance hit at all, but it's excellent practice to include that call, and even I do it. I know I don't have to, but I do it anyway.

Member Avatar for proghelper

Yes it is the best practice to provide the default constructor in the program code that we write.

If we do not write one, the compiler includes a default one into the byte code. However there is no gaurentee that performance wise it is faster.

Having our own constructor is not really a place where we got to bother of performance as Java is slow anyway :cheesy:

______________________________________

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.