JAXP互換性ガイドJava SE 5プラットフォーム用

新機能
DOM Level 3
- DOMインタフェースに追加されたメソッド
- XML形式の保持
SAX 2.0.2
XSLTの呼び出し
- プログラミングによるXalan XPathへのアクセス
パッケージ名の変更
- 変更点と変更の理由
- システム・プロパティおよび実装クラスの使用
入れ子にされたエンティティ定義によるセキュリティの問題

はじめに

Java SE 1.4プラットフォームには、JAXP 1.1用の「Crimson」リファレンス実装が含まれていました。 Java SE 5プラットフォームには、Apache「Xerces」ライブラリに基づく、JAXP 1.3用のリファレンス実装が含まれています。

これらの実装はまったく異なるコード・ベースが基になっており、かつJAXP標準は1.1から1.3へと発展したため、どちらもJAXP標準に準拠していますが、これらの実装間にはわずかな差異があります。これら2つの要因が組み合わさるために、このガイドで説明する互換性の問題が発生しています。

新機能

1.4 用に作成されたXMLアプリケーションにはいくつかの非互換性の問題があるとはいえ、Java SE 5プラットフォームのJAXP 1.3にはそれを上回る利点があります。

組込みのXMLスキーマ検証プロセッサ。
ほかのスキーマ・バリデータを使用可能かつjavax.xml.validationパッケージとの併用可能。
javax.xml.datatypeにXMLスキーマ・データ型を完全に実装。これまでJavaプラットフォームに同等のものが存在しなかったグレゴリオ暦(太陽暦)の日時を含む。
高速なコンパイル・トランスフォーマであるXSLTC。XSLT処理のデフォルト・エンジン。
DOM Level 3コア。次の機能を備える
- XML 1.1およびNamespaces 1.1 (javax.xml.namespace)、タグ名および名前空間でのUnicode文字サポートが向上。
- ドキュメントの正規化のサポート
- スキーマ・データ型(TypeInfo)のサポート
- ErrorHandlingおよびエラー箇所特定の向上
- ブートストラップ。 DOM Level 3では、実装に依存しないDOMImplementation取得方法をサポート。
- DOM Level 3では、ノード内のアプリケーション・データを設定可能。また、ノードが複製、削除、または名前変更されたときに呼び出されるUserDataHandlerを設定可能。
javax.xml.xpathでのJava中心のXPath API。XPath式がJavaでさらに使いやすくなった。これは、そのインタフェースを実装するどのデータ・モデルにも適用できるように設計された。これを使用してリファレンス実装のDOMを処理できるようになった。将来は、JDomやSTAXデータ・モデルの処理時にも利用できるようになる予定。
XIncludeの実装。ほかの箇所で再利用可能なセグメントに格納されているテキストまたはXMLを使用するドキュメントをビルド可能になった。
文法の事前解析およびキャッシュ。大量のXML処理では、パフォーマンスに大きく影響する。
パーサーの実装およびバージョンを知るためのAPI。新しいライブラリのインストール時に、アプリケーションでそのライブラリが使用されているかを確認できるようになった。

以上が改善点です。しかし、いくつかの互換性の問題が残っています。本ドキュメントの残りの部分では、これらの問題について説明します。

DOM Level 3

Java SE 1.4のリファレンス実装ではDOM Level 2 APIをサポートしていますが、Java SE 5の実装ではDOM Level 3ファミリのAPIをサポートしています。このセクションでは、この変更に伴う、JAXP 1.1リファレンス実装を使用するプログラムへの影響を説明します。

DOMインタフェースに追加されたメソッド
XML形式の保持

詳細は、DOM Level 3の付録「Changes」にある変更点の完全な一覧を参照してください。

DOMインタフェースに追加されたメソッド

DOM Level 3では、次のインタフェースにメソッドが追加定義されました。

Attr
Document
DOMImplementation
Element
Entity
Node
Text

