Да, компилятор Java заменяет статические постоянные значения, такие как SIZE в вашем примере, их литеральными значениями.

Таким образом, если вы позже измените SIZE в классе A, но не перекомпилируете класс b, вы все равно увидите старое значение в классе b. Вы можете легко проверить это:

файл A.java

public class A {
    public static final int VALUE = 200;
}

файл B.java

public class B {
    public static void main(String[] args) {
        System.out.println(A.VALUE);
    }
}

Скомпилируйте A.java и B.java. Теперь запустите: java B

Измените значение в A.java. Перекомпилируйте A.java, но не B.java. Запустите снова, и вы увидите, что печатается старое значение.

Вы можете предотвратить компиляцию константы в B, выполнив

class A
{  
    public static final int SIZE;

    static 
    {
        SIZE = 100;
    }
}  

Ву - каждый день узнаешь что-то новое!

Взято из спецификации Java...

Примечание. Если примитивный тип или строка определены как константы и значение известно во время компиляции, компилятор заменяет имя константы везде в коде ее значением. Это называется константой времени компиляции. Если значение константы во внешнем мире изменится (например, если законодательно установлено, что число пи на самом деле должно быть 3,975), вам потребуется перекомпилировать все классы, использующие эту константу, чтобы получить текущее значение.

Еще один способ доказать, что это поведение — посмотреть на сгенерированный байт-код. Когда константа "маленькая" (предположительно ‹ 128):

public B();
  Code:
   0:   aload_0
   1:   invokespecial   #10; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   bipush  42
   7:   anewarray       #3; //class java/lang/Object
   10:  putfield        #12; //Field temp:[Ljava/lang/Object;
   13:  return

}

(Я использовал 42 вместо 100, чтобы он больше выделялся). В данном случае он явно подставляется в байт-коде. Но, скажем, константа «больше». Затем вы получаете байт-код, который выглядит так:

public B();
  Code:
   0:   aload_0
   1:   invokespecial   #10; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   ldc     #12; //int 86753098
   7:   anewarray       #3; //class java/lang/Object
   10:  putfield        #13; //Field temp:[Ljava/lang/Object;
   13:  return

Когда он больше, используется код операции «ldc», который согласно документация JVM "байт без знака, который должен быть действительным индексом в пуле констант времени выполнения текущего класса".

В любом случае константа встроена в B. Я предполагаю, что, поскольку в кодах операций вы можете получить доступ только к текущему пулу констант времени выполнения классов, это решение записать константу в файл класса не зависит от реализации (но я не это точно знаю).

Важной концепцией здесь является то, что поле static final инициализируется константой времени компиляции, как определено в JLS. Используйте непостоянный инициализатор (или не-2_ или не-final), и он не будет скопирован:

public static final int SIZE = null!=null?0: 100;

(null не является константой времени компиляции.)

На самом деле я столкнулся с этой странностью некоторое время назад.

Это скомпилирует "100" непосредственно в класс b. Если вы просто перекомпилируете класс A, это не обновит значение в классе B.

Кроме того, компилятор может не заметить перекомпиляции класса b (в то время, когда я компилировал отдельные каталоги, а класс B находился в отдельном каталоге, а компиляция каталога a не запускала компиляцию B)

В качестве оптимизации компилятор встроит эту переменную final.

Итак, во время компиляции это будет выглядеть так.

class b
{
      Object[] temp = new Object[100];
}

Следует отметить одну вещь: статическое конечное значение известно во время компиляции, если значение неизвестно во время компиляции, компилятор не будет заменять имя константы везде в коде. с его значением.

  public class TestA {
      // public static final int value = 200;
      public static final int value = getValue();
      public static int getValue() {
        return 100;
      }
  }

public class TestB {
    public static void main(String[] args) {
        System.out.println(TestA.value);
    }
}

сначала скомпилируйте TestA и TestB, запустите TestB

затем измените TestA.getValue(), чтобы он возвращал 200, скомпилируйте TestA, запустите TestB, TestB получит новое значение введите здесь описание изображения

Есть исключение: -

Если во время компиляции поле static final имеет значение null, оно не заменяется значением null (которое на самом деле является его значением)

А.ява

class A{
     public static final String constantString = null;
}

Б.ява

class B{
     public static void main(String... aa){
         System.out.println(A.constantString);
     }
}

Скомпилируйте и A.java, и B.java и запустите java B.

Вывод будет null

Теперь обновите A.java следующим кодом и скомпилируйте только этот класс.

class A{
     public static final String constantString = "Omg! picking updated value without re-compilation";
}

Теперь запустите java B.

Вывод будет О боже! выбор обновленного значения без повторной компиляции

Java оптимизирует такие значения, но только если они находятся в одном классе. В этом случае JVM смотрит в A.SIZE, а не оптимизирует его из-за варианта использования, который вы рассматриваете.