Sun Java System Application Server Enterprise Edition 8.2 アップグレードと移行

第 5 章 J2EE 1.4 の互換性の問題

次にこの章の内容を示します。

バイナリ互換性

Application Server 8.2 に含まれる Java SDK は J2EE Version 1.4 SDK です。このバージョンの J2EE SDK は J2EE SDK, v1.3 と互換性があります。

ソース互換性

ソースの下位互換性は保たれていません。ソースファイルで新しい J2EE API が使用されている場合、これらは以前のバージョンの J2EE プラットフォームでは使用できません。

一般的なポリシーは次のようになります。

保守リリースでは新しい API は導入されないので、相互間のソース互換性は維持されます。ただし、J2EE は J2SE に基づいているので、新しい Application Server のリリースには新しいバージョンの J2SE が含まれている可能性があります。詳細については、次に示す J2SE のマニュアルの互換性の問題に関する説明を参照してください。

http://java.sun.com/j2se/1.4.2/compatibility.html
機能リリースとメジャーリリースはソースの上位互換性を持っていますが、ソースの下位互換性は持っていません。

非推奨 API は下位互換性のみをサポートするメソッドやクラスであり、このような API を使用していると、-nowarn コマンド行オプションを指定していない限り、コンパイラは警告メッセージを生成します。非推奨メソッドやクラスを使用しないようにプログラムを変更することが推奨されますが、現在のところ、このようなメソッドやクラスを完全に削除する計画はありません。

J2EE 1.4 プラットフォーム (J2EE 1.3 リリース以降) との非互換性

Sun Java System Application Server 8.2 リリースは Java 2 Platform, Enterprise Edition, version 1.4 に基づいています。Sun Java System Application Server 7 リリースは Java 2 Platform, Enterprise Edition, version 1.3 に基づいています。

ほとんどの既存のプログラムは、何も変更しなくても Sun Java System Application Server 8.2 リリースで実行できるはずです。しかし、まれな状況や「コーナーケース」で発生するいくつかのマイナーな潜在的な非互換性も存在しているためその状況に対処できるように補足としてここで説明します。

Java Servlet 仕様 Version 2.4 は Sun Java System Application Server 8.2 リリースに付属しており、次の URL からダウンロードできます。

http://java.sun.com/products/servlet/

Version 2.3 の仕様は J2EE 1.3 SDK に付属していました。次の各項目は、これらのリリース間の互換性の問題について説明しています。
- HttpSessionListenersessionDestroyedメソッドは、これまではセッションが無効化されたことを通知するために使用されていました。今回のリリースでは、このメソッドはセッションが無効化されようとしていることを通知するために使用されるようになったので、セッションの無効化の前に通知を行います。以前の動作を前提としてコードが作成されている場合は、新しい動作に合うように変更する必要があります。
- ServletRequest,getRemotePort,getLocalName,getLocalAddr,getLocalPort
  
  今回のバージョンの仕様では、ServletRequest インタフェースに次のメソッドが追加されています。この追加によって、開発者が ServletRequest インタフェースを実装した場合などに、ソース互換性が失われる場合があるので注意が必要です。このような場合は、次の新しいメソッドがすべて実装されていることを確認します。
  - public int getRemotePort()は、クライアントのインターネットプロトコル (IP) のソースポートまたは最後に要求を送信したプロキシを返します。
  - public java.lang.String getLocalName() は、要求を受信した IP インタフェースのホスト名を返します。
  - public java.lang.String getLocalAddr() は、要求を受信したインタフェースの IP アドレスを返します。
  - public int getLocalPort() は、要求を受信したインタフェースの IP ポート番号を返します。
  Java Server Pages (JSP) 仕様 2.0 は Sun Java System Application Server 8.2 リリースに付属しており、次の URL からダウンロードできます。
  
  http://java.sun.com/products/jsp/
  
  JSP 仕様 1.2 は J2EE 1.3 SDK に付属していました。JSP 2.0 仕様は、可能な限り JSP 1.2 仕様との完全な下位互換を保つように配慮されています。JSP 1.2 仕様には一部あいまいな部分がありましたが、これらは JSP 2.0 仕様で明確化されています。いくつかの JSP 1.2 コンテナは異なる動作を行うため、コンテナ固有の動作に依存するアプリケーションについては、JSP 2.0 環境で正しく動作するように調整しなければならない場合があります。
  
  JSP に関連する既知の下位互換性の問題を次に示します。