追加されたメソッドにより影響を受けるのは、インタフェースを直接実装しているアプリケーションだけで、それもそのようなアプリケーションを再コンパイルしたときだけです。アプリケーションでこれらのインタフェースの実装クラスを取得するためにファクトリ・メソッドを使用している場合は、問題ありません。

XML形式の保持

これらの変更の影響を受けるアプリケーションは、XMLデータをDOMに読み込んで変更し、元のデータ形式を保持しながら書き出すようなアプリケーションです。

JAXP 1.1では、余分な空白は入力時に自動的に削除されました。このとき、たとえばエンティティ・ノードやCDATAノードを保持するために、単一のプロパティ(ignoringLexicalInfo)がfalseに設定されていました。これらのノードを含めることで、DOMは処理がいくらか複雑になっていました。しかしこれらのノードが含まれているために空白出力(インデントや改行)が追加され、可読性が高く、書式化された、入力内容に非常に近いXMLデータを出力できました。

JAXP 1.3では、処理に利用できる字句(書式)情報の程度を判別するためにアプリケーションが使用するAPIが4つあり、それぞれ以下のDocumentBuilderFactoryメソッドを使用します。

setCoalescing() - CDATAノードをTextノードに変換し、隣接するTextノードがあれば、そのノードに追加する。
setExpandEntityReferences() - エンティティ参照ノードを展開する。
setIgnoringComments() - コメントを無視する。
setIgnoringElementContentWhitespace() - 空白が要素の内容に重要でない場合は、その空白を無視する。

これらのプロパティのデフォルト値はどれもfalseで、受け取ったドキュメントを元の形式に再構築するために必要な字句情報がすべて保持されます。これらのプロパティをすべてtrueに設定すると、もっとも単純なDOMが構築できるため、アプリケーションでは字句構文の詳細を考慮することなく、データのセマンティック・コンテンツに集中できます。

ノート:新しいノードを追加するときは、可読性を高めるために必要となるインデントや改行の書式は自動的に付加されないため、アプリケーションで付加する必要があります。

SAX 2.0.2

SAX 2.0.0とSAX 2.0.2の間で行われた変更で、互換性に影響を及ぼす可能性のあるものは次のとおりです。

DeclHandler.externalEntityDeclは、DTDHandler.unparsedEntityDeclとの一貫性を保つため、現在では絶対システム識別子を返すパーサーを必要とする。このため、非互換性が生じる可能性がある。
SAX 2.0.1では、アプリケーションはErrorHandler、EntityResolver、ContentHandler、またはDTDHandlerをnullに設定できる。このようにするとSAX 2.0ではNullPointerException (NPE)が発生していたが、この制約が緩くなった。

そのため、JAXP 1.3では、次のコードも有効
```
SAXParserFactory spf = SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();
XMLReader reader = sp.getXMLReader();
    
reader.setErrorHandler(null);
reader.setContentHandler(null);
reader.setEntityResolver(null);
reader.setDTDHandler(null);
```
EntityResolver APIのresolveEntity()メソッドで、IOExceptionとSAXExceptionをスローするようになった。これまではSAXExceptionだけがスローされていた。

問題が生じるような方法でDefaultHandlerを使用するアプリケーションはごく一部だけであり、また、DefaultHandler実装クラスが追加の例外を宣言するように変更されたため、ほとんどのアプリケーションはこの影響を受けない。

アプリケーションに影響があるのは、resolveEntity()メソッドをオーバーライドして、かつ super.resolveEntity()を呼び出す場合だけである。その場合、アプリケーションは、super.resolveEntity()がスローするIOExceptionを処理するようにメソッドを変更するまで、Java SE 5でコンパイルされない。
新機能は次のとおりです。
- http://xml.org/sax/features/external-general-entities - 外部の一般的なエンティティを含めることができる。
- http://xml.org/sax/features/external-parameter-entities - 外部のパラメータ・エンティティと、外部のDTDサブセットを含めることができる。
また、新しいプロパティは次のとおり
- http://xml.org/sax/properties/xml-string - 現在のイベントに関連する文字列を取得する。
Xercesの機能およびプロパティの完全な一覧は、http://xml.apache.org/xerces2-j/features.htmlおよびhttp://xml.apache.org/xerces2-j/properties.htmlを参照してください。

