Оптимизирует ли компилятор Java ненужный тернарный оператор?

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

При этом поведение компилятора в этом отношении можно легко проверить, сравнив байт-код, скомпилированный JVM.
Вот два фиктивных класса, чтобы проиллюстрировать это:

Случай I (без тернарного оператора):

class Class {

    public static void foo(int a, int b, int c) {
        boolean val = (a == c && b != c);
        System.out.println(val);
    }

    public static void main(String[] args) {
       foo(1,2,3);
    }
}

Случай II (с тернарным оператором):

class Class {

    public static void foo(int a, int b, int c) {
        boolean val = (a == c && b != c) ? true : false;
        System.out.println(val);
    }

    public static void main(String[] args) {
       foo(1,2,3);
    }
}

Байт-код для метода foo() в случае I:

       0: iload_0
       1: iload_2
       2: if_icmpne     14
       5: iload_1
       6: iload_2
       7: if_icmpeq     14
      10: iconst_1
      11: goto          15
      14: iconst_0
      15: istore_3
      16: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
      19: iload_3
      20: invokevirtual #3                  // Method java/io/PrintStream.println:(Z)V
      23: return

Байт-код для метода foo() в случае II:

       0: iload_0
       1: iload_2
       2: if_icmpne     14
       5: iload_1
       6: iload_2
       7: if_icmpeq     14
      10: iconst_1
      11: goto          15
      14: iconst_0
      15: istore_3
      16: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
      19: iload_3
      20: invokevirtual #3                  // Method java/io/PrintStream.println:(Z)V
      23: return

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

ИЗМЕНИТЬ:

Разговор по этому вопросу пошел по одному из нескольких направлений.
Как показано выше, в обоих случаях (с избыточной тройкой или без нее) скомпилированный байт-код java идентичен.
Может ли компилятор Java рассматривать это как оптимизацию, зависит от вашего определения оптимизации. В некоторых отношениях, как неоднократно указывалось в других ответах, имеет смысл утверждать, что нет - это не оптимизация, а тот факт, что в обоих случаях сгенерированный байт-код представляет собой простейший набор операций стека, который выполняет эта задача, независимо от троичной.

Однако по основному вопросу:

Очевидно, было бы лучше просто присвоить результат оператора логической переменной, но разве это важно для компилятора?

Простой ответ - нет. Компилятору все равно.

Вопреки ответам Павла Хорала, Codo и yuvgin Я утверждаю, что компилятор НЕ оптимизирует (или игнорирует) тернарный оператор. (Пояснение: я имею в виду компилятор Java в байт-код, а не JIT)

Смотрите тестовые примеры.

Класс 1: оценивает логическое выражение, сохраняет его в переменной и возвращает эту переменную.

public static boolean testCompiler(final int a, final int b)
{
    final boolean c = ...;
    return c;
}

Итак, для разных булевых выражений проверяем байт-код: 1. Выражение: a == b

Байт-код

   0: iload_0
   1: iload_1
   2: if_icmpne     9
   5: iconst_1
   6: goto          10
   9: iconst_0
  10: istore_2
  11: iload_2
  12: ireturn

2. Выражение: a == b ? true : false

Байт-код

   0: iload_0
   1: iload_1
   2: if_icmpne     9
   5: iconst_1
   6: goto          10
   9: iconst_0
  10: istore_2
  11: iload_2
  12: ireturn

3. Выражение: a == b ? false : true

Байт-код

   0: iload_0
   1: iload_1
   2: if_icmpne     9
   5: iconst_0
   6: goto          10
   9: iconst_1
  10: istore_2
  11: iload_2
  12: ireturn

Случаи (1) и (2) компилируются в один и тот же байт-код не потому, что компилятор оптимизирует тернарный оператор, а потому, что ему необходимо каждый раз выполнять этот тривиальный тернарный оператор. На уровне байт-кода необходимо указать, следует ли возвращать true или false. Чтобы убедиться в этом, посмотрите на случай (3). Это точно такой же байт-код, за исключением строк 5 и 9, которые поменялись местами.

Что происходит тогда и a == b ? true : false при декомпиляции дает a == b? Это выбор декомпилятора, который выбирает самый простой путь.

Кроме того, на основе эксперимента «Класс 1» разумно предположить, что a == b ? true : false точно такое же, как a == b в том, как оно транслируется в байт-код. Однако это не так. Чтобы проверить это, мы исследуем следующий «Класс 2», единственная разница с «Классом 1» заключается в том, что он не сохраняет логический результат в переменной, а вместо этого немедленно возвращает его.

