おそらく BigDecimal.valueOf(double d) メソッドの使用が望ましいです。BigDecimal(たとえば、BigDecimal.valueOf(0.1) は0.1を与えます) を作成するためには double の文字列表現を使用します。

FindBugs は、HRS の最も露骨で自明なケースだけを探します。 FindBugs が何かを派遣したならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 HRS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

FindBugs は、HRS の最も露骨で自明なケースだけを探します。 FindBugs が何かを見つけたならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 HRS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

FindBugs は、相対パストラバーサルの最も露骨で自明なケースだけを探します。 FindBugs が何かを見つけたならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 相対パストラバーサルを心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

FindBugs は、相対パストラバーサルの最も露骨で自明なケースだけを探します。 FindBugs が何かを見つけたならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 相対パストラバーサルを心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

FindBugs は、XSS の最も露骨で自明なケースだけを探します。 FindBugs が何かを見つけたならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 XSS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

FindBugs は、XSS の最も露骨で自明なケースだけを探します。 FindBugs が何かを見つけたならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 XSS を心配するなら、商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

FindBugs は、XSS の最も露骨で自明なケースだけを探します。 FindBugs が何かを見つけたならほぼ間違いなく FindBugs が報告しないより多くの脆弱性があるでしょう。 XSS に関して心配しているなら商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討するべきです。

Number[] arr = new Integer[10];
arr[0] = 1.0;

作成した配列の型またはフィールド型を変更することを検討してください。

Number[] arr = new Integer[10];
arr[0] = 1.0;

作成した配列の型またはローカル変数型を変更することを検討してください。

作成した配列の型またはメソッドの戻り型を変更することを検討してください。

すべての clone メソッドが super.clone() を呼び出すなら Object.clone() が呼び出されることが保証され、常に正しい型のオブジェクトが返されます。

過去に、close メソッドや finalize メソッドでガベージコレクタを明示的に呼び出していた状況は、巨大なパフォーマンスブラックホールの原因となりました。 ガベージコレクションは高くつきます。何百、何千ものガベージコレクションを強制する状況は、システムの停滞をもたらすでしょう。

-128から127までの値は対応するキャッシュされたインスタンスを持つことが保証されています。 そして、valueOf メソッドの使用は、コンストラクタを使用するより約3.5倍高速です。 定数範囲外の値は、両方のスタイルの性能は同じです。

クラスが J2SE 5.0より前の Java 仮想マシンとの互換性が不要なら、Long、Integer、Short、Character、Byte のインスタンスを作成するときは、オートボクシングか valueOf メソッドを使用してください。

クラスが J2SE 5.0より前の Java 仮想マシンとの互換性が不要なら、オートボクシングか Double、Float の valueOf メソッドを使用してください。

• String.toUpperCase(Locale l)
• String.toLowerCase(Locale l)

nextInt メソッドへの引数は整数でなければなりません。 たとえば、-99から0までの乱数を生成したいなら、-r.nextInt(100) を使用してください。

この問題を直すために、最初にローカル変数をオブジェクトに格納して、完全に構築した後で volatile フィールドを保存することを考えてください。

参照によってつながった複数のオブジェクトがファイナライズ可能になると、Java 仮想マシンはすべてのオブジェクトの finalize メソッドを呼び出します。 おそらく異なるスレッドで同時にです。 したがって、クラス X の finalize メソッドの中から X によって参照されているオブジェクトの finalize メソッドを呼び出すのは、とりわけ間違った考えです。 なぜなら、オブジェクトが既に別のスレッドによってファイナライズされているかもしれないからです。

public boolean equals(Object o) {
    if (o instanceof Foo)
        return name.equals(((Foo)o).name);
    else if (o instanceof String)
        return name.equals(o);
    else return false;
}

これは対称的で推移的である equals メソッドを実現するのはとても難しいので、バッドプラクティスと見なされています。 プロパティがなければまったく予想していない振る舞いが起こりえます。