- 名前空間を認識せず、プレフィックスパラメータのみに依存するタグライブラリのバリデータは、いくつかの JSP 2.0 ページの妥当性を正しく検査できない可能性があります。これは、XML ビューでは jsp:root 以外の要素にタグライブラリ宣言が格納されていることがあり、同じタグライブラリ宣言が異なるプレフィックスを使用して何度も格納される可能性があるからです。これらの代わりに、タグライブラリのバリデータでは常に uri パラメータを使用するようにしてください。既存のタグライブラリを含む既存の JSP ページでは何も問題は発生しません。
- いくつかのコンテナで、I18N の動作が異なっていることがあります。これは主に JSP 1.2 仕様のあいまいさが原因です。可能な限り、下位互換性への影響を最小限に抑えるための手段が講じられた結果、全体的に I18N のテクノロジ機能は大幅に改善されました。
  
  JSP 2.0 より前の JSP 仕様のバージョンでは、XML 構文の JSP ページと標準構文の JSP ページは、同じ方法でページエンコーディングを決定していました。つまり、それぞれのページ指令の pageEncoding または contentType 属性を調べることによってページエンコーディングを決定しており、どちらの属性も存在しない場合は、デフォルトで ISO-8859-1 が設定されていました。
  
  JSP 仕様 v2.0 からは、JSP ドキュメントのページエンコーディングは、XML 仕様のセクション 4.3.3 および付録 F.1 の説明のとおりに決定されており、これらのページの pageEncoding 属性は、XML 仕様のとおりに決定されたページエンコーディングとの整合性を確認するだけのためにチェックされます。
  
  この変更の結果、pageEncoding 属性から決定されるページエンコーディングに依存する JSP ドキュメントは、正しくデコードされなくなりました。したがって、これらの JSP ドキュメントには適切な XML エンコーディング宣言を追加する必要があります。
  
  また、JSP 1.2 仕様のページエンコーディングは変換ユニットごとに決定されますが、JSP 2.0 仕様のページエンコーディングは、ファイルごとに決定されます。したがって、.jsp に b.jsp が静的に含まれており、ページエンコーディングは b.jsp ではなく a.jsp で指定されている場合、JSP 1.2 仕様では、b.jsp に対して a.jsp のエンコーディングが使用されますが、JSP 2.0 仕様では b.jsp に対してデフォルトのエンコーディングが使用されます。
- 型強制規則 (JSP 2.0 仕様の表 JSP.1-11 参照) は、EL 強制規則との整合性がとられました。このため、いくつかの例外条件について、JSP 2.0 仕様では例外が発生しなくなりました。特に、空の文字列を数値タイプの属性に渡した場合、これまでは変換エラーか NumberFormatException が発生していましたが、JSP 2.0 仕様では、代わりに 0 が渡されるようになりました。詳細については、JSP 2.0 仕様の表 JSP.1-11 を参照してください。通常、この調整により問題が発生することはありません。なぜなら、これらは JSP 1.2 仕様の例外条件であり、この仕様ではこれらの例外が変換時または要求時に発生することが許容されていたからです。
- JSP コンテナは web.xml を使用して、さまざまなコンテナ機能のデフォルト動作を決定します。次の項目は、JSP 開発者が web.xml ファイルをサーブレットバージョン 2.3 仕様からサーブレットバージョン 2.4 仕様にアップグレードするときに注意すべき点を示したものです。
  - EL 式は、JSP 1.2 テクノロジによって作成されたアプリケーションでは、デフォルトで無視されます。Web アプリケーションを JSP 2.0 仕様にアップグレードする場合、EL 式はデフォルトで解釈されます。エスケープシーケンス \\$ を使用して、コンテナによって解釈されるべきではない EL 式をエスケープすることができます。あるいは、isELIgnored ページ指令や、el-ignored 設定要素によって、変換ユニット全体に対して EL を無効化することもできます。JSTL 1.0 のユーザーは、taglib/ インポートを JSTL 1.1 URI にアップグレードするか、_rt バージョンのタグを使用する必要があります (たとえば、c の代わりに c_rt 、fmt の代わりに fmt_rt を使用)。
  - 拡張子が .jspx のファイルは、デフォルトで JSP ドキュメントとして解釈されます。JSP 設定要素 is-xml を使用して、.jspx ファイルを正規の JSP ページとして処理します。JSP コンテナから.jspx の関連付けを解除する方法はありません。
  - エスケープシーケンス \\$ は、JSP 1.2 仕様では予約されていませんでした。JSP 1.2 仕様では、\\$ という表示のテンプレート文字や属性値を使用すると \\$ と出力されていましたが、現在では $ のみが出力されます。

