notify() のコールで、起動されるスレッドを指定する方法はありません。

例 1: 次のコードでは、notifyJob() が notify() をコールします。

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

この場合、開発者はwait()をコールするスレッドを起動しようとしていますが、notify()が意図しているスレッドとは別のスレッドを通知する可能性があります。

ほとんどの場合、Thread オブジェクトの run() メソッドの直接コールはバグです。プログラマは制御の新規スレッドを開始しようとして、誤って start() の代わりに run() をコールしたため、run() メソッドがコーラーの支配下のスレッドで実行されます。

例 1: 次の Java プログラムからの抜粋は、start() の代わりに誤って run() をコールしています。

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

ほとんどの場合、Thread オブジェクトの stop() メソッドの直接コールはバグです。プログラマーはスレッドの実行を中止しようとするかもしれませんが、スレッドの停止は適切な方法ではありません。Thread の stop() 関数は ThreadDeath 例外を Thread オブジェクトのどこかで引き起こす可能性があり、オブジェクトは不整合な状態になり、漏えいの可能性のあるリソースになります。API は本質的に安全ではないため、かなり前に廃止されています。

例 1: 次の例は、誤って Thread.stop() をコールしている Java プログラムです。

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

clone() と名付けられたメソッドを実装するため、プログラマはこのクラスで Cloneable インターフェイスの実装を意図したようです。しかし、クラスは Cloneable インターフェイスを実装せず、clone() メソッドは正しく動作しません。

例 1: このクラスに clone() をコールすると、結果として CloneNotSupportedException. になります。

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

ICloneable インターフェイスでは、ディープコピーが保証されず、このインターフェイスを実装するクラスはクローンが作成されるときに予想される通りに動作しない可能性があります。ICloneable を実装し、シャローコピー (別のオブジェクトへの既存の参照を含む、オブジェクトのみをコピーする方法) のみを行うクラスでは、予期せぬ動作が発生する可能性があります。ディープコピー (オブジェクトとすべての参照オブジェクトをコピーする方法) が一般にクローンメソッドの動作として仮定されているため、ICloneable インターフェイスを使用するとエラーが発生しやすくなります。このインターフェイスの使用は避ける必要があります。

clone() 関数がオーバーライド関数をコールする場合、クローンが部分的に初期化された状態で、あるいは壊れた状態で残ることがあります。

例 1: 次の clone() 関数は、オーバーライドされる可能性のあるメソッドをコールしています。

  ...
  class User implements Cloneable {
    private String username;
    private boolean valid;
    public Object clone() throws CloneNotSupportedException {
      final User clone = (User) super.clone();
      clone.doSomething();
      return clone;
    }
    public void doSomething(){
      ...
    }
  }

関数 doSomething() と括弧で囲まれたクラスは final ではないため、関数がオーバーライドされる可能性があります。その結果、クローン オブジェクト clone が部分的に初期化された状態で残され、ロジックを対処しなかった場合、予期しない方法でエラーが起こる可能性があります。

ボクシングされたプリミティブ型が等価かどうかを比較する場合、演算子 == や != ではなくボクシングされたプリミティブ型の equals() メソッドをコールするべきです。Java 仕様は、ボクシング変換について次のように記述しています。

"ボクシング変換の対象となる値 p が -128 から 127 までの数値であるint 型の整数リテラル、true または false のブール リテラル、「\u0000」から「\u007f」までの文字リテラルである場合、p に対する任意の 2 つのボクシング変換結果を a と b とする。この場合、常に a == b が成立する。"

これは、ボクシングされたプリミティブ型が使用される場合 (Boolean または Byte 以外)、特定の範囲の値のみがキャッシュまたはメモリに保存されることを意味します。値のサブセットでは、== または != を使用して正しい値を返します。このサブセットに含まれないすべての値では、オブジェクト アドレスを比較した結果を返します。

例 1: 次の例では、ボクシングされたプリミティブ型で等価演算子を使用しています。

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

Example 1 のコードでは、Integer のボクシングされたプリミティブ型を使用して、2 つの int 値を比較しようとしています。mask0 と mask1 が両方とも 100 と等しい場合は、mask0 == mask1 は true を返します。しかし、mask0 と mask1 が両方とも 777 に等しい場合は、これらの値がボクシングされたプリミティブ型のキャッシュされた値の範囲内にないため、mask0 == maske1 は false を返します。