Why doesn't Java allow overriding of static methods?

Overriding depends on having an instance of a class. The point of polymorphism is that you can subclass a class and the objects implementing those subclasses will have different behaviors for the same methods defined in the superclass (and overridden in the subclasses). A static method is not associated with any instance of a class so the concept is not applicable.

There were two considerations driving Java's design that impacted this. One was a concern with performance: there had been a lot of criticism of Smalltalk about it being too slow (garbage collection and polymorphic calls being part of that) and Java's creators were determined to avoid that. Another was the decision that the target audience for Java was C++ developers. Making static methods work the way they do had the benefit of familiarity for C++ programmers and was also very fast, because there's no need to wait until runtime to figure out which method to call.

Personally I think this is a flaw in the design of Java. Yes, yes, I understand that non-static methods are attached to an instance while static methods are attached to a class, etc etc. Still, consider the following code:

public class RegularEmployee {    private BigDecimal salary;    public void setSalary(BigDecimal salary) {        this.salary = salary;    }    public static BigDecimal getBonusMultiplier() {        return new BigDecimal(".02");    }    public BigDecimal calculateBonus() {        return salary.multiply(getBonusMultiplier());    }    /* ... presumably lots of other code ... */}public class SpecialEmployee extends RegularEmployee {    public static BigDecimal getBonusMultiplier() {        return new BigDecimal(".03");    }}

This code will not work as you might expect. Namely, SpecialEmployee's get a 2% bonus just like regular employees. But if you remove the "static"s, then SpecialEmployee's get a 3% bonus.

(Admittedly, this example is poor coding style in that in real life you would likely want the bonus multiplier to be in a database somewhere rather than hard-coded. But that's just because I didn't want to bog down the example with a lot of code irrelevant to the point.)

It seems quite plausible to me that you might want to make getBonusMultiplier static. Perhaps you want to be able to display the bonus multiplier for all the categories of employees, without needing to have an instance of an employee in each category. What would be the point of searching for such example instances? What if we are creating a new category of employee and don't have any employees assigned to it yet? This is quite logically a static function.

But it doesn't work.

And yes, yes, I can think of any number of ways to rewrite the above code to make it work. My point is not that it creates an unsolvable problem, but that it creates a trap for the unwary programmer, because the language does not behave as I think a reasonable person would expect.

Perhaps if I tried to write a compiler for an OOP language, I would quickly see why implementing it so that static functions can be overriden would be difficult or impossible.

Or perhaps there is some good reason why Java behaves this way. Can anyone point out an advantage to this behavior, some category of problem that is made easier by this? I mean, don't just point me to the Java language spec and say "see, this is documented how it behaves". I know that. But is there a good reason why it SHOULD behave this way? (Besides the obvious "making it work right was too hard"...)

Update

@VicKirk: If you mean that this is "bad design" because it doesn't fit how Java handles statics, my reply is, "Well, duh, of course." As I said in my original post, it doesn't work. But if you mean that it is bad design in the sense that there would be something fundamentally wrong with a language where this worked, i.e. where statics could be overridden just like virtual functions, that this would somehow introduce an ambiguity or it would be impossible to implement efficiently or some such, I reply, "Why? What's wrong with the concept?"

I think the example I give is a very natural thing to want to do. I have a class that has a function that does not depend on any instance data, and which I might very reasonably want to call independent of an instance, as well as wanting to call from within an instance method. Why should this not work? I've run into this situation a fair number of times over the years. In practice I get around it by making the function virtual, and then creating a static method whose only purpose in life is to be a static method that passes the call on to the virtual method with a dummy instance. That seems like a very roundabout way to get there.

The short answer is: it is entirely possible, but Java doesn't do it.

Here is some code which illustrates the current state of affairs in Java:

File Base.java:

package sp.trial;public class Base {  static void printValue() {    System.out.println("  Called static Base method.");  }  void nonStatPrintValue() {    System.out.println("  Called non-static Base method.");  }  void nonLocalIndirectStatMethod() {    System.out.println("  Non-static calls overridden(?) static:");    System.out.print("  ");    this.printValue();  }}