JAXP と SAX の非互換性

Sun Java System Application Server 8.2 は JAXP 1.3 をサポートしています。つまり SAX 2.0.2 をサポートしていることになります。SAX 2.0.2 では、DeclHandler.externalEntityDecl が、DTDHandler.unparsedEntityDecl との整合性を保つために、絶対的なシステム識別子を返すようパーサーに要求します。このことによって、SAX 2.0.0 を使用するアプリケーションを移行するときに、いくつかの非互換性が発生します。

これまでの externalEntityDecl の動作を変更せずに、SAX 2.0.0 を使用するアプリケーションを SAX 2.0.2 に移行するには、resolve-dtd-uris 機能を false に設定します。次に例を示します。

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://xml.org/sax/features/resolve-dtd-uris",false);

SAX 2.0.0 と SAX 2.0.2 との間のその他の非互換性については、『JAXP Compatibility Guide』を参照してください。

`pass-by-reference` 要素

Sun Java System Application Server 8.2 は、デフォルトで Java 2 Platform, Enterprise Edition 仕様と互換性があります。この場合、移植性のあるすべての J2EE プログラムは、変更なしで Application Server 上で実行できます。ただし、J2EE の互換性要件で許可されている内容に従って、J2EE 仕様と互換性がない Sun Java System Application Server 8.2 の機能を使用するようにアプリケーションを設定することもできます。

sun-ejb-jar.xml ファイル内の pass-by-reference 要素は、リモート呼び出しのみに適用されます。EJB 2.0 仕様、セクション 5.4 で定義されているように、ローカルインタフェースへの呼び出しは pass-by-reference (参照渡し) のセマンティクスを使用します。

pass-by-reference 要素のデフォルト値が false に設定されている場合、リモートインタフェースへの呼び出しのセマンティクスを渡すパラメータは、EJB 2.0 仕様、セクション 5.4 に準拠します。true に設定されている場合、この仕様とは逆に、リモート呼び出しでは pass-by-value (値渡し) のセマンティクスではなく pass-by-reference (参照渡し) のセマンティクスが必要になります。

移植性のあるプログラムでは、このような呼び出しのときにオブジェクトのコピーが作成されることは想定できないので、元のオブジェクトを変更しても安全です。コピーが作成されないことも想定できないので、オブジェクトへの変更は、呼び出し元と呼び出し先の両方に表示されます。このフラグが true に設定されている場合、パラメータと戻り値は読み取り専用であると見なされます。このようなパラメータや戻り値を変更するプログラムの動作は定義されていません。pass-by-reference 要素の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide 』を参照してください。

`delegate` 属性

sun-web.xml ファイルの class-loader 要素にある delegate 属性のデフォルト値が true に設定されている場合、コンテナ全体のライブラリ JAR ファイルにあるクラスとリソースの方が、WAR ファイル内にパッケージされたクラスやリソースよりも優先して読み込まれます。これは、サーブレット 2.3 仕様、セクション 9.7.2 で推奨されている内容と相反しています。false に設定されている場合、クラスローダーの委任動作は、サーブレット 2.3 仕様、セクション 9.7.2 で推奨されている内容に準拠しています。

delegate 属性の値を true にして使用している移植性のあるプログラムを、J2EE 仕様の一部であるクラスやインタフェースと一緒にパッケージしないでください。このようなクラスまたはインタフェースが WAR ファイルに含まれているプログラムの動作は定義されていません。class-loader 要素の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide 』を参照してください。