FindBugs looks only for the most blatent, obvious cases of HTTP response splitting. If FindBugs found any, you almostly certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

FindBugs looks only for the most blatent, obvious cases of HTTP response splitting. If FindBugs found any, you almostly certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

FindBugs looks only for the most blatent, obvious cases of cross site scripting. If FindBugs found any, you almostly certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

FindBugs looks only for the most blatent, obvious cases of cross site scripting. If FindBugs found any, you almostly certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

FindBugs looks only for the most blatent, obvious cases of cross site scripting. If FindBugs found any, you almostly certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool, such as those provided by Fortify Software, a sponsor of the FindBugs project. If your software is open source, Fortify will scan your code for free as part of the JOR (Java Open Review) effort.

全てのclone()メソッドがsuper.clone()を呼び出すようになっていれば、Object.clone()が呼び出される事が保証され、正しい型のオブジェクトが返送されます。

元のStringをそのまま使用してください。

過去において、close()やfinalize()メソッドでのガベージコレクションを明示的に呼び出すことが、パフォーマンスのブラックホールに陥れるケースがありました。ガベージコレクションは高くつく場合があります。数百、数千のガベージコレクション呼び出しは、システムのパフォーマンスを極めて落とす事になります。

-128から127までの値は、キャッシュされるので、valueOfを使用すると約3.5倍高速になります。この範囲外の場合にはパフォーマンスの差はありません。

バージョン5.0より前のJava実行環境との互換性が不要であれば、オートボクシングか、Long、Integer、Short、Character、ByteのvalueOf()メソッドを代わりに使用してください。

バージョン5.0より前のJava実行環境との互換性が不要であれば、オートボクシングか、Double、FloatのvalueOf()メソッドを代わりに使用してください。

を使用してください。

もしも参照によってつながった複数のオブジェクトがファイナライズされると、それぞれのオブジェクトのfinalize()がVMから呼び出されますが、もしかすると別々のスレッドによって複数のfinalize()が同時に呼び出されるかもしれません。このため、あるクラスXのfinalize()の中から、別のオブジェクト(クラスXから参照されている)のfinalize()を呼び出すのは、とりわけ間違ったやり方です。なぜならすでにそのオブジェクトは別のスレッドでファイナライズ済みかもしれないからです。

The likely intended semantics are object identity: that an object is equal to itself. This is the behavior inherited from class Object. If you need to override an equals inherited from a different superclass, you can use use:

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

もしもこのクラスのインスタンスが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; // 適当な値
}

もしもhashCodelを定義する必要がない、あるいはこのオブジェクトをHashMap/Hashtableに格納したく ないと考えるのであれは、hashCode()メソッドをUnsupportedOperationExceptionを スローするように実装してください。

1. クラス内でアクセスする際に、ロックしたりしていなかったりしており、
2. 最低でも1つのロックされたアクセスがクラス内のメソッドから行われており、
3. 書き込みに対して、読み込みの2倍の重み付けをした場合に、ロックしていないフィールドアクセス(読み書き)の数が、全体のアクセス数の1/3を超えていない

このパターンに当てはまる典型的な例は、スレッドセーフを意図しているのに、メソッドを同期化するのを忘れているケースです。

ディテクタにコードの意図を伝えるため「非同期アクセス」のラベルを付ける事ができます。

このディテクタには、判断を誤る要因が幾つかあります。例えば、ディテクタはスレッドがロックを獲得しているかどうかを、コードを見て静的に判断する事は出来ません。例えディテクタが、ロックされたアクセスと、そうでないアクセスを的確に判定出来たとしても、依然としてコードが正しい可能性は残ります。

ここの記述は"IS2"バージョンのパターンディテクタを参考にしています。これは、ロック・非ロックアクセスの検出に関して"IS"バージョンよりも正確です。

このバグ報告は、必ずしもプログラミングエラーを意味しません。オブジェクトの状態変更がメソッド内部で行われ、そこから更にnotify()/notifyall()メソッドを持ったメソッドを呼び出しているかもしれないからです。

非短絡論理は、両側の式が評価されます。それはたとえ左側だけで結果が決定してしまう場合にもです。これは効率が悪く、左側がガード条件になっている場合には、右側の評価でエラーが発生するかもしれません。

詳細はJava言語仕様を参照してください。

詳細については、Java言語仕様を参照してください。

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) { ...}
...

Constant Strings are interned and shared across all other classes loaded by the JVM. Thus, this could is locking on something that other code might also be locking. This could result in very strange and hard to diagnose blocking and deadlock behavior. See http://www.javalobby.org/java/forums/t96352.html and http://jira.codehaus.org/browse/JETTY-352.

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

Since there normally exist only two Boolean objects, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock

private static final Integer fileLock = new Integer(1);
...
  synchronized(fileLock) { 
     .. do something ..
     }