File Child.java:

package sp.trial;public class Child extends Base {  static void printValue() {    System.out.println("  Called static Child method.");  }  void nonStatPrintValue() {    System.out.println("  Called non-static Child method.");  }  void localIndirectStatMethod() {    System.out.println("  Non-static calls own static:");    System.out.print("  ");    printValue();  }  public static void main(String[] args) {    System.out.println("Object: static type Base; runtime type Child:");    Base base = new Child();    base.printValue();    base.nonStatPrintValue();    System.out.println("Object: static type Child; runtime type Child:");    Child child = new Child();    child.printValue();    child.nonStatPrintValue();    System.out.println("Class: Child static call:");    Child.printValue();    System.out.println("Class: Base static call:");    Base.printValue();    System.out.println("Object: static/runtime type Child -- call static from non-static method of Child:");    child.localIndirectStatMethod();    System.out.println("Object: static/runtime type Child -- call static from non-static method of Base:");    child.nonLocalIndirectStatMethod();  }}

If you run this (I did it on a Mac, from Eclipse, using Java 1.6) you get:

Object: static type Base; runtime type Child.  Called static Base method.  Called non-static Child method.Object: static type Child; runtime type Child.  Called static Child method.  Called non-static Child method.Class: Child static call.  Called static Child method.Class: Base static call.  Called static Base method.Object: static/runtime type Child -- call static from non-static method of Child.  Non-static calls own static.    Called static Child method.Object: static/runtime type Child -- call static from non-static method of Base.  Non-static calls overridden(?) static.    Called static Base method.

Here, the only cases which might be a surprise (and which the question is about) appear to be the first case:

"The run-time type is not used to determine which static methods are called, even when called with an object instance (obj.staticMethod())."

and the last case:

"When calling a static method from within an object method of a class, the static method chosen is the one accessible from the class itself and not from the class defining the run-time type of the object."

Calling with an object instance

The static call is resolved at compile-time, whereas a non-static method call is resolved at run-time. Notice that although static methods are inherited (from parent) they are not overridden (by child). This could be a surprise if you expected otherwise.

Calling from within an object method

Object method calls are resolved using the run-time type, but static (class) method calls are resolved using the compile-time (declared) type.

Changing the rules

To change these rules, so that the last call in the example called Child.printValue(), static calls would have to be provided with a type at run-time, rather than the compiler resolving the call at compile-time with the declared class of the object (or context). Static calls could then use the (dynamic) type hierarchy to resolve the call, just as object method calls do today.

This would easily be doable (if we changed Java :-O), and is not at all unreasonable, however, it has some interesting considerations.

The main consideration is that we need to decide which static method calls should do this.

At the moment, Java has this "quirk" in the language whereby obj.staticMethod() calls are replaced by ObjectClass.staticMethod() calls (normally with a warning). [Note: ObjectClass is the compile-time type of obj.] These would be good candidates for overriding in this way, taking the run-time type of obj.

If we did it would make method bodies harder to read: static calls in a parent class could potentially be dynamically "re-routed". To avoid this we would have to call the static method with a class name -- and this makes the calls more obviously resolved with the compile-time type hierarchy (as now).

The other ways of invoking a static method are more tricky: this.staticMethod() should mean the same as obj.staticMethod(), taking the run-time type of this. However, this might cause some headaches with existing programs, which call (apparently local) static methods without decoration (which is arguably equivalent to this.method()).

So what about unadorned calls staticMethod()? I suggest they do the same as today, and use the local class context to decide what to do. Otherwise great confusion would ensue. Of course it means that method() would mean this.method() if method was a non-static method, and ThisClass.method() if method were a static method. This is another source of confusion.

Other considerations

If we changed this behaviour (and made static calls potentially dynamically non-local), we would probably want to revisit the meaning of final, private and protected as qualifiers on static methods of a class. We would then all have to get used to the fact that private static and public final methods are not overridden, and can therefore be safely resolved at compile-time, and are "safe" to read as local references.