Класс 2: оценка логического выражения и возврат результата (без сохранения его в переменной).

public static boolean testCompiler(final int a, final int b)
{
    return ...;
}

• 1. a == b

Байт-код:

   0: iload_0
   1: iload_1
   2: if_icmpne     7
   5: iconst_1
   6: ireturn
   7: iconst_0
   8: ireturn

• 2. a == b ? true : false

Байт-код

   0: iload_0
   1: iload_1
   2: if_icmpne     9
   5: iconst_1
   6: goto          10
   9: iconst_0
  10: ireturn

• 3. a == b ? false : true

Байт-код

   0: iload_0
   1: iload_1
   2: if_icmpne     9
   5: iconst_0
   6: goto          10
   9: iconst_1
  10: ireturn

Здесь очевидно, что a == b и a == b ? true : false выражения компилируются по-разному, так как случаи (1) и (2) дают разные байт-коды (случаи (2) и (3), как и ожидалось, поменялись местами только их строки 5,9).

Сначала это меня удивило, так как я ожидал, что все 3 случая будут одинаковыми (за исключением переставленных строк 5,9 случая (3)). Когда компилятор встречает a == b, он оценивает выражение и сразу после него возвращается, в отличие от встречи с a == b ? true : false, где он использует goto для перехода к строке ireturn. Я понимаю, что это сделано для того, чтобы оставить место для оценки потенциальных утверждений внутри «истинного» случая тернарного оператора: между проверкой if_icmpne и строкой goto. Даже если в данном случае это просто логическое значение true, компилятор обрабатывает его так же, как в общем случае, когда присутствует более сложный блок.
С другой стороны, "класс 1" скрыл этот факт, так как в ветке true были также istore, iload и не только ireturn, форсирующие команду goto и приводившие к точно такому же байт-коду в случаях (1) и (2).

В качестве примечания относительно тестовой среды: эти байт-коды были созданы с помощью последней версии Eclipse (4.10), в которой используется соответствующий компилятор ECJ, отличный от javac, который использует IntelliJ IDEA.

Однако, читая созданный javac байт-код в других ответах (которые используют IntelliJ), я считаю, что та же логика применима и там, по крайней мере, для эксперимента «Класс 1», где значение было сохранено и не возвращено немедленно.

Наконец, как уже указывалось в других ответах (например, от supercat и jcsahnwaldt) , как в этой теме, так и в других вопросах SO тяжелая оптимизация выполняется компилятором JIT, а не компилятором java-->java-bytecode, поэтому эти проверки, хотя и информативные для перевода байт-кода, не являются хорошей мерой того, как будет выполняться окончательный оптимизированный код.

Дополнение: ответ jcsahnwaldt сравнивает созданный javac и ECJ байт-код для аналогичных случаев.

(В качестве отказа от ответственности: я не изучал компиляцию или дизассемблирование Java так много, чтобы на самом деле знать, что он делает под капотом; мои выводы в основном основаны на результатах приведенных выше экспериментов.)

Да, компилятор Java оптимизирует. Это легко проверить:

public class Main1 {
  public static boolean test(int foo, int bar, int baz) {
    return foo == bar && bar == baz ? true : false;
  }
}

После javac Main1.java и javap -c Main1:

  public static boolean test(int, int, int);
    Code:
       0: iload_0
       1: iload_1
       2: if_icmpne     14
       5: iload_1
       6: iload_2
       7: if_icmpne     14
      10: iconst_1
      11: goto          15
      14: iconst_0
      15: ireturn

public class Main2 {
  public static boolean test(int foo, int bar, int baz) {
    return foo == bar && bar == baz;
  }
}

После javac Main2.java и javap -c Main2:

  public static boolean test(int, int, int);
    Code:
       0: iload_0
       1: iload_1
       2: if_icmpne     14
       5: iload_1
       6: iload_2
       7: if_icmpne     14
      10: iconst_1
      11: goto          15
      14: iconst_0
      15: ireturn

Оба примера заканчиваются одним и тем же байт-кодом.

Компилятор javac обычно не пытается оптимизировать код перед выводом байт-кода. Вместо этого он полагается на виртуальную машину Java (JVM) и JIT-компилятор, который преобразует байт-код в машинный код для ситуаций, когда конструкция эквивалентна более простой конструкции.