ノート:互換性についても説明すべき点が1つあります。 Java SE 1.4 (JAXP 1.1)では、名前空間の認識は、デフォルトでオフになっていました。下位互換性のため、この方針はJava SE 5 (JAXP 1.3)でも変わりません。ただし、https://sourceforge.net/projects/sax/から入手できる公式のSAX実装では、名前空間の認識がデフォルトでオンになっています。 JAXPの観点からは厳密には互換性の問題となりませんが、思いがけない結果を招くことがあります。

XSLTの起動

標準JAXP APIを使用し、XSLトランスフォーマを作成したりXSLトランスフォーマにアクセスしたりするコードは、変更する必要がありません。出力は同じですが、ほとんどの場合は生成が高速になります。これは、Xalanトランスフォーマを解釈する代わりに、XSLTCのコンパイル・トランスフォーマがデフォルトで使用されるためです。

ノート: XSLスタイル・シートの開発やテストなど、小さいデータ・セットで1回実行する場合は、XalanとXSLTCのパフォーマンス上の大きな差はありません。しかし、大きなデータ・セットでXSLTCを使用する場合には、パフォーマンス上の大きな利点があります。

プログラミングによるXalan XPathへのアクセス

JAXP 1.3は、XPath表現を評価するための標準XPath APIを提供します。このAPIを使用することをお薦めします。 Xalanインタプリタ型トランスフォーマは、リファレンス参照に含まれていません。アプリケーションがスタンドアロンXPath表現(XSLTスタイル・シートの一部でないもの)を評価するためにXalan XPath APIを明示的に使用している場合は、Xalan用のApacheライブラリをダウンロードしてインストールし、クラス・パスに指定する必要があります。

パッケージ名の変更

この変更点は、標準JAXP APIを使用するように制限されているアプリケーションには影響ありません。ただし、以前のJAXPバージョンで定義されたXMLプロセッサの実装固有の機能にアクセスするアプリケーションでは、JAXP 1.3で変更されたパッケージ名を使用するように変更する必要があります。

変更により、従来のアプリケーションには次の影響があります。

内部実装にアクセスするために使用されていたプロパティ値を変更する必要がある。
Xalan実装クラスから内部APIを使用していたアプリケーションでは、そのようなAPIにアクセスするためのimport文を変更する必要がある。
Crimson実装から内部APIを使用していたアプリケーションは、書き直す必要がある。このとき可能であれば、新しいJAXP APIまたは、必要に応じてXerces APIを使用する。

変更点と変更の理由

Java SE 1.4では、JAXPがJavaプラットフォームに組み込まれたことにはメリットもデメリットもありました。一方、アプリケーションは、それが組み込まれているという事実に依存できました。他方、ほとんどのアプリケーションでは、以降のバージョンで入手可能になった機能やバグ修正が必要でした。

しかし、内部クラスは常にクラス・パスよりも優先されるため、新しいライブラリを追加しても効果はありませんでした。 1.4ではこの問題を解決するために、承認済み標準メカニズムが使用されました。しかしそのメカニズムは新しく、アプリケーション開発者だけでなくエンド・ユーザーにも余分の労力が必要とされました。

JAXP 1.3参照名では、実装で使用されるApacheライブラリのパッケージ名を変更することで解決します。この変更により、クラス・パスで新しいApacheライブラリを参照できるため、アプリケーション開発者はそのライブラリをこれまでと同じ方法で使用しながら、Javaプラットフォームに追加されたその他の機能を利用できます。

JAXP 1.3リファレンス実装でApacheパッケージに付けられた新しい名前は次のとおりです。

	JAXP 1.1	JAXP 1.3
JAXP	`org.apache.crimson`	`-/- com.sun.org.apache.xerces.internal`
	`org.apache.xml`	`com.sun.org.apache.xml.internal`
