Java if (false) Скомпилировать

Я разрабатываю динамический веб-проект с использованием Tomcat. Полезно иметь глобальный флаг, который является единственным, что я должен изменить между моими серверами разработки и развертывания. Наибольшее использование флага связано с операциями печати.

public class Debug {
    public final static boolean DEVEL = true;        
    public static void print(String message){
        if(DEVEL){
            System.out.println(message);
        }
    }
}

Мой вопрос в том, будет ли java компилировать инструкции печати. т.е. если тег devel является ложным, сообщения, очевидно, не будут печататься, но будут ли они включены в файлы классов (окончательное окончание). Это вопрос эффективности. Я слышал, что java-компилятор очень умный, но он подберет это.

Ответ 1

используйте атрибут 'final' (как и вы), и он скомпилирует код:

public static final boolean DEVEL = false;

Вы можете проверить, если grepping результирующий файл класса для строки, которая появится только в том случае, если код был скомпилирован.

Ответ 2

Взгляните на эту статью:

http://www.javaworld.com/javaworld/jw-03-2000/jw-03-javaperf_4.html

Представленный вами код называется "мертвым кодом", поэтому он не будет включен в скомпилированный файл класса, если вы установите DEVEL на false, он не будет включен в байт-код.

Кроме того, проверьте команду

javap -c

чтобы увидеть полученный байт-код вашего класса.

Ответ 3

Если вы хотите, чтобы компилятор не скомпилировал его, используйте это:

    public final static boolean DEVEL = Math.random() > -1;

Компилятор не будет знать, что это всегда true. (конечно, используйте < -1 для false)

Я нахожу этот трюк удобным, когда вы хотите временно удалить код, если компилятор не жалуется на мертвый код, например:

void myMethod() {
    // temporarily exit early
    if (Math.random() > -1) return;
    // usual code
}

Ответ 4

Я никогда не видел, чтобы компилятор удалял такой код, однако JIT эффективно удалит код, который никогда не запускается. Утверждения являются распространенным прецедентом для этого. Там все еще может быть условная стоимость, но, как правило, об этом не стоит беспокоиться. то есть менее 1 наносекунды.

Ответ 5

Стоимость может быть больше, если метод toString() сообщения является дорогостоящим. Метод toString большого sql-запроса в подготовленном операторе вызвал переполнение кучи из-за этой строки. Таким образом, стандарт не удалял его.