Why can't I define a static method in a Java interface?-Collection of common programming errors
There are two questions here:
- Why can’t interfaces contain static methods?
- Why can’t static methods be overridden?
There is no technical reason why an interface couldn’t support static methods. This is summed up nicely by the poster of the question you duplicated. One of the comments I made there emphasizes this point. In the end, I think this was just a choice by the language designers. This might actually be considered as a small language change. [Update: An official proposal was made to add static methods to interfaces in Java 7,] and was initially slated for inclusion, but was later dropped due to unforeseen complications.
Update: In fact, in Java 8, interfaces can have static methods, as well as override-able methods with a default implementation. They still can’t have instance fields though. These features are part of the lambda expression support, and you can read more about them in Part H of JSR 335.
The answer to the second question is a little more complicated.
Static methods are resolvable at compile time. Dynamic dispatch makes sense for instance methods, where the compiler can’t determine the the concrete type of the object, and, thus, can’t resolve the method to invoke. But invoking a static method requires a class, and since that class is known at compile time, dynamic dispatch is unnecessary.
A little background on how instance methods work is necessary to understand what’s going on here. I’m sure the actual implementation is quite different, but let me explain my notion of method dispatch, which models observed behavior accurately.
Pretend that each class has a hash table that maps method signatures (name and parameter types) to an actual chunk of code to implement the method. When the virtual machine attempts to invoke a method on an instance, it gets the object’s class, and looks up the requested signature in the class’s table. If a method body is found, it is invoked. Otherwise, the parent class of the class is obtained, and the lookup is repeated there. This proceeds until the method is found, or there are no more parent classes—which results in a NoSuchMethodError.
If a super class and a sub class both have an entry in their tables for the same method signature, the sub class’s version is encountered first, and the super class’s version is never used—this is an “override”.
Now, suppose we skip the object instance, and just start with a subclass. The resolution could proceed as above, giving you a sort of “overridable” static method. However, since the compiler is starting from a class known at compile time, rather than an object of unknown type passed in at runtime, the resolution can all happen at compile-time. There is no point in “overriding” a static method, since one can always specify the class that contains the desired version.
Here’s a little more material to address the recent edit to the question.
It sounds like you want to effectively mandate a constructor-like method for each implementation of IXMLizable. Forget about trying to enforce this with an interface for a minute, and pretend that you have some classes that meet this requirement. How would you use it?
class Foo implements IXMLizable {
public static Foo newInstanceFromXML(Element e) { ... }
}
Foo obj = Foo.newInstanceFromXML(e);
Since you have to explicitly name the concrete type Foo when “constructing” the new object, the compiler can verify that it does indeed have the necessary factory method. And if it doesn’t, so what? If I can implement an IXMLizable that lacks the “constructor”, and I create an instance and pass it to your code, it is an IXMLizable with all the necessary interface.
Construction is part of the implementation, not the interface. Any code that works successfully with the interface doesn’t care about the constructor. Any code that cares about the constructor needs to know the concrete type anyway, and the interface can be ignored.