XSLT	`org.apache.xalan org.apache.xpath org.apache.xalan.xsltc`	`com.sun.org.apache.xalan.internal com.sun.org.apache.xpath.internal com.sun.org.apache.xalan.internal.xsltc`

システム・プロパティおよび実装クラスの使用

アプリケーションが標準APIに存在しない機能にアクセスするには、コマンド行で-Dを使ってシステム・プロパティを指定しますが、このときJREのlib/jaxp.propertiesファイル内で指定するか、またはアプリケーション内にハード・コーディングして指定することが一般的です。

JAXP 1.3には、多くの新機能があります。そのようなアプリケーションをアップグレードするときは、同じジョブを行うjavax.xml.*パッケージで標準APIを検索することをお薦めします。これは、将来のアプリケーション変更を避けるのに最善の方法です。どうしても必要な場合(機能上の制約や、新APIを検証する時間がないなど)、パッケージ名をこれまでの形式から次の形式に変換してプロパティの値を変更できます。

org.apache.somePackage → com.sun.org.apache.SomePackage.internal

同様に、内部実装クラスすべてで、新しいパッケージ名を使用します。アプリケーションで実装クラスを使用している場合(推奨されない方法)、そのようなパッケージ名も変更する必要があります。

入れ子にされたエンティティ定義によるセキュリティの問題

XMLでは、再帰的なエンティティ定義は認められませんが、入れ子にされたエンティティ定義は認められます。しかし、外部ソースからのXMLデータを許可するサーバーがサービス妨害攻撃を受ける可能性があります。たとえば、次のように非常に深く入れ子にされたエンティティ定義が含まれるSOAPドキュメントは、エンティティを展開するのにCPU時間の100%と大量のメモリーを消費してしまいます。

<?xml version="1.0" encoding ="UTF-8"?>
<!DOCTYPE foobar[
  <!ENTITY x100 "foobar">
  <!ENTITY  x99 "&x100;&x100;">
  <!ENTITY  x98 "&x99;&x99;">
  ...
  <!ENTITY   x2 "&x3;&x3;">
  <!ENTITY   x1 "&x2;&x2;">
]>
  
<SOAP-ENV:Envelope xmlns:SOAP-ENV=...>
  <SOAP-ENV:Body>
    <ns1:aaa xmlns:ns1="urn:aaa" SOAP-ENV:encodingStyle="...">
      <foobar xsi:type="xsd:string">&x1;</foobar>
    </ns1:aaa>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

外部XMLデータを受け入れないシステムではこの問題を考慮する必要はありませんが、受け入れるシステムではこの問題を防ぐために、次のような予防手段のどれかを利用できます。

エンティティ展開を制限する新しいシステム・プロパティ: entityExpansionLimitシステム・プロパティを使用すると、既存のアプリケーションは、コードを再コンパイルしなくても、エンティティ展開の総回数を制限できます。エンティティ展開の上限に達すると、パーサーは致命的なエラーをスローします。 (デフォルトでは、64000に制限されています。)

システム・プロパティでエンティティ展開の上限を設定するには、Javaコマンド行で-DentityExpansionLimit=100000のようなオプションを使用します。
DTDを禁止する新しいパーサー・プロパティ: アプリケーションでは、http://apache.org/xml/features/disallow-doctype-declパーサー・プロパティをtrueに設定することもできます。この場合、受け取ったXMLドキュメントにDOCTYPE宣言が含まれていると、致命的なエラーがスローされます。このプロパティのデフォルト値はfalseです。 SOAPメッセージには文書型定義を含めることができないため、一般にこのプロパティはSOAPベースのアプリケーションで便利です。
セキュア処理のための新機能: JAXP 1.3には、新しくセキュア処理機能が含まれているため、アプリケーションではSAXParserFactoryまたは DocumentBuilderFactoryを構成して、セキュリティ保護された方法で動作するXMLプロセッサを取得できます。この機能をtrueに設定すると、エンティティ展開の制限が64000に設定されます。デフォルトの制限は、entityExpansionLimitシステム・プロパティを使用して増やすことができます。

連絡先