这是一个糟糕的语言设计，真的没有理由不可能。

事实上，这里有一个模式或方法可以在**Java中模仿它，让你至少能够修改自己的实现:

public static abstract class Request {                 

        // Static method
        public static void doSomething() {
                get().doSomethingImpl();
        }
        
        // Abstract method
        abstract void doSomethingImpl();

        /////////////////////////////////////////////
        private static Request SINGLETON;
        private static Request get() {
            if ( SINGLETON == null ) {
                // If set(request) is never called prior,
                // it will use a default implementation. 
                return SINGLETON = new RequestImplementationDefault();
            }
            return SINGLETON;
        }
        public static Request set(Request instance){
            return SINGLETON = instance;
        }
        /////////////////////////////////////////////
}

两种实现:

/////////////////////////////////////////////////////

public static final class RequestImplementationDefault extends Request {
        @Override void doSomethingImpl() {
                System.out.println("I am doing something AAA");
        }
}

/////////////////////////////////////////////////////

public static final class RequestImplementaionTest extends Request {
        @Override void doSomethingImpl() {
                System.out.println("I am doing something BBB");
        }
}

/////////////////////////////////////////////////////

可以这样使用:

Request.set(new RequestImplementationDefault());

// Or

Request.set(new RequestImplementationTest());

// Later in the application you might use

Request.doSomething();

这将允许您静态地调用方法，同时还能够更改例如Test环境的实现。

理论上，您也可以在ThreadLocal上执行此操作，并且能够为每个线程上下文设置实例，而不是像这里所示的完全全局，然后可以执行Request。withRequest(anotherRequestImpl，() ->{…})或类似的。

现实世界通常不需要ThreadLocal方法，通常能够全局地改变测试环境的实现就足够了。

请注意，这样做的唯一目的是能够保留静态方法所提供的直接、轻松和干净地调用方法的能力，同时能够切换实现，以牺牲稍微复杂的实现为代价。

它只是一种绕过通常不可修改的静态代码的模式。

方法的抽象注释表明该方法必须在子类中重写。

在Java中，静态成员(方法或字段)不能被子类覆盖(在其他面向对象语言中不一定是这样，请参阅SmallTalk)。静态成员可能被隐藏，但这与被覆盖有本质区别。

由于静态成员不能在子类中被重写，因此抽象注释不能应用于它们。

顺便说一句，其他语言确实支持静态继承，就像实例继承一样。从语法的角度来看，这些语言通常要求在语句中包含类名。例如，在Java中，假设你在ClassA中编写代码，这是等价的语句(如果methodA()是一个静态方法，并且没有具有相同签名的实例方法):

ClassA.methodA();

and

methodA();

在SmallTalk中，类名不是可选的，所以语法是(注意，SmallTalk不使用。将“主语”和“动词”分开，而是将其用作语句结束符):

ClassA methodA.

因为总是需要类名，所以总是可以通过遍历类层次结构来确定方法的正确“版本”。无论如何，我偶尔会错过静态继承，当我第一次开始使用Java时，我就被Java中缺乏静态继承所困扰。此外，SmallTalk是duck类型的(因此不支持契约式编程)。因此，类成员没有抽象修饰符。

静态方法 可以调用静态方法，而不需要创建类的实例。静态方法属于类，而不是类的对象。 静态方法可以访问静态数据成员，也可以改变它的值。 摘要关键字用于实现抽象。 静态方法不能在子类中重写或实现。因此，把静态方法做得抽象是没有用的。

我相信我已经找到了这个问题的答案，即为什么接口的方法(就像父类中的抽象方法一样工作)不能是静态的。以下是完整的答案(不是我的)

基本上静态方法可以在编译时绑定，因为要调用它们你需要指定一个类。这与实例方法不同，对于实例方法，在编译时调用方法的引用的类可能是未知的(因此只能在运行时确定调用哪个代码块)。

如果您正在调用一个静态方法，那么您已经知道实现它的类，或者它的任何直接子类。如果你定义

abstract class Foo {
    abstract static void bar();
}

class Foo2 {
    @Override
    static void bar() {}
}

然后任意Foo.bar();调用显然是非法的，您将始终使用Foo2.bar();。

考虑到这一点，静态抽象方法的唯一目的是强制子类实现这样的方法。你可能最初认为这是非常错误的，但如果你有一个泛型类型参数<E扩展MySuperClass>，它将很好地通过接口保证E可以. dosomething()。请记住，由于类型擦除，泛型只存在于编译时。

那么，它有用吗?是的，也许这就是为什么Java 8允许在接口中使用静态方法(尽管只有默认实现)。为什么不在类中使用默认实现抽象静态方法呢?很简单，因为具有默认实现的抽象方法实际上是一个具体方法。

为什么不使用没有默认实现的抽象/接口静态方法?显然，这仅仅是因为Java识别它必须执行哪个代码块的方式(我回答的第一部分)。

因为抽象类是一个OOPS概念，静态成员不是OOPS....的一部分 现在我们可以在接口中声明静态完整方法，我们可以通过在接口中声明主方法来执行接口

interface Demo 
{
  public static void main(String [] args) {
     System.out.println("I am from interface");
  }
}

根据Java文档:

静态方法是与其中的类相关联的方法 它是定义的，而不是与任何对象。类的每个实例 共享它的静态方法

在Java 8中，除了默认方法外，接口中还允许使用静态方法。这使得我们更容易在库中组织helper方法。我们可以在同一个接口中保留特定于某个接口的静态方法，而不是在一个单独的类中。

一个很好的例子是:

list.sort(ordering);

而不是

Collections.sort(list, ordering);

另一个使用静态方法的例子也在doc中给出:

public interface TimeClient {
    // ...
    static public ZoneId getZoneId (String zoneString) {
        try {
            return ZoneId.of(zoneString);
        } catch (DateTimeException e) {
            System.err.println("Invalid time zone: " + zoneString +
                "; using default time zone instead.");
            return ZoneId.systemDefault();
        }
    }

    default public ZonedDateTime getZonedDateTime(String zoneString) {
        return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString));
    }    
}