おそらく意図されたことは、オブジェクトはそれ自身と等価であるというオブジェクト同一性です。 これは Object クラスから継承される振る舞いです。 異なるスーパークラスから継承される equals メソッドをオーバーライドする必要があるなら以下のようなコードが使えます。

public boolean equals(Object o) {
    return this == o;
}

JDK はこのバグを解決してサイズを1MB減らすことができました。
詳細は、JDK bug 6447475 を参照してください。

このクラスのインスタンスが HashMap/HashTable に決して代入されるだろうと思わないなら推奨される hashCode メソッドの実装は以下のようになります。

public int hashCode() {
    assert false : "hashCodeが呼び出されることは想定されていません。";
    return 42; // 適当な値 
}

Comparable インタフェースの compareTo メソッドの JavaDoc を以下に引用します。

必須というわけではありませんが、(x.compareTo(y)==0) == (x.equals(y)) であることが強く推奨されます。 一般的にComparable インタフェースを実装しているクラスで、この条件に違反するクラスは明確にこの事実を示す必要があります。 「注:このクラスは equals と一貫性のない自然順序付けを持ちます」などと明示することをお勧めします。

このクラスのインスタンスが HashMap/HashTable に決して代入されるだろうと思わないなら推奨される hashCode メソッドの実装は以下のようになります。

public int hashCode() {
    assert false : "hashCodeが呼び出されることは想定されていません。";
    return 42; // 適当な値 
}

hashCode メソッドを定義したくないまたはオブジェクトが HashMap/Hashtable に決して格納されないだろうと思っているなら UnsupportedOperationException をスローする hashCode() メソッドを定義してください。

• クラスは、ロックされたアクセスとアンロックされたアクセスが混在していて
• クラスは、javax.annotation.concurrent.NotThreadSafe としてアノテートされません
• 少なくとも1つのロックされたアクセスがクラス自身のメソッドの1つによって実行され、
• 読み出しの2倍の重み付けをした書き込みで、非同期フィールドのアクセス (読み出しと書き込み) 数がすべてのアクセスのわずか1/3

このバグパターンに合致する典型的なバグは、スレッドセーフを意図したクラスでメソッドを同期化させることを忘れていることです。

ディテクタがどこでフィールドが同期化なしでアクセスされると信じていたかを示すコードの場所に「非同期アクセス」というラベルがついているノードを選択できます。

不正確ないろいろな原因がこのディテクタにあることに注意してください。 たとえば、ディテクタはロックを保持されるすべての状況を静的に検出できるわけではありません。 また、ディテクタがロックされたアクセスとアンロックされたアクセスの区別が正確なときでも、問題のコードは依然として正しいかもしれません。

可変オブジェクトの状態変更が通知があるメソッドを呼び出したメソッドで起こったかもしれないので、このバグが必ずしもエラーを示すというわけではありません。

詳細については、the Java Language Specification を参照してください。

詳細については、the Java Language Specification を参照してください。

これはたくさんの具象クラスを作るためです。以下のクラスを検討してください。

abstract class A {
    int hashCode;
    abstract Object getValue();
    
    A() {
        hashCode = getValue().hashCode();
    }
}

class B extends A {
    Object value;

    B(Object v) {
        this.value = v;
    }

    Object getValue() {
        return value;
    }
}

B が構築されるとき、B のコンストラクタが value に値を設定する前に、A クラスのコンストラクタが呼び出されます。 したがって、A のコンストラクタが getValue を呼び出すとき、value の初期化されていない値が読み出されます。

public class CircularClassInitialization {
    static class InnerClassSingleton extends CircularClassInitialization {
        static InnerClassSingleton singleton = new InnerClassSingleton();
    }
    
    static CircularClassInitialization foo = InnerClassSingleton.singleton;
}

private static String LOCK = "LOCK";

synchronized(LOCK) {
    ...
}

