注释编辑:从Java 8开始，静态方法现在被允许出现在接口中。

这是正确的，静态方法自Java 8以来就被允许在接口中，但您的示例仍然不能工作。你不能只是定义一个静态方法:你必须实现它，否则你会得到一个编译错误。

因为静态方法不能在子类中重写，因此它们不能是抽象的。事实上，接口中的所有方法都是抽象的。

First, all language decisions are decisions made by the language creators. There is nothing in the world of software engineering or language defining or compiler / interpreter writing which says that a static method cannot be part of an interface. I've created a couple of languages and written compilers for them -- it's all just sitting down and defining meaningful semantics. I'd argue that the semantics of a static method in an interface are remarkably clear -- even if the compiler has to defer resolution of the method to run-time.

其次，我们使用静态方法意味着有一个包含静态方法的接口模式的正当理由——我不能代表你们，但我经常使用静态方法。

The most likely correct answer is that there was no perceived need, at the time the language was defined, for static methods in interfaces. Java has grown a lot over the years and this is an item that has apparently gained some interest. That it was looked at for Java 7 indicates that its risen to a level of interest that might result in a language change. I, for one, will be happy when I no longer have to instantiate an object just so I can call my non-static getter method to access a static variable in a subclass instance ...

假设你能做到;想想这个例子:

interface Iface {
  public static void thisIsTheMethod();
}

class A implements Iface {

  public static void thisIsTheMethod(){
    system.out.print("I'm class A");
  }

}

class B extends Class A {

  public static void thisIsTheMethod(){
    System.out.print("I'm class B");
  } 
}

SomeClass {

  void doStuff(Iface face) {
    IFace.thisIsTheMethod();
    // now what would/could/should happen here.
  }

}

Java 8允许静态接口方法

在Java 8中，接口可以有静态方法。它们也可以有具体的实例方法，但没有实例字段。

这里有两个问题:

为什么在糟糕的过去，接口不能包含静态方法? 为什么静态方法不能被覆盖?

接口中的静态方法

在以前的版本中，接口不能有静态方法并没有强有力的技术原因。一个重复问题的海报很好地总结了这一点。静态接口方法最初被认为是一个小的语言变化，然后有一个官方提议在Java 7中添加它们，但后来由于不可预见的复杂性而被放弃。

最后，Java 8引入了静态接口方法，以及使用默认实现重写实例方法。但它们仍然不能有实例字段。这些特性是lambda表达式支持的一部分，您可以在JSR 335的H部分中阅读有关它们的更多信息。

覆盖静态方法

第二个问题的答案有点复杂。

静态方法在编译时可解析。动态分派对于实例方法很有意义，因为在实例方法中，编译器不能确定对象的具体类型，因此不能解析要调用的方法。但是调用静态方法需要一个类，由于该类在编译时是静态已知的，因此动态分派是不必要的。

了解实例方法如何工作的一些背景知识对于理解这里发生的事情是必要的。我相信实际的实现是完全不同的，但是让我解释一下方法分派的概念，它准确地模拟了观察到的行为。

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 queries the object for its 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.

如果一个超类和一个子类在它们的表中都有相同方法签名的条目，则首先遇到子类的版本，而从不使用超类的版本——这就是“重写”。

现在，假设我们跳过对象实例，只从一个子类开始。解析可以像上面那样进行，为您提供一种“可重写的”静态方法。但是，解析都可以在编译时发生，因为编译器是从已知的类开始的，而不是等到运行时才查询未指定类型的对象的类。“重写”静态方法没有意义，因为总是可以指定包含所需版本的类。

构造函数“接口”

这里有更多的材料来解决最近对这个问题的编辑。

听起来好像您希望有效地为IXMLizable的每个实现强制使用一个类构造函数方法。暂时不要试图通过接口强制实现这一点，假设您有一些满足此需求的类。你会如何使用它?

class Foo implements IXMLizable<Foo> {
  public static Foo newInstanceFromXML(Element e) { ... }
}

Foo obj = Foo.newInstanceFromXML(e);

由于在“构造”新对象时必须显式地将具体类型命名为Foo，因此编译器可以验证它确实具有必要的工厂方法。如果没有，那又怎样?如果我可以实现一个缺少“构造函数”的IXMLizable，并且我创建了一个实例并将其传递给您的代码，那么它就是一个具有所有必要接口的IXMLizable。

构造是实现的一部分，而不是接口。任何成功使用接口的代码都不关心构造函数。任何关心构造函数的代码都需要知道具体类型，而接口可以被忽略。

一个接口永远不能被静态地解引用，例如issomething .member。接口总是通过引用该接口子类实例的变量来解除引用。因此，如果没有其子类的实例，接口引用永远不可能知道它引用的是哪个子类。

Thus the closest approximation to a static method in an interface would be a non-static method that ignores "this", i.e. does not access any non-static members of the instance. At the low-level abstraction, every non-static method (after lookup in any vtable) is really just a function with class scope that takes "this" as an implicit formal parameter. See Scala's singleton object and interoperability with Java as evidence of that concept. And thus every static method is a function with class scope that does not take a "this" parameter. Thus normally a static method can be called statically, but as previously stated, an interface has no implementation (is abstract).

Thus to get closest approximation to a static method in an interface, is to use a non-static method, then don't access any of the non-static instance members. There would be no possible performance benefit any other way, because there is no way to statically link (at compile-time) a ISomething.member(). The only benefit I see of a static method in an interface is that it would not input (i.e. ignore) an implicit "this" and thus disallow access to any of the non-static instance members. This would declare implicitly that the function that doesn't access "this", is immutate and not even readonly with respect to its containing class. But a declaration of "static" in an interface ISomething would also confuse people who tried to access it with ISomething.member() which would cause a compiler error. I suppose if the compiler error was sufficiently explanatory, it would be better than trying to educate people about using a non-static method to accomplish what they want (apparently mostly factory methods), as we are doing here (and has been repeated for 3 Q&A times on this site), so it is obviously an issue that is not intuitive for many people. I had to think about it for a while to get the correct understanding.

在接口中获取可变静态字段的方法是在接口中使用非静态getter和setter方法，来访问子类中的静态字段。旁注，显然不可变静态可以在带有静态final的Java接口中声明。