Call to super must be first statement in constructor java

This applies to CheckingAccountCustomer too.

• No-args constructor: a constructor with no parameters;
• Accessible no-args constructor: a no-args constructor in the superclass visible to the subclass. That means it is either public or protected or, if both classes are in the same package, package access; and
• Default constructor: the public no-args constructor added by the compiler when there is no explicit constructor in the class.

So all classes have at least one constructor.

Subclasses constructors may specify as the first thing they do which constructor in the superclass to invoke before executing the code in the subclass's constructor.

If the subclass constructor does not specify which superclass constructor to invoke then the compiler will automatically call the accessible no-args constructor in the superclass.

If the superclass has no no-arg constructor or it isn't accessible then not specifying the superclass constructor to be called (in the subclass constructor) is a compiler error so it must be specified.

public class Base < >public class Derived extends Base

This is fine because if you add no constructor explicitly Java puts in a public default constructor for you.

public class Base < >public class Derived extends Base < public Derived(int i) < >> 

public class Base < public Base(String s) < >> public class Derived extends Base

The above is a compilation error as Base has no default constructor.

public class Base < private Base() < >> public class Derived extends Base

This is also an error because Base's no-args constructor is private.

super() refers to the extended class (not an implemented interface). Which in this case is Object

So it will call the constructor in Object (Which does nothing)

Java enforces that the call to super (explicit or not) must be the first statement in the constructor. This is to prevent the subclass part of the object being initialized prior to the superclass part of the object being initialized.

In your case, you don't do anything but local "trivial computation", so all things considered, it would be okay. However, Java's compiler doesn't go to the level of determining whether statements before a call to super actually do any initialization. It just disallows all statements before super() .

There is no intrinsic reason why Java could not be extended to allow statements that do not access this before the constructor. However, that would add to the language complexity and obscure the code when used (particularly when you consider the call may be implicit).

Generally you want to keep constructors as simple as possible. init() methods are a bad idea as they prevent the use of final . It appears that the code is accessing a mutable static which is a really bad idea.

For your specific code, you can write:

 public IMethodFinder(String projectName, String methodName, int numberOfParameters)

A more general hack is to call a static method within the call to the constructor:

public class IMethodFinder < public IMethodFinder(String projectName, String methodName, int numberOfParameters) < this(createProject(projectName), methodName, numberOfParameters); >public IMethodFinder(IJavaProject javaProject, String methodName, int numberOfParameters) < . >private static IJavaProject createProject(String projectName) < IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject(projectName); IJavaProject javaProject = JavaCore.create(project); return javaProject; >> 

Edit March 2018: In message Records: construction and validation Oracle is suggesting this restriction be removed (but unlike C#, this will be definitely unassigned (DU) before constructor chaining).

Historically, this() or super() must be first in a constructor. This restriction was never popular, and perceived as arbitrary. There were a number of subtle reasons, including the verification of invokespecial, that contributed to this restriction. Over the years, we've addressed these at the VM level, to the point where it becomes practical to consider lifting this restriction, not just for records, but for all constructors.

Источник

Avoiding the "call to super must be first statement in constructor" message

posted 12 years ago

I'd like to have something like that:

but I get the call to super must be first statement in constructor message.

posted 12 years ago

Bartender

posted 12 years ago

Where are you getting foo from? If it's an instance variable then the value will always be the default value.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.

Marshal

posted 12 years ago

You can't write super() twice, but you can get an if . . . then . . . else into a single statement, quite easily.

posted 12 years ago

Wouter Oet wrote: Where are you getting foo from? If it's an instance variable then the value will always be the default value.

I'm getting it from the session.
I should have written JSFUtil.getSession.getBean(. )

posted 12 years ago

Campbell Ritchie wrote: You can't write super() twice, but you can get an if . . . then . . . else into a single statement, quite easily.

Well yeah, I can use the ? and : symbols if I have two cases. but actually have four of them.

posted 12 years ago

• 1

Well, it's possible to chain multiple ? : together. But many people would consider that hard to read. You can also call a static method as part of the super constructor call:

Put whatever you want inside the method, as long as it doesn't access instance variables. That's why only static methods are allowed here; instance variables can't possibly have been meaningfully initialized at this point.

posted 12 years ago

Mike Simmons wrote: Well, it's possible to chain multiple ? : together. But many people would consider that hard to read. You can also call a static method as part of the super constructor call:

Put whatever you want inside the method, as long as it doesn't access instance variables. That's why only static methods are allowed here; instance variables can't possibly have been meaningfully initialized at this point.

That works perfectly.
Thanks a bunch! : o)

Источник

call to super() must be the first statement in constructor body

But isn't it effectively the exact same thing? In both cases, a couple of trivial computation are made prior to calling the super constructor, based on the values of the parameters passed to the subclass constructor. Why shouldn't the compiler be able to compile the first example given that it can compile the second?

Is the calling-super-constructor-must-be-first-statement specification more simplistic than it would need to be, or am I missing something?

EDIT: this has been wrongly marked as duplicate of Why do this() and super() have to be the first statement in a constructor?. That question is much more generic and asks why super() have to be the first statement at all. The question here is why a case like the one I've posted would defeat those requirements (and it has been satisfactorily answered in this very question)

Answers

Java enforces that the call to super (explicit or not) must be the first statement in the constructor. This is to prevent the subclass part of the object being initialized prior to the superclass part of the object being initialized.

In your case, you don't do anything but local "trivial computation", so all things considered, it would be okay. However, Java's compiler doesn't go to the level of determining whether statements before a call to super actually do any initialization. It just disallows all statements before super() .

Источник

call to super must be first statement in constructor?

posted 1 year ago

I want to call parent class but it given me error? how can I call using super?

posted 1 year ago

super.calc(a,b);// it return derived class value which is (1) I want the parent class value which is (0)
^
^

Saloon Keeper

posted 1 year ago

posted 1 year ago

super.calc( a, b ); I wrote this one but got 1 as output but I want 0 as output which is in parent class

Marshal

posted 1 year ago

That is because you wrote return 1; If you want the 0 elsewhere you will have to write super.calc(123, 456) (or similar) there. You can only get the result if you use super.calc(. ) direcly in an instance method. You cannot use super like that in a static method. If you get xyz.super.foo() to compile, you will get the same as for xyz.foo() because of polymorphism.

Источник