我认为java没有静态接口方法，因为你不需要它们。你可能认为你知道，但是… 你会如何使用它们?如果你想叫他们

MyImplClass.myMethod()

那么就不需要在接口中声明它了。如果你想叫他们

myInstance.myMethod()

那么它就不应该是静态的。 如果您实际上打算使用第一种方法，但只是想强制每个实现都有这样的静态方法，那么它实际上是一种编码约定，而不是实现接口的实例和调用代码之间的契约。

接口允许您在实现接口的类实例和调用代码之间定义契约。java帮助您确保这个契约没有被违反，因此您可以依赖它，而不必担心哪个类实现了这个契约，只要“某个签署了契约的人”就足够了。在静态接口的情况下，你的代码

MyImplClass.myMethod()

不依赖于每个接口实现都有此方法的事实，因此不需要Java来帮助您确定使用它。

通常这是使用工厂模式完成的

public interface IXMLizableFactory<T extends IXMLizable> {
  public T newInstanceFromXML(Element e);
}

public interface IXMLizable {
  public Element toXMLElement();
}

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

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

静态方法不像实例方法那样是虚拟的，所以我猜想Java设计者决定不让它们出现在接口中。

但是您可以将包含静态方法的类放在接口中。你可以试试!

public interface Test {
    static class Inner {
        public static Object get() {
            return 0;
        }
    }
}

接口中静态方法的需求是什么，静态方法基本上是在你不需要创建对象实例时使用的，接口的整个思想是引入面向对象的概念，通过引入静态方法，你从概念中转移。

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 ...