Я не очень понимаю, что происходит или почему он жалуется в первую очередь:
Причина жалобы в первом примере заключается в том, что вы безусловно проделал большую работу по созданию сообщения журнала. Работа будет потрачена впустую, если уровень журнала выше, чем INFO.
Второй пример лучше первого, поскольку строка сообщения журнала создается из шаблона только в том случае, если уровень журнала равен INFO или ниже. Выражение pointcut.getSignature().getName() по-прежнему оценивается безоговорочно, но это может быть неизбежно в зависимости от используемого вами API ведения журнала c.
(Если вы оцениваете это дорого, у вас все еще есть проблема с производительностью. Вы можете посмотреть на использование if (log.isInfoLevel()) { ... } guard или чего-то такого, что сделает вычисление выражения ленивым; например, Supplier<String>. Но лучшее решение может быть, чтобы избежать записи этого дорогого выражения.)
Жалоба сонара во втором примере, похоже, касается конкретного синтаксиса, который вы использовали в строке сообщения / формата. @ C. Ответ Лечнера объясняет это так:
- В первой версии с {} тип {} оценивается во время выполнения.
- Во второй с % s,% d вы определяете тип во время компиляции.
Если возможно, вы должны использовать тип, чтобы избежать неправильного использования переменных-заполнителей и позволить компилятору java выполнить некоторые дополнительные проверки.
Я не совсем уверен, что компилятор Java сделает проверку. (Это, конечно, не требуется для JLS.) Но вполне вероятно, что компилятор или (умный) анализатор кода stati c может проверить.
В любом случае строка формата будет проверена (снова ) во время выполнения.
Наконец, эта версия:
String logMessage = String.format("Execution of method %s finished in %d ms",
pointcut.getSignature().getName(), ms);
log.info(logMessage);
имеет ту же проблему с производительностью, что и первая версия, но я подозреваю, что Sonar не достаточно умен, чтобы понять это .