почему статический блок не может получить доступ к статической переменной, определенной после него

Статические поля инициализируются на основе порядка их появления в коде.

Итак, когда вы присваиваете значение переменной i, вы просто говорите компилятору: «Эй, парень, когда ты будешь инициализировать эту переменную, установи ее значение в…». Но вы не можете использовать его, пока он не будет инициализирован, потому что его просто еще не существует.

ОБНОВЛЕНИЕ:

Как сказано в книге «Спецификация языка Java» Джеймса Гослинга, Билла Джоя, Гая Стила и Гилада Брачи:

Эти ограничения предназначены для обнаружения во время компиляции циклических или иным образом искаженных инициализаций.

Учти это:

static {
            i = 2;
            j = i + 5; //should it be 7 or 15?
}
static int i = 10;
static int j;

Должна ли переменная j быть 7 или 15? Если 7, то мы дважды инициализировали переменную i, что невозможно, так как поле статичное. Если 15, то что означает i = 2;?

Этот код неоднозначен, поэтому Спецификация Java не позволяет этого сделать.

После некоторого дальнейшего чтения я думаю, что Павел не совсем точен в этом вопросе, поскольку @Holger указал в комментарии.

мы дважды инициализировали переменную i, что невозможно, так как поле статическое.

Согласно 12.4.2. Подробная процедура инициализации указывает

Для каждого класса или интерфейса C существует уникальная блокировка инициализации LC. Отображение из C в LC оставлено на усмотрение реализации виртуальной машины Java.

Я полагаю, что инициализация дважды подходит для самого инициализатора класса, если только один раз для вызывающих клиентов.

Но демонстрация, предоставленная Павлом, по-прежнему сохраняет свою позицию, поэтому я в основном просто использую ее здесь, но с другим объяснением.

static {
       i = 2;
       j = i + 5; 
       // no one knows whether "i" here initialized properly here
}
static int i = 10;
static int j;

Но когда вы используете MyClass.i непосредственно в j = MyClass.i + 5, компилятор будет знать, что все будет в порядке, как 8.3.3. Пересылка ссылок во время инициализации поля с четырьмя условиями.

В частности, это ошибка времени компиляции, если выполняются все следующие утверждения:

1. Объявление переменной класса в классе или интерфейсе C появляется текстуально после использования переменной класса;

2. Использование — простое имя либо в инициализаторе переменной класса C, либо в статическом инициализаторе C;

3. Использование не находится в левой части присваивания;

4. C является самым внутренним классом или интерфейсом, включающим использование.

И в этом ответе уже есть подробное обсуждение.

В заключение я думаю, что для предсказуемого поведения нужно добавить эти ограничения. Еще раз, другая официальная цель указана в 8.3.3. Пересылка ссылок во время инициализации поля.

Эти ограничения предназначены для обнаружения во время компиляции циклических или иным образом искаженных инициализаций.

То же самое применимо и к нестатическим элементам. Вы можете присвоить им значения в блоке инициализатора экземпляра, но не можете использовать их до инициализации.

class Parent {
    {
        x = 3; // works fine
        // System.out.println(x); // gives compilation error.

    }
    int x = 0;

    public static void main(String[] args) {

    }
}