文字列定数は正準化され、Java 仮想マシンによってロードされたすべてのクラス全体で共有されます。 したがって、これは他のコードがロックしているかもしれない何かをロックしている可能性があります。 これはブロッキングとデッドロックの振る舞いの診断を難しくして、とても奇妙な結果になる可能性があります。
詳細は、http://www.javalobby.org/java/forums/t96352.html と http://jira.codehaus.org/browse/JETTY-352 を参照してください。

private static Boolean inited = Boolean.FALSE;

synchronized(inited) { 
    if (!inited) {
        init();
        inited = Boolean.TRUE;
    }
}

一般には2つの Boolean オブジェクトだけが存在しています。 このコードは他の無関係なコードと同じオブジェクトで同期化している可能性があるので、無応答やデッドロックの原因になります。

private static final Integer fileLock = new Integer(1);

synchronized(fileLock) { 
    .. do something ..
}

このコードは fileLock を以下のように宣言するとより良くなります。

private static final Object fileLock = new Object();

既存のコードとしては間違っていないかもしれないが、紛らわしいので将来リファクタリングするべきかもしれません。 たとえば、IntelliJ の "Remove Boxing" のようなリファクタリングは Java 仮想マシンを通して共有される正準化された Integer オブジェクトを使用するように置き換えてしまい、非常に紛らわしい振る舞いと潜在的デッドロックの原因になります。

private static Integer count = 0;

synchronized(count) { 
    count++;
}

Integer オブジェクトはキャッシュして共有できます。 他の無関係なコードと同じオブジェクトで同期化している可能性があるので、無応答やデッドロックの原因になります。

CERT の CON08-J. Do not synchronize on objects that may be reused を参照してください。

synchronized() {
}

空の synchronized ブロックは巧妙で正しく使用するのは困難です。 空の synchronized ブロックはわざとらしくて決して良い解決策ではありません。

• クラスにはロックされたアクセスとアンロックされたアクセスが混在していて
• 少なくとも1つのロックされたアクセスがクラス自身のメソッドの1つによって実行され、
• 読み出しの2倍の重み付けをした書き込みで、非同期フィールドのアクセス (読み出しと書き込み) 数がすべてのアクセスのわずか1/3

このバグパターンに合致する典型的なバグは、スレッドセーフを意図したクラスでメソッドを同期化するのを忘れていることです。

不正確のいろいろなソースがこのディテクタにあることに注意してください。 たとえば、ディテクタはロックを保持されるすべての状況を静的に検出できるわけではありません。 また、ディテクタがロックされたアクセスとアンロックされたアクセスの区別が正確なときでも、問題のコードはまだ正しいかもしれません。

private Long myNtfSeqNbrCounter = new Long(0);
private Long getNotificationSequenceNumber() {
     Long result = null;
     synchronized(myNtfSeqNbrCounter) {
         result = new Long(myNtfSeqNbrCounter.longValue() + 1);
         myNtfSeqNbrCounter = new Long(result.longValue());
     }
     return result;
}

本当に継承されたメソッドを呼び出すつもりなら super を付けて (例：super.foo(17)) 呼び出してください。 そうすれば、外部クラスのメソッドではなく継承されたメソッドを呼び出したいことがこのコードを読む人と FindBugs に明確になります。

this.foo(17) を呼び出す場合は、継承されたメソッドが呼び出されます。 しかしながら、FindBugs はクラスファイルを見るだけなので、this.foo(17) と foo(17) の呼び出しの違いを見分けることができません。 潜在的なあいまいな呼び出しについて文句を言うでしょう。

import alpha.Foo;

public class A {
    public int f(Foo x) { return 17; }
}
----
import beta.Foo;

public class B extends A {
    public int f(Foo x) { return 42; }
}

クラス B で定義された f(Foo) メソッドは、クラス A の f(Foo) メソッドをオーバーライドしていません。 これは引数の型 Foo が違うパッケージだからです。

import alpha.Foo;

