DEBUG и RELEASE строятся на Java (Eclipse)?

Question

Новое в Java и Eclipse (но с Visual Studio и Delphi). Использование Eclipse Mars (4.5) и не может найти, как установить конфигурацию сборки (DEBUG или RELEASE). Несколько связанных вопросов:

• Поддерживаются ли DEBUG/RELEASE в Java?
• Как вы переключаетесь между двумя конфигурациями?
• Вы можете обнаружить конфигурации во время сборки и запуска условного кода, как это (с использованием Delphi в качестве примера): {$IFDEF DBG} CallDebugFunction(); {$ELSE} CallReleaseFunction(); {$ENDIF};

Answer 1

DEBUG/RELEASE не в точности поддерживается в Java. Но есть несколько фактов, которые полезно запомнить, и несколько других способов выполнения частей того же самого.

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

Ключевое слово assert, к которому относится Java, относится к типу DEBUG/RELEASE. Вы можете контролировать, будут ли утверждения оцениваться путем подачи на виртуальную машину параметра -assertionsenabled (-ea для краткости). Прочитайте это, а также прочитайте, как передать параметры виртуальной машине.

Обратите внимание, что параметры виртуальной машины являются параметрами времени выполнения, они не имеют ничего общего с компилятором, что означает, что компилятор всегда будет испускать утверждения в байт-код, а если вы не укажете -ea, тогда среда выполнения воздержит от оценивая их. Таким образом, по крайней мере всегда будет скрытый оператор if(assertionsEnabled) { ... } для выполнения для каждого утверждения.

Другого дело, стоит вспомнить, что public static final переменных рассматриваются как время компиляции константы, и компилятор может избежать излучающего любые байт-кода для исходного кода, управляемого if(false) пункта. Однако исходный код всегда будет скомпилирован, поэтому он должен быть правильным, несмотря на то, что байт-код не будет сгенерирован.

Таким образом, вы можете иметь глобальную переменную, определенную как public static final boolean DEBUG = true, для управления всем вашим кодом отладки, но вам придется вручную изменить ее в исходном коде и перестроить проект, чтобы создать сборку выпуска; java специально воздерживается от предоставления любого другого способа этого.

Также обратите внимание, что if(false) (и по расширению if(DEBUG)) выдаст предупреждение о том, что условие всегда верно или всегда неверно, поэтому я не люблю его использовать.

Философия java заключается в том, что мы, как правило, не заботимся о производительности в такой степени параноидальности, что хотим иметь полный контроль над небольшими различиями в производительности между DEBUG и RELEASE. Как правило, ключевое слово assert - это все, что необходимо, и на самом деле (к моему ужасу) большинство людей джава даже не используют аргументы из-за различных (хромых, IMHO) причин.

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

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

Возможно, вы с удовольствием узнаете, что все это не так уж плохо из-за JITting: байт-код скомпилирован в машинный код VM, и на этом этапе выполняется много оптимизаций, поэтому вы всегда получаете выгоду от них, а не просто на RELEASE.

Что касается определения, включено ли утверждение, вы можете использовать следующий код:

static boolean areAssertionsEnabled() 
{ 
    //noinspection UnusedAssignment 
    boolean b = false; 
    //noinspection ConstantConditions,AssertWithSideEffects 
    assert b = true; 
    //noinspection ConstantConditions 
    return b; 
} 

В noinspection рюшечках предназначены для подавления предупреждений в IntelliJ IDEA, в Java IDE, который намного превосходит Eclipse. Если вы настаиваете на использовании Eclipse, вам придется найти для него эквивалентные механизмы подавления предупреждений.