...

It would be much better, in this code, to redeclare fileLock as

private static final Object fileLock = new Object();

private static Integer count = 0;
...
  synchronized(count) { 
     count++;
     }
...

Since Integer objects can be cached and shared, this code could be synchronizing on the same object as other, unrelated code, leading to unresponsiveness and possible deadlock

synchronized() {}

空のsynchronizedブロックは難解で、考えられている程利用は容易ではありません。また少々ぶかっこうなコードになっても大抵の場合、空のsynchronizedブロックを使用しない方が、より優れたコードになります。

1. クラス内でアクセスする際に、ロックしたりしていなかったりしており、
2. 最低でも1つのロックされたアクセスがクラス内のメソッドから行われており、
3. 書き込みに対して、読み込みの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;
 }

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; }
}

The f(Foo) method defined in class B doesn't override the f(Foo) method defined in class A, because the argument types are Foo's from different packages.

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; }
}

The f(Foo) method defined in class B doesn't override the f(Foo) method defined in class A, because the argument types are Foo's from different packages.

In this case, the subclass does define a method with a signature identical to the method in the superclass, so this is presumably understood. However, such methods are exceptionally confusing. You should strongly consider removing or deprecating the method with the similar but not identical signature.

可能であれば、インナークラスをstaticとしてください。outerクラスを直列化可能とすることでも問題を解決できますが、この場合インナークラスの直列化にあたってouterクラスも直列化されることに注意してください。おそらくこれはプログラマの意図とは異なるでしょう。 ]]>

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

このメソッドの戻り値をチェックするべきです。このようなコードを書いてしまった原因の1つとして、イミュータブルなオブジェクトのメソッド呼び出しが、そのオブジェクトの状態を変化させると誤解しているケースが考えられます。例えば、

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

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

It was probably the intent of the programmer to throw the created exception:

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

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

このプログラマは、trim()メソッドがdateStringが参照しているStringの状態を変えると考えているように思われます。しかしStringはイミュータブルであり、trim()メソッドは新しいStringオブジェクトを返すので、これでは戻されたオブジェクトが捨てられてしまいます。このコードは、以下のように修正すべきです。

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

また、FindBugsはswitch-caseのdefaultも例外経路と見なしますが、しばしばdefaultは実行され得ない場合がありますので、注意してください。

また、FindBugsはswitch-caseのdefaultも例外経路と見なしますが、しばしばdefaultは実行され得ない場合がありますので、注意してください。

これに対し「返すべき値が無い事を示す」のにnullを用いるのが、恐らく適切です。例えば、File.listFiles()は、ディレクトリにファイルが無い時はサイズ0の配列を、指定されたパスがディレクトリでなければnullを返します。

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

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

• 比較されている2つの値は明らかにnullです。
• 一方は明らかにnullであり、もう一方は明らかにnullではありません。

この警告は、一般には、明らかにnullでない値をnullとチェックすることにより報告されます。単純に、実際には、チェックは全く不要な、防御的プログラミングかもしれません。

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

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

  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を替わりに使用することについても真剣に検討すべきです(この場合も毎回インスタンスを生成してはいけません)。

計算結果が負にならないと思っているのであれば、コードを修正する必要があります。序数が2のn乗であることが明らかならば、かわりにビットANDを使用することができます(x.hashCode()%nの代わりにx.hashCode()&(n-1)を使用します)。これは恐らく剰余計算よりも高速です。それ以外のケースでは剰余に対して絶対値を算出してください(Math.abs(x.hashCode()%n)。

とりわけ、以下のようにバイト配列に格納された値をint変数に取り出すコードはひどく間違っています。

かわりに以下のようなイディオムを使用することで正しく動作するようになります。

((event.detail & SWT.SELECTED) > 0)

Boris Bokowski

((event.detail & SWT.SELECTED) > 0)

Boris Bokowski

このバグの典型的なパターンとして、ビットセットのテストのために、論理積("&")を使うべきところを、間違って論理和("|")を使用してしまったケースが考えられます。

明示的にStringBufferあるいはStringBuilder(J2SE 1.5から導入されます)を用いる事で、パフォーマンスを改善する事が出来ます。

例)

  // 悪い例
  String s = "";
  for (int i = 0; i < field.length; ++i) {
    s = s + field[i];
  }

  // 良い例
  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()

[Bill Pugh]: すみません、私はこの警告の出力には強く反対で、あなたのコードは全く正しいと思います。ユーザのコードはequals()の実装がどうなっているかを意識すべきではなく、==でのインスタンス比較に依存すべきではありません。このようにしてしまうと、ライブラリ側でオブジェクトの同値性を制御することができなくなってしまいます。

See Sun's article on Java SE compatibility for more details and examples, and suggestions on how to force class initialization in Java 5.