public class A {
    public int f(Foo x) { return 17; }
}
----
import beta.Foo;

public class B extends A {
    public int f(Foo x) { return 42; }
    public int f(alpha.Foo x) { return 27; }
}

クラス B で定義された f(Foo) メソッドは、クラス A の f(Foo) メソッドをオーバーライドしません。 これは引数の型 Foo が違うパッケージだからです。

この場合、サブクラスがスーパークラスのメソッドと同一のシグネチャでメソッドを定義しているので、おそらく理解できます。 しかしながら、そのようなメソッドは非常に紛らわしいです。 類似しているが同一ではないシグネチャのメソッドを除去するか、非推奨にすることを強く検討するべきです。

解析は生成されたバイトコードを見るだけなので、default が switch 文の終わりにあって、他のケースに break 文が含まれていないなら誤検出のトリガーとなります。

できれば、内部クラスを static にして問題を解決するべきです。 外部クラスを直列化可能にすることで動作するかもしれないが、内部クラスのインスタンスを直列化することは外部クラスも常に直列化することを意味します。 本当に望むことですか。

我々はできる限り誤検出を減らそうと努力しているが、いくつかのケースでは警告は間違っているかもしれません。 よくある誤検出例です。

- メソッドは、副作用を持つかもしれないクラスのロードをトリガすることを意図している

- メソッドは、暗黙のわかりにくい例外をスローするように意図されている

この解析はめったに誤検出することはありません。よくある誤検出のケースです。

- 暗黙のうちに曖昧な例外をスローした

- コードを一般化してスタブとして使用された

- 弱/ソフト参照オブジェクトへの強い参照を持っていた

我々は、できる限り誤検出を減らそうとしていますが、いくつかのケースではこの警告が間違っているかもしれません。 よくある誤検出です。

- メソッドは、オーバライドされ解析対象外の他のプロジェクトで副作用がもたらされるように設計されている

- メソッドは、副作用をもたらすかもしれないクラスローダをトリガーするように呼び出されている

- メソッドは、例外を取得するために呼び出されている

我々の仮定が正しくないと感じるなら、FindBugs にこのメソッドの戻り値が無視されることを許容するように指示する @CheckReturnValue アノテーションを使用することができます。

我々は、戻り値を無視することがメソッド本体の単純な解析から悪い考えかもしれないと推測しています。 このメソッドの戻り値を無視することが重要であるか許容できるかどうかに関して、FindBugs に指示する @CheckReturnValue アノテーションが使えます。

戻り値を無視することが間違いではないか決めるために厳密に調査してください。

String dateString = getHeaderField(name);
dateString.trim();

プログラマは、trim メソッドが dateString によって参照される String オブジェクトが更新されると思っています。 しかし、String オブジェクトは不変で、trim メソッドが新しい String オブジェクトを返すのに無視しています。 このコードは以下のように修正するべきです。

String dateString = getHeaderField(name);
dateString = dateString.trim();

if (x < 0) {
    new IllegalArgumentException("x must be nonnegative");
}

おそらくプログラマの意図は、作成した例外をスローすることでした。

if (x < 0) {
    throw new IllegalArgumentException("x must be nonnegative");
}

switch 文の default が多くの場合実行不可能なので FindBugs が例外経路である default を検討することに注意して下さい。

switch 文の default が多くの場合実行不可能なので FindBugs が例外経路である default を検討することに注意して下さい。

なお、if (x == null) throw new NullPointerException(); は x の参照解除として扱われることに注意して下さい。

他方では、「この質問に対する答えがない」ことを示すために null を使用することはおそらく適切です。 たとえば、File.listFiles() は、ファイルがないディレクトリを与えられた場合は空のリストを返し、ファイルがディレクトリでないなら null を返します。

if (argv.length == 0) {
    // TODO: handle this case
}

if (argv.length == 1);
    System.out.println("Hello, " + argv[0]);

• Both values compared are definitely null
• One value is definitely null and the other is definitely not null

