OSで共通の注意事項について説明します。

• java.math.BigDecimalクラスの値表示の差異について
  JDK 5.0およびJDK 6では，toString()メソッドによる文字列変換で指数表記が使用されるようになったため，値の出力形式が異なります。
  　
  （例）1E-15の値をtoString()メソッドで出力する
  
  • JDK 1.4.2以前の場合：0.000000000000001
  • JDK 5.0およびJDK 6の場合：1E-15
  なお，JDK 1.4.2以前の形式で値を出力したい場合は，toPlainString()メソッドを使用してください。
  
• Unicodeのバージョンについて
  JDK 6では，文字処理がUnicode標準のバージョン4.0に基づくようになったため，文字コードを個々に参照して解析する場合は注意が必要です。
  詳細は，該当ページ（http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html）の「Supporting Supplementary Characters in Your Application」を参照してください。
  
• javaソースプログラムの注釈の扱いについて
  JDK 6では，ソースプログラムの注釈中の文字について，文字コードをチェックします。例えば，デフォルトエンコーディングがEUCの環境で，注釈にShift-JISコードを含むソースプログラムをコンパイルした場合には警告が出力されます。コンパイル時には適切なエンコーディングを-encodingオプションに指定してください。
  
• Javaプログラムのコンパイルについて
  J2SE 5.0でのJava言語仕様の拡張に伴い，javacコマンドのデフォルトで以前はコンパイルできていたJavaプログラムでも，J2SE 5.0のJava言語仕様に違反する構文について，注意または警告のメッセージが出力されたり，エラーになったりすることがあります。注意および警告のメッセージの場合，以前のバージョンで動作していたものはそのまま動作させて問題ありません。ただし，Javaコードとしては，修正が望ましいコードと考えられます。なお，javacコマンドで-sourceオプションを指定すると，javacコマンドが受け付けるソースコード バージョン1.4を指定してコンパイルできます。これによって，注意および警告のメッセージを抑止できます。
  
• Javaプログラムのコンパイル時に発生する注意および警告のメッセージについて
  J2SE 5.0でのJava言語仕様の拡張に伴い，新しい言語仕様によるソース記述方法を推奨するため，次のような注意メッセージがコンパイル終了時に出力されることがあります。
  
  • 注: AccountEJB.java の操作は，未チェックまたは安全ではありません。
  • 注: 詳細については，-Xlint:uncheckedオプションを指定して再コンパイルしてください。
  また，-Xlintオプション指定時には，次のような警告メッセージが該当個所ごとに出力されます。
  
  • 警告: [unchecked] raw 型 java.util.List のメンバとしての add(E) への無検査呼び出しです。
  これらの警告および注意のメッセージは，コンパイル時にチェックができないことを示すものです。実際にエラーがあった場合には，JDK 1.4でも実行時に例外が発生します。したがって，移行前に稼働実績があるプログラムであれば，特に対処する必要はありません。
  
• JDK 1.4からJDK 5.0への変更での言語仕様に関する主な非互換項目について
  J2SE 5.0でのJava言語仕様の拡張で，Java言語に型保証された列挙型が追加されました。このため，enumはキーワードとなり，識別子として使用できません。
  
• java.net.Proxyクラスの追加による影響について
  JDK 5.0では，既存のjava.lang.reflect.Proxyクラスに加えて，java.net.Proxyクラスが追加されました。そのため，記述例1のようにimport宣言をしたクラスでProxyと記述した場合，どちらのパッケージのProxyクラスかがあいまいであるため，コンパイルエラーとなります。
  

  記述例1

  import java.lang.reflect.*;

  import java.net.*;

  この場合，記述例2のようにimport宣言を変更すると，java.lang.reflectパッケージのProxyクラスと明記されているので，コンパイルエラーを回避できます。
  

  記述例2

  import java.lang.reflect.*;

  import java.net.*;

  import java.lang.reflect.Proxy;

• クラス初期化のタイミング変更について
  JDK 5.0より前では，クラスリテラル（Foo.classなど）を参照すると，クラスが初期化されていました。しかし，JDK 5.0以降では初期化されません。クラスリテラルの参照時にクラスを初期化しようとしている場合には，初期化コードを追加する必要があります。記述例を次に示します。
  

  初期化コードの追加前の記述例

  Class cl = Foo.class;

  初期化コードの追加後の記述例

  Class cl = forceInit(Foo.class);

  public static <T> Class<T> forceInit(Class<T> klass) {

  try {

  Class.forName(klass.getName(), true, klass.getClassLoader());

  } catch (ClassNotFoundException e) {

  throw new AssertionError(e); // Can't happen

  }

  return klass;

  }

• java.lang.ClassLoaderクラスの変更点について
  Stringクラス名を引数とするClassLoaderメソッドのクラス名には，API仕様上，ピリオド（.）で区切られたバイナリ名を指定する必要があります。
  JDK 5.0より前では，スラッシュ（/）で区切られた名称（例えば，java/lang/Stringなど）でも問題なく動作しました。しかし，JDK 5.0以降では，バイナリ名でないクラス名を指定した場合には，java.lang.ClassNotFoundExceptionが発生します。ClassLoaderクラスのメソッドには，API仕様に従ってクラスのバイナリ名を指定してください。
  
