Por que não campos abstratos?

Por que as classes Java não podem ter campos abstratos como podem ter métodos abstratos?

Por exemplo: eu tenho duas classes que estendem a mesma classe base abstrata. Cada uma dessas duas classes tem um método idêntico, exceto por uma constante String, que por acaso é uma mensagem de erro, dentro delas. Se os campos pudessem ser abstratos, eu poderia tornar essa constante abstrata e puxar o método para a classe base. Em vez disso, tenho que criar um método abstrato, chamado getErrMsg()neste caso, que retorna String, sobrescrever esse método nas duas classes derivadas e, então, posso puxar o método (que agora chama o método abstrato).

Por que eu não poderia simplesmente tornar o campo abstrato para começar? O Java poderia ter sido projetado para permitir isso?

Você pode fazer o que descreveu tendo um campo final em sua classe abstrata que é inicializado em seu construtor (código não testado):

abstract class Base {

    final String errMsg;

    Base(String msg) {
        errMsg = msg;
    }

    abstract String doSomething();
}

class Sub extends Base {

    Sub() {
        super("Sub message");
    }

    String doSomething() {

        return errMsg + " from something";
    }
}

Se sua classe filha "esquecer" de inicializar o final por meio do super construtor, o compilador dará um aviso de erro, assim como quando um método abstrato não é implementado.

Não vejo sentido nisso. Você pode mover a função para a classe abstrata e apenas substituir algum campo protegido. Não sei se funciona com constantes, mas o efeito é o mesmo:

public abstract class Abstract {
    protected String errorMsg = "";

    public String getErrMsg() {
        return this.errorMsg;
    }
}

public class Foo extends Abstract {
    public Foo() {
       this.errorMsg = "Foo";
    }

}

public class Bar extends Abstract {
    public Bar() {
       this.errorMsg = "Bar";
    }
}

Então, o que você quer dizer é que você quer impor a implementação / substituição / qualquer coisa errorMsgnas subclasses? Achei que você só queria ter o método na classe base e não sabia como lidar com o campo na época.

Obviamente, ele poderia ter sido projetado para permitir isso, mas nos bastidores ainda teria que fazer o despacho dinâmico e, portanto, uma chamada de método. O design de Java (pelo menos nos primeiros dias) foi, até certo ponto, uma tentativa de ser minimalista. Ou seja, os designers tentaram evitar a adição de novos recursos se eles pudessem ser facilmente simulados por outros recursos já existentes na linguagem.

Lendo seu título, pensei que você estava se referindo a membros de instância abstratos; e eu não via muito uso para eles. Mas membros estáticos abstratos é outra questão completamente.

Muitas vezes desejei poder declarar um método como o seguinte em Java:

public abstract class MyClass {

    public static abstract MyClass createInstance();

    // more stuff...

}

Basicamente, gostaria de insistir que as implementações concretas de minha classe pai fornecem um método de fábrica estático com uma assinatura específica. Isso me permitiria obter uma referência a uma classe concreta com Class.forName()e ter certeza de que poderia construir uma em uma convenção de minha escolha.

Outra opção é definir o campo como público (final, se preferir) na classe base e, em seguida, inicializar esse campo no construtor da classe base, dependendo de qual subclasse está sendo usada no momento. É um pouco obscuro, pois introduz uma dependência circular. Mas, pelo menos, não é uma dependência que pode mudar - ou seja, a subclasse existirá ou não, mas os métodos ou campos da subclasse não podem influenciar o valor de field.

public abstract class Base {
  public final int field;
  public Base() {
    if (this instanceof SubClassOne) {
      field = 1;
    } else if (this instanceof SubClassTwo) {
      field = 2;
    } else {
      // assertion, thrown exception, set to -1, whatever you want to do 
      // to trigger an error
      field = -1;
    }
  }
}