このようには見えません。しかし、少し気をつけて、おそらくisDebugEnabled()のようなガード機能なしで行うことができます。ロガーは通常、文字列をフォーマットする前にロギング機能の内部でログレベルをチェックします。ロギングレベルが一致すると判断した場合は、フォーマットされた文字列に含めるために渡されたパラメータにtoString()を呼び出すことを含む文字列のフォーマットが行われます。 loggerメソッドに直接渡された複雑な式を避け、ログに書きたい式を評価する関数toString()をオブジェクトにカプセル化すると、ガード式を使用せずにガード式の利点を得ることができます。
vertxがapiをJULログにバインドする方法がわかりません。最初のObjectパラメーターがJULのSupplierパラメーターとして渡されることがあります。そうでない場合は、以下のテクニックを試してみてください。このテクニックは、そのパラメータに対してtoString（）を呼び出す一般的な文字列ロギングメカニズムに適合させることができます。この例では
debug("Doing something with {}", some_expression_that_is_expensive);
、some_expression_that_is_expensiveでデバッグログが有効になっているかどうか、debug関数が呼び出されるたびに呼び出されます：
はSLF4Jのパラメータ表記を使用して次のことを、考えてみましょう。あなたの代わりに、このような
class EncapsulatedExpression {
@Override
public String toString() {
return some_expression_that_is_expensive;
}
}
としてクラスを持っていた場合、あなたは
debug("Doing something with {}", new EncapsulatedExpression());
を呼び出してから、some_expression_that_is_expensiveができ、ログレベルはデバッグした場合にのみ呼び出されます。
あなたはSupplierはそう、あなたがそのtoString()Supplierは、原因となるカプセル化することができます何かを作成するためのツールが必要になります欲しいものを得るために、より一般的な方法で同様の遅延評価を提供するだろうと言って正しい軌道に乗っていますサプライヤは評価されるべきである。おそらく、このような何かが働くだろう：
debug("Doing something with {}", lazily(() -> some_expression_that_is_expensive));
：
class ToStringSupplier<T> {
private Supplier<T> supplier;
public ToStringSupplier(Supplier<T> supplier){
this.supplier = supplier;
}
public static <T> ToStringSupplier<T> lazily(Supplier<T> supplier){
return new ToStringSupplier<>(supplier);
}
@Override
public String toString(){
return Objects.toString(supplier.get()); // supplier could safely return null
}
}
をあなたはこのようにそれを使用することができます