This particular warning generally indicates that a value known not to be null was checked against null. While the check is not necessary, it may simply be a case of defensive programming.

Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}

Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}

    int foo;
    public void setFoo(int foo) {
        foo = foo;
    }

そのような代入は役に立ちません。そうではなく、フィールドに代入するつもりでしたか？

public void foo() {
    int x = 3;
    x = x;
}

そのような代入は役に立たないので、論理エラーかタイプミスかもしれません。

int x;
public void foo() {
    x = x;
}

そのような代入は役に立たないので、論理エラーかタイプミスかもしれません。

int x,y;
public void foo() {
    x = x = 17;
}

フィールドに2回代入することは役に立たないので、論理エラーかタイプミスかもしれません。

public void foo() {
    int x,y;
    x = x = 17;
}

変数に同じ値を2回代入することは役に立たないので、論理エラーかタイプミスかもしれません。

生成された乱数が推測可能でないことが重要なら、乱数ごとに新しい Random オブジェクトを作成してはいけません (値はあまりに簡単に推測可能です)。 その代わりに java.security.SecureRandom の使用を強く検討するべきです (そして必要とされる乱数ごとに新しい SecureRandom のオブジェクトを作成することを回避します)。

文字列の2^32個に1個は Integer.MIN_VALUE のハッシュコードを持っていて、「polygenelubricants」、「GydZG_」、「DESIGNING WORKHOUSES」が該当します。

計算結果が負ではないことを確認したいなら、コードを変更する必要があるかもしれません。 除数が2の累乗であることがわかっているなら、代わりにビット演算を使用できます (すなわち、x.hashCode()%n の代わりに x.hashCode()&(n-1) を使用してください)。 これはおそらく、剰余を計算するより高速です。 除数が2の累乗であるということをわかっていないなら、剰余演算の結果の絶対値を取得してください (すなわち Math.abs(x.hashCode()%n))。

特に、バイト配列 int にパックする以下のようなコードはひどく間違っています。

int result = 0;
for(int i = 0; i < 4; i++) {
    result = ((result << 8) | b[i]);
}

その代わりに以下のようなイディオムは動作します。

int result = 0;
for(int i = 0; i < 4; i++) {
    result = ((result << 8) | (b[i] & 0xff));
}

特に、バイト配列 int にパックする以下のようなコードはひどく間違っています。

int result = 0;
for(int i = 0; i < 4; i++) 
  result = ((result << 8) + b[i]);

その代わりに以下のようなイディオムは動作します。

int result = 0;
for(int i = 0; i < 4; i++) 
  result = ((result << 8) + (b[i] & 0xff));

典型的に、このバグは、ビットセットで帰属関係のテストを実行したいコードで発生します。 しかし、ビット論理積演算子 ("&") の代わりにビット論理和演算子 ("|") を使用しています。

こうしたバグは (e & (A | B)) == C が意図されている間に ((e & A) | B) == C のように解析される (e & A | B) == C のような式で現れるかもしれません。

たとえメソッドが複数のスレッドによって決して呼び出されないと確信していても、 それは、フィールドに設定している値が完全にデータを読み込まれるか初期化されるまで、 static フィールドを設定しないほうが良いかもしれません。

そのようなコードは正しいかもしれないが、将来コードを維持しなければならない人々を混乱させるかもしれないので慎重にレビューし文書化するべきです、

StringBuffer (または J2SE 5.0の StringBuilder) を明示的に使うとより良い性能を得られます。

たとえば、

// This is bad
String s = "";
for (int i = 0; i < field.length; ++i) {
    s = s + field[i];
}

// This is better
StringBuffer buf = new StringBuffer();
for (int i = 0; i < field.length; ++i) {
    buf.append(field[i]);
}
String s = buf.toString();

public static junit.framework.Test suite()

か

public static junit.framework.TestSuite suite()

のどちらかを宣言する必要があります。