• java.util.logging.Levelの変更点について
  JDK 5.0より前では，コンストラクタjava.util.logging.Level(String name, int value, String resourceBundleName)にnullのname引数を与えても例外は発生しません。しかし，JDK 5.0以降では，NullPointerExceptionが発生します。null引数を与えないようにしてください。
  
• java.sql.Timestamp.compareToの変更点について
  JDK 5.0では，java.sql.Timestamp.compareTo(java.util.Date)がAPIに追加されました。これは，JDK1.4.2のjava.util.Date.compareTo(java.util.Date)とは精度が異なり，ナノ秒までの精度を持っています。JDK 1.4.2ではこのAPIがないため，継承の関係からjava.util.Date.compareTo(java.util.Date)が呼ばれていましたが，JDK 5.0以降では，java.sql.Timestamp.compareTo(java.util.Date)が呼ばれます。
  次の条件をすべて満たす場合，JDK 1.4.2とJDK 5.0以降では比較結果が異なることがあります。
  
  • java.sql.Timestamp.compareTo(java.util.Date o)を呼び出す
  • java.sql.Timestampオブジェクトの持つ時刻と引数java.util.Dateオブジェクトの持つ時刻で，ナノ秒単位の差がある
  JDK 1.4.2と同じ精度でjava.sql.Timestampとjava.util.Dateの比較をするためには，java.util.DateのcompareTo(java.util.Date)メソッドを使用して，java.sql.Timestampを引数に渡す必要があります。
  
• 直列化バージョンUIDについて
  入れ子クラス内で包含クラス^※のメソッド呼び出し（例えば，<入れ子クラスを包含するクラス名>.this.メソッド名(引数);）をして，その包含クラスが直列化可能な場合，JDK 5.0以降では，包含クラスのデフォルトの直列化バージョンUIDの値が，JDK 5.0より前のバージョンと異なります。これは，JDK 5.0で実施されたjavacコマンドの変更によるものです。これらの条件をすべて満たす場合には，直列化可能クラスに直列化バージョンUIDを追加してください。
  　
  注※　包含クラスとは，入れ子クラスを包含するクラスのことです。
  

  （記述例）

  import java.io.*;

  class A implements Serializable { // 直列化可能な包含クラス

  void method1() {}

  class B { // 入れ子クラス

  void method2() { A.this.method1(); }

  }

  }

• メソッドキャンセル機能への影響について（Windows，AIXおよびLinuxの場合）
  Windows，AIXおよびLinuxの場合，アプリケーションサーバ 07-00以降では，アプリケーションサーバ 06-70と比較して，メソッドキャンセル機能が失敗しやすくなっています。
  これは，Component Container 06-70-/Gでの保護区の追加と，アプリケーションサーバ 07-00でのJDK 1.4.2からJDK 5.0へのバージョンアップによるものです。
  
  • Component Container 06-70-/Gでの保護区の追加
    Component Container 06-70-/Gでは，Javaクラスライブラリ内の複数クラスを保護区に追加しました。保護区に追加したJavaクラスライブラリ内のクラスでは，メソッドキャンセルが実行されると内部状態に不整合が生じます。
    Component Container 07-00以降は，Component Container 06-70-/G以降の保護区を引き継いでいるため，Component Container 06-70-/Gより前と比較して，保護区が多くなっています。保護区として定義されている内容については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「付録C　保護区リストの内容」を参照してください。
    
  • アプリケーションサーバ 07-00でのJDK 5.0へのバージョンアップ
    Javaの仕様やJDK実装上の制限によって，メソッドキャンセルできないことがあります。このような領域は，クラス単位ではない特殊な保護区としています。Javaの仕様やJDK実装上の制限によって，メソッドキャンセルできないことがある領域の扱いについて，Component Container 06-70と07-00以降の仕様差を次の表に示します。
    

    表15-1　メソッドキャンセルできないことがある領域の扱い

    Javaプログラムの実行処理	Component Container 06-70での扱い	Component Container 07-00以降での扱い
    synchronizedでロック確保待ち	メソッドキャンセルできる	メソッドキャンセルできない
    forやwhileループの終端	メソッドキャンセルできる	メソッドキャンセルできない
    オブジェクトの生成（newキーワード）	メソッドキャンセルできる
    上記以外のJavaプログラム実行中	メソッドキャンセルできない（ただし，インタプリタによる実行中はメソッドキャンセルできる）

    なお，Javaの仕様やJDK実装上の制限によってメソッドキャンセルできなかった場合は，KDJE52718-Wセージの詳細情報として，クラス名（JP.co.Hitachi.soft.jvm.CriticalClass.dummy(Native Method)）が表示されます。
    
• UDPソケット数の上限について
  セキュリティマネージャが有効な場合，JavaVMプロセス当たり26以上のUDPソケットを同時に使用することはできません。
  26以上のUDPソケットを作成しようとした場合は，java.net.SocketExceptionがスローされます。
  

HP-UXでの注意事項について説明します。

• スタックサイズ（-Xssオプション）の初期値について
  JDK 1.4.2では，Javaスレッドのスタックサイズの初期値は1メガバイトでしたが，JDK 6以降では，Javaスレッドのスタックサイズの初期値は4メガバイトとなっています。
  

Linuxでの注意事項について説明します。

• java.lang.ProcessクラスのwaitFor()およびexitValue()メソッドについて
  waitFor()およびexitValue()メソッドで取得できる子プロセスの終了コードが0以上255以下に変更されました。子プロセスが負の終了コードで終了した場合，その値は符号なし整数と見なされます。