Отключить ведение журнала в Java во время компиляции

Question

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

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

Но я бы хотел избежать построения параметров, как показано ниже в моем производственном коде:

Logger.log("undefined state" + state + " @ " + new Date());

Я использую Sun Java Compiler.

Answer 1

Рассматривали ли вы подход slf4j с {} -местителями.Это допускает отложенное построение toString (), означающее, что log.debug (...) дешев, если ведение журнала отладки отключено.

log.debug("in loop() - a={}, b={}", a, b);

Answer 2

Можно выполнить постобработку файлов классов java с помощью Proguard и использовать опцию -assumenosideeffects для удаления регистрации вызовов. Это делается чаще всего для Android, используя:

-assumenosideeffects class android.util.Log {
    public static *** d(...);
    public static *** v(...);
}

чтобы удалить все звонки на Log.d(TAG, "message") и т.д ...

Answer 3

if(logger.isDebugEnabled()) {
  logger.debug(expression);
}

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

Answer 4

Казалось бы, это то, что вы ищете:

что на самом деле делает log4j, когда мы включаем или выключаем некоторые журналы?

Answer 5

Один из способов - выполнить проверку вне метода журнала. Почти такая же проверка, как вы упомянули, но вы делаете это сами:

if (LOGGER.isLoggable(Level.DEBUG)) {
    LOGGER.log("undefined state" + state + " @ " + new Date());
}

Этот метод может использоваться с любым уровнем ведения журнала. см. Logger # isLoggable (Level) для получения дополнительной информации. Обратите внимание, что это рекомендуемый способ избежать построения параметров метода журнала.

Answer 6

Нет встроенного способа, который сделал бы это возможным.Вы можете использовать препроцессор Java .

Answer 7

Я понимаю, что компилятор Java способен исключать блоки кода, которые защищены выражением постоянной времени компиляции.Таким образом, теоретически вы должны быть в состоянии сделать это примерно так:

 public class Logging {
     public static final boolean ENABLED = true;  // change to false
 }

 public class Something
     ....

     if (Logging.ENABLED) {
          logger.debug("hello mum");
     }
 }

К сожалению, вам нужно перекомпилировать каждый класс, который зависит от флага Logging.ENABLED, всякий раз, когда вы изменяете его значение.Поэтому я очень предпочитаю следующее:

public class Something
     ....

     if (logger.isDebugEnabled()) {
          logger.debug("hello mum");
     }
 }

, что имеет то преимущество, что вы можете делать детальные корректировки уровней ведения журнала во время конфигурации или даже во время выполнения;например, с использованием отладчика, JMX и т. д. Кроме того, накладные расходы на вызов logger.isDebugEnabled() в log4j достаточно малы, поэтому они вряд ли будут заметны, если у вас нет безумного количества входов в базу кода.

Answer 8

Вы действительно должны использовать индикатор уровня для сообщений журнала, Level.SEVERE -> Level.FINEST.

Для этого есть предопределенные методы в Logger, т. Е.

Logger.info(msg);
Logger.finest(msg); // debug/trace message.

Logger.log(Level.CONFIG, "config message");

это позволит вам настроить минимальный уровень ведения журнала на уровне приложения и включить / выключить эти сообщения ниже настроенного уровня с помощью командной строки, файлов конфигурации или вручную с помощью LogManager

Answer 9

Гадкий взлом, который может сработать, - скрыть реализацию библиотеки Logger с пустой реализацией.Оптимизатор встроит их, а удаление мертвого кода должно удалить конструкцию параметра.Это не будет работать, если в конструкции параметра есть побочные эффекты.

Теперь это теория, я не проверял это на практике.Мне любопытно об этом все же.Может быть, это требует отдельного вопроса?

Answer 10

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