Sun の javac コンパイラが final なローカル変数のためにしばしば無効な格納を生成することに注意してください。 FindBugs は、バイトコードベースのツールなので誤検出をなくす簡単な方法がありません。

より多くの詳細と例と J2SE 5.0 のクラスの強制的な初期化の方法の提案は Sun の article on Java SE compatibility を参照してください。

より良いアプローチは、明示的にキャッチするよりもスローされる特定の例外をスローします。 あるいは、以下に示すように明示的に RuntimeException をキャッチ、再スローして、非実行時例外をキャッチします。

try {
    ...
} catch (RuntimeException e) {
    throw e;
} catch (Exception e) {
    ... deal with all non-runtime exceptions ...
}

long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; } 

long を使用して乗算をすれば、結果がオーバーフローするという可能性を回避できます。
たとえば以下のように修正できます。

long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; } 

または

static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; } 

Date getDate(int seconds) { return new Date(seconds * 1000); }

乗算は32ビット演算を使用して、64ビット値に変換されます。 32ビット値は、64ビットに変換されて、絶対時間値を表すために使用されるとき、1969年12月と1970年1月の日付しか表せません。

上記のメソッドの正しい実装は以下のとおりです。

// 失敗、2037年後の日付
Date getDate(int seconds) { return new Date(seconds * 1000L); }

// より良い、すべての日付で動作する
Date getDate(long seconds) { return new Date(seconds * 1000); }

int x = 2;
int y = 5;
// Wrong: yields result 0.0
double value1 =  x / y;

// Right: yields result 0.4
double value2 =  x / (double) y;

String[] getAsArray(Collection<String> c) {
  return (String[]) c.toArray();
}

これは通常 ClassCastException をスローして失敗します。 ほとんどすべてのコレクションの toArray メソッドは、Object[] を返します。 Collection オブジェクトは宣言された総称型コレクションの参照がないので、本当に何もできません。 コレクションから特定の型の配列を得る正しい方法は、c.toArray(new String[]); または c.toArray(new String[c.size()]); (後者はわずかにより効率的です) を使用することです。 これに対する1つの共通の知られている例外があります。 Arrays.asList(...)によって返されるリストの toArray() メソッドは共変型配列を返します。 たとえば、Arrays.asArray(new String[] { "a" }).toArray() は String [] を返します。 FindBugs はそのようなケースを検出して抑止しようとしますが、見落としているかもしれません。

• s.replaceAll(".", "/") は、すべての文字が '/' 文字に置換された String を返す
• s.split(".") は、常に長さが0の String 配列を返す
• "ab|cd".replaceAll("|", "/") は、"/a/b/|/c/d/" を返す
• "ab|cd".split("|") は、6個の要素がある配列を返す: [, a, b, |, c, d]

このバグは、二分探索とマージソートの多くの以前の実装で存在します。 Martin Buchholz が JDK ライブラリのバグを発見して修正しています。 Joshua Bloch が バグパターンとして公表しました。

• javax.xml.parsers.DocumentBuilderFactory
• javax.xml.parsers.SAXParserFactory
• javax.xml.transform.TransformerFactory
• org.w3c.dom.Document.createXXXX

まれに、非対称 equals メソッドを定義して、まだ、何とかそれらのコードを機能させています。 APIのどれも文書化していないか、保証もしていないが、Collection<String> に Foo があるかどうか調べたいなら、 引数の equals メソッド (たとえば、Fooクラスの equals メソッド) を使用して等価性をチェックします。

より正確に、when=ALWAYS を指定した型修飾子でアノテートされた値が同じ型修飾子で when=NEVER を指定する値と比較しています。

たとえば、@NonNegative は型修飾子アノテーション @Negative(when=When.NEVER) の略称とします。 以下のコードは、return 文が @NonNegative 値を要求するが、@Negative としてマークされている値を受け取るのでこの警告を生成します。

public boolean example(@Negative Integer value1, @NonNegative Integer value2) {
    return value1.equals(value2);
}

