NetBeans flags the existence of an overridable method called from a constructor as shown in the next screen snapshot (NetBeans 7.3 in this case):

To demonstrate a common problem associated with overridable methods called in a constructor, a child class is needed. That is shown next with the code listing for ComputerScientist, which extendsEmployee.

One might expect the Computer Scientist, Fred Flintstone, to earn a weekly salary in the range of $1,000 to $60,000. However, that is not what is shown when the simple main application is executed (command line output and NetBeans output shown).

The reason the Computer Scientist's salary range is not correct is that the parent class's (Employee's) constructor must first be run before the extending class (ComputerScientist) is completely instantiated. The child class does override the setSalaryRange() method, but this overridden implementation depends on an instance variable (marketFactor) that is not yet initialized in the child instance when the parent's constructor calls this child class's overridden method.

There are multiple ways to avoid this problem. Perhaps the best and easiest approaches are those recommended by the NetBeans hint that flagged this issue.

As the screen snapshot above shows, NetBeans provides four easy and effective ways to deal with the issue of an overridable method called from the constructor of a class. Because the issue involves an "overridable" method and a child class that is not fully instantiated when that overridable method is invoked during parent's constructor, an obvious tactic is to make the parent class final so that it cannot be extended. This obviously will only work for new classes that don't have classes extending them. I have found that Java developers often don't put a lot of consideration into making a class final or planning for it to be extensible, but this is an example of where such consideration is worthwhile.

When it is not practical to make the parent class final, NetBeans offers three other approaches for addressing the problem of an overridable method called from the parent class constructor. Even if the class cannot be final, that method can have the final modifier applied to it so that the constructor is no longer calling an "overridable" method. This allows a child class to still extend the parent class, but it cannot override that method and so won't have an implementation that depends on instance level variables that have not yet been initialized.

The other two ways shown that NetBeans uses to handle the issue of an overridable method being called from a constructor likewise focus on making that invoked method not overridable. In these other two cases, this is accomplished by making the invoked method static (class level rather than instance level) or by making the method private (but then not accessible at all to the child class).

In my particular example above, another way to fix the specific issue would have been to convert the instance-level marketFactor variable into a class-level (static) variable because that would move its initialization forward enough to be used in the invocation of the overridden method. The problem with this method is that there is still an overridable method invoked from the parent constructor and that method can have more than one state issue to worry about.

In general, I try to be very careful about a constructor calling methods as part of an instance's instantiation. I prefer to use a static factory that constructs an object and calls static methods to set that instance appropriately. It is always wise to be cautious with implementation inheritance and this issue of overridable methods called from a constructor is just another in the list of reasons why caution is warranted.

My example shown in this post is relatively simple and it is easy to figure out why the results were not as expected. In a much larger and more complicated example, it might be more difficult to find this and it can lead to pernicious bugs. NetBeans helps tremendously by warning about overridable methods called from constructors so that appropriate action can be taken. If a class is not extended and there are no plans to extend it, then making the class final is easy and appropriate. Otherwise, NetBeans presents other options for ensuring that all methods called from a constructor are not overridable.