Это значительно упрощает определение того, правильно ли работает реализация компилятора Java, поскольку большинство конструкций могут быть представлены только одной предопределенной последовательностью байт-кодов. Если компилятор создает любую другую последовательность байт-кода, она нарушается, даже если эта последовательность будет вести себя так же, как исходная.

Изучение байт-кода, выводимого компилятором javac, не является хорошим способом судить о том, будет ли конструкция выполняться эффективно или неэффективно. Вполне вероятно, что может быть какая-то реализация JVM, в которой такие конструкции, как (someCondition ? true : false), будут работать хуже, чем (someCondition), а в некоторых случаях они будут работать одинаково.

В IntelliJ я скомпилировал ваш код и открыл файл класса, который автоматически декомпилируется. Результат:

boolean val = foo == bar && foo1 != bar;

Так что да, компилятор Java оптимизирует его.

Я хотел бы обобщить прекрасную информацию, представленную в предыдущих ответах.

Давайте посмотрим, что делают javac Oracle и ecj Eclipse со следующим кодом:

boolean  valReturn(int a, int b) { return a == b; }
boolean condReturn(int a, int b) { return a == b ? true : false; }
boolean   ifReturn(int a, int b) { if (a == b) return true; else return false; }

void  valVar(int a, int b) { boolean c = a == b; }
void condVar(int a, int b) { boolean c = a == b ? true : false; }
void   ifVar(int a, int b) { boolean c; if (a == b) c = true; else c = false; }

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

Я скомпилировал код с помощью javac и ecj, а затем декомпилировал его с помощью Oracle javap.

Вот результат для javac (я пробовал javac 9.0.4 и 11.0.2 - они генерируют точно такой же код):

boolean valReturn(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: ireturn

boolean condReturn(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: ireturn

boolean ifReturn(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     7
     5: iconst_1
     6: ireturn
     7: iconst_0
     8: ireturn

void valVar(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: istore_3
    11: return

void condVar(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: istore_3
    11: return

void ifVar(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     10
     5: iconst_1
     6: istore_3
     7: goto          12
    10: iconst_0
    11: istore_3
    12: return

А вот результат для ecj (версия 3.16.0):

boolean valReturn(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     7
     5: iconst_1
     6: ireturn
     7: iconst_0
     8: ireturn

boolean condReturn(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: ireturn

boolean ifReturn(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     7
     5: iconst_1
     6: ireturn
     7: iconst_0
     8: ireturn

void valVar(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: istore_3
    11: return

void condVar(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     9
     5: iconst_1
     6: goto          10
     9: iconst_0
    10: istore_3
    11: return

void ifVar(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmpne     10
     5: iconst_1
     6: istore_3
     7: goto          12
    10: iconst_0
    11: istore_3
    12: return

Для пяти из шести функций оба компилятора генерируют один и тот же код. Единственная разница заключается в valReturn: javac генерирует goto для ireturn, а ecj генерирует ireturn. Для condReturn они оба генерируют от goto до ireturn. Для ifReturn они оба генерируют ireturn.

Означает ли это, что один из компиляторов оптимизирует один или несколько таких случаев? Можно подумать, что javac оптимизирует код ifReturn, но не может оптимизировать valReturn и condReturn, а ecj оптимизирует ifReturn и valReturn, но не оптимизирует condReturn.

Но я не думаю, что это правда. Компиляторы исходного кода Java в основном вообще не оптимизируют код. Компилятор, который делает оптимизацию кода, — это компилятор JIT (точно в срок) (часть JVM, которая компилирует байтовый код в машинный код), и компилятор JIT может выполнять свою работу лучше, если байтовый код относительно прост, т.е. не оптимизирован.

В двух словах: нет, компиляторы исходного кода Java не оптимизируют этот случай, потому что на самом деле они ничего не оптимизируют. Они делают то, что от них требуют спецификации, но не более того. Разработчики javac и ecj просто выбрали несколько разные стратегии генерации кода для этих случаев (предположительно по более или менее произвольным причинам).

См. эти Переполнение стека вопросы еще несколько деталей.

(Пример: оба компилятора в настоящее время игнорируют флаг -O. Опции ecj явно говорят об этом: -O: optimize for execution time (ignored). javac больше не упоминает флаг и просто игнорирует его.)