より正確に、when=ALWAYS を指定した型修飾子でアノテートされた値が到達することが保証されているか同じ型修飾子で when=NEVER を指定する場所で使用しています。

たとえば、@NonNegative は型修飾子アノテーション @Negative(when=When.NEVER) の略称とします。 以下のコードは、return 文が ＠NonNegative 値を要求するが ＠Negative としてマークされている値を受け取るのでこの警告を生成します。

public @NonNegative Integer example(@Negative Integer value) {
    return value;
}

厳密なアノテーションを指定しているので値を型変換します。戻り値が厳密なアノテーションでアノテートされる同一性機能を定義してください。 これは厳密な型修飾子アノテーションで非アノテート値を値に変える唯一の方法です。

より正確に、when=NEVER を指定した型修飾子でアノテートされた値が同じ型修飾子で when=ALWAYS を指定する場所で使用しています。

追加モードでファイルを開き、オブジェクト出力ストリームで書き込むことができる唯一の状況は、 ファイルを読み出すときにランダムアクセスモードで開き、追加を開始するところまでバイトオフセットをシークすると計画した場合です。

private static final String base = "label";
private static int nameCounter = 0;

String constructComponentName() {
    synchronized (getClass()) {
        return base + nameCounter++;
    }
}

Label のサブクラスは同じサブクラスで同期化しません。データレースを生じさせます。 代わりに、このコードは Label.class で同期化するべきです。

private static final String base = "label";
private static int nameCounter = 0;

String constructComponentName() {
    synchronized (Label.class) {
        return base + nameCounter++;
    }
}

Jason Mehrens によって寄贈されたバグパターン

一般的にメソッドがストリープや他のリソースを開いたなら、メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために try/finally ブロックを使用するべきです。

このバグパターンは、OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして、うまくいけばより良い) 静的解析技術に基づいています。 私たちは、このバグパターンの有効性についてのフィードバックを得ることに関心があります。 どちらかの方法でフィードバックを送ってください。

• send email to findbugs@cs.umd.edu
• file a bug report: http://findbugs.sourceforge.net/reportingBugs.html

特に、このバグパターンの誤検出抑制探索法は詳細にわたって調整されていないので、誤検出についてのレポートは我々の助けになります。

解析技術の説明は、Weimer と Necula による Finding and Preventing Run-Time Error Handling Mistakes を参照してください。

一般的にメソッドがストリープや他のリソースを開いたなら、メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために try/finally ブロックを使用するべきです。

このバグパターンは、OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして、うまくいけばより良い) 静的解析技術に基づいています。 私たちは、このバグパターンの有効性についてのフィードバックを得ることに関心があります。 どちらかの方法でフィードバックを送ってください。

• send email to findbugs@cs.umd.edu
• file a bug report: http://findbugs.sourceforge.net/reportingBugs.html

特に、このバグパターンの誤検出抑制探索法は詳細にわたって調整されていないので、誤検出についてのレポートは我々の助けになります。

解析技術の説明は、Weimer と Necula による Finding and Preventing Run-Time Error Handling Mistakes を参照してください。

public static void initLogging() throws Exception {
    Logger logger = Logger.getLogger("edu.umd.cs");
    logger.addHandler(new FileHandler()); // ロガーの構成の変更
    logger.setUseParentHandlers(false); // 別のロガーの構成の変更
}

ロガーの参照は、メソッドの終わり (メソッドは脱出しません) で失われるので、 initLogging の呼び出しの後でガベージコレクションの循環があるなら、ロガー構成は失われます (なぜなら Logger は弱参照を保持するだけなので)。

public static void main(String[] args) throws Exception {
    initLogging(); // ファイルハンドラーをロガーに追加する
    System.gc(); // ロガーの構成が失われる
    Logger.getLogger("edu.umd.cs").info("Some message"); // 期待したようにファイルに記録されません
}

Ulf Ochsenfahrt と Eric Fellheimer