モジュール java.xml.bind

パッケージ javax.xml.bind

クラスJAXBContext

java.lang.Object

javax.xml.bind.JAXBContext

public abstract class JAXBContext
extends Object

JAXBContextクラスは、JAXB APIに対するクライアントのエントリ・ポイントを提供します。 これは、JAXBバインディング・フレームワーク操作(非整列化、整列化および検証)を実装する上で必要になるXML/Javaバインディング情報を管理するための抽象化オブジェクトを提供しています。

利用可能なほかの特殊なメソッドの形式はありますが、クライアント・アプリケーションは通常、次の2つのスタイルのnewInstanceメソッドのいずれかを使用して、このクラスの新しいインスタンスを取得します。

• JAXBContext.newInstance("com.acme.foo:com.acme.bar")
  JAXBContextインスタンスは、コロンで区切られたJavaパッケージ名のリストをもとに初期化されます。 各Javaパッケージには、JAXBマップ・クラス、スキーマ派生クラス、ユーザーによって注釈が付けられたクラスが含まれます。 また、Javaパッケージに、処理すべきJAXBパッケージ注釈が含まれることもあります(JLSのセクション7.4.1名前付きパッケージを参照)。
• JAXBContext.newInstance(com.acme.foo.Foo.class)
  JAXBContextインスタンスは、パラメータとして渡されたクラスとこれらのクラスから静的に到達可能なクラスをもとに初期化されます。 詳細は、newInstance(Class...)を参照してください。

次のJAXB 1.0要件は、スキーマからJavaへのインタフェースおよび実装バインディングでのみ必要になります。 JAXB注釈付きクラスには適用されません。 JAXBプロバイダは、スキーマ派生クラスを含む各パッケージにjaxb.propertiesファイルを生成する必要があります。 このプロパティ・ファイルには、プロパティ名がjavax.xml.bind.context.factoryで、値がcreateContext APIを実装するクラス名であるプロパティが含まれる必要があります。

プロバイダが提供するクラスはjavax.xml.bind.JAXBContextに割当て可能でなくてもよく、単にcreateContext APIを実装するクラスを提供することが求められます。

また、プロバイダは、整列化および非整列化メソッドのクライアント呼出しの前にDatatypeConverter.setDatatypeConverter APIを呼び出す必要があります。 これは、これらの操作中に使用されるデータ型コンバータを構成するために必要になります。

非整列化

Unmarshallerクラスは、XMLデータをJavaコンテンツ・オブジェクト・ツリーに変換できる機能をクライアント・アプリケーションに提供します。 非整列化メソッドでは、スキーマ内で宣言された任意のグローバルXML要素を、インスタンス文書のルートとして非整列化することができます。 加えて、非整列化メソッドでは、スキーマで宣言された型定義を参照するxsi:type属性値を持つ未認識のルート文書を、インスタンス文書のルートとして非整列化することができます。 JAXBContextオブジェクトは、contextPathにリストされたスキーマ・セットにまたがるグローバル要素と型定義のマージを許可しています。 スキーマ・セット内の各スキーマは異なるネームスペースに属することができるため、非整列コンテキストへのスキーマの統一はネームスペースに依存しない必要があります。 このことは、contextPathでリストされた任意のスキーマのインスタンスであるXML文書をクライアント・アプリケーションが非整列化できることを意味します。 次に例を示します。

      JAXBContext jc = JAXBContext.newInstance( "com.acme.foo:com.acme.bar" );
      Unmarshaller u = jc.createUnmarshaller();
      FooObject fooObj = (FooObject)u.unmarshal( new File( "foo.xml" ) ); // ok
      BarObject barObj = (BarObject)u.unmarshal( new File( "bar.xml" ) ); // ok
      BazObject bazObj = (BazObject)u.unmarshal( new File( "baz.xml" ) ); // error, "com.acme.baz" not in contextPath
 

また、クライアント・アプリケーションは、既存のXMLデータを非整列化するのでなく、Javaコンテンツ・ツリーを明示的に生成することもできます。 すべてのJAXB注釈付き値クラスに対し、アプリケーションはコンストラクタを使用してコンテンツを作成できます。 スキーマ派生インタフェース/実装クラス、およびJAXBアノテーション付きクラスにバインドされていない要素を作成するには、アプリケーションに含まれる各Javaパッケージに存在する各スキーマ派生ObjectFactoryクラスcontextPath。 個々のスキーマ派生Javaクラスには、その型のオブジェクトを生成するstaticファクトリ・メソッドが存在します。 たとえば、スキーマをコンパイルしたあと、PurchaseOrderという名前のスキーマ派生インタフェースを含むパッケージcom.acme.fooがあるとします。 その型のオブジェクトを作成するために、クライアント・アプリケーションは次のファクトリ・メソッドを使用します。

       com.acme.foo.PurchaseOrder po =
           com.acme.foo.ObjectFactory.createPurchaseOrder();
 

スキーマ派生オブジェクトのインスタンスの作成後、クライアント・アプリケーションは変更用メソッドを使用してそれのコンテンツを設定できます。

生成されたObjectFactoryクラスの詳細は、仕様のセクション4.2Java Packageを参照してください。

プロバイダは、静的なnewInstance( javaContentInterface )メソッドだけでなく、ObjectFactoryというパッケージに必要なすべてのオブジェクト・ファクトリ・メソッドを含む各パッケージにクラスを生成する必要があります

整列化

Marshallerクラスは、Javaコンテンツ・ツリーを変換してXMLデータに戻す機能をクライアント・アプリケーションに提供します。 ファクトリ・メソッドを使用して手動で作成されたコンテンツ・ツリーをマーシャリングし、結果としてunmarshal操作のコンテンツ・ツリーをマーシャリングすることには違いはありません。 クライアントは、Javaコンテンツ・ツリーをXMLデータに整列化し、java.io.OutputStreamまたはjava.io.Writerに書き込むことができます。 あるいは、整列化プロセスがSAX2イベント・ストリームを生成して登録済みのContentHandlerに渡すか、DOM Nodeオブジェクトを生成することもできます。 クライアント・アプリケーションは、出力エンコーディングと、XMLデータを文書全体またはフラグメントとして整列化するかどうかを制御します。

次に、XML文書を非整列化したあと、それを整列化し直す、簡単な例を示します。

        JAXBContext jc = JAXBContext.newInstance( "com.acme.foo" );

        // unmarshal from foo.xml
        Unmarshaller u = jc.createUnmarshaller();
        FooObject fooObj = (FooObject)u.unmarshal( new File( "foo.xml" ) );

        // marshal to System.out
        Marshaller m = jc.createMarshaller();
        m.marshal( fooObj, System.out );
 

検証

検証は、JAXB 1.0以降、大きく変更されました。 Validatorクラスは、非推奨になり、オプションとされています。 これは、このクラスを使用しないことが推奨されていることを意味し、実際に、使用しているJAXBプロバイダによっては利用できない場合もあります。 Validatorに依存するJAXB 1.0クライアント・アプリケーションは、JAXB 1.0実行システムに配備された場合、まだ正常に動作します。 JAXB 2.0では、JAXP 1.3 javax.xml.validationフレームワークを公開する簡易メソッドがUnmarshallerに含まれています。 詳細は、Unmarshaller.setSchema(javax.xml.validation.Schema) APIを参照してください。

JAXB実行時バインディング・フレームワークの互換性

次のJAXB 1.0の制限は、スキーマとインタフェースまたは実装クラス間のバインディングにのみ適用されます。 このバインディングは共通の実行システムを必要としないため、JAXBクライアント・アプリケーションは、異なるプロバイダの実行時オブジェクト(JAXBContext、Marshallerなど)の混合を試みることはできません。 このことは、クライアント・アプリケーションに移植性がないことを意味しません。単に、クライアントが、スキーマをコンパイルするときに使用したのと同じプロバイダにより提供される実行システムを使用する必要があることを意味します。

JAXB実装の検出

JAXBContextのインスタンスを作成するには、JAXBContext.newInstance(...)メソッドの1つが呼び出されます。 JAX-B実装が検出された後、呼び出しは、元の呼び出しからパラメータを渡す適切なプロバイダ・メソッドcreateContext(...)に委譲されます。

JAX-B実装の発見は、JAXBContext.newInstanceが呼び出されるたびに行われます。 ユーザー固有の構成が提供されていない場合は、デフォルトのJAX-Bプロバイダを返す必要があります。

実装の検出は、以下のステップで構成されます:

1. newInstance(java.lang.String)メソッドに明示的に渡されるパッケージ/クラスは、jaxb.propertiesファイルが関連するクラス・ローダーを使用してパッケージ内で検索されるまで、指定された順序で処理されます - これはClass引数の場合はthe owner class loader、パッケージの場合は指定されたClassLoaderです。

   そのようなリソースが検出された場合、それはプロパティ・ファイルとしてloadedであり、JAXB_CONTEXT_FACTORYキーの値はプロバイダ・ファクトリ・クラスとみなされます。 値が見つからない場合、"javax.xml.bind.context.factory"は下位互換性の理由からキーとして使用されます。 このクラスは、上で説明した関連するクラス・ローダーによってロードされます。

   検索のこの段階では、一部のパッケージで強制的に特定のJAXB実装を使用できます。 (たとえば、スキーマ・コンパイラによってコード内に何らかのベンダー拡張機能が生成されている場合があります。)

   この構成メソッドは非推奨です。

2. システム・プロパティJAXB_CONTEXT_FACTORYが存在する場合は、その値がプロバイダ・ファクトリ・クラスと見なされます。 このようなプロパティが存在しない場合、下位互換性の理由から、プロパティ"javax.xml.bind.context.factory"および"javax.xml.bind.JAXBContext"も(この順番で)でチェックされます。 検索のこの段階では、JVM単位でJAXB実装をオーバーライドできます。
3. JAXBContextFactoryのプロバイダは、ServiceLoaderクラスで定義されているサービス・プロバイダのローディング機能を使用してロードされ、デフォルトのロード・メカニズムを使用してサービスの実装の検索とロードを試みます: サービス・プロバイダ・ローディング機能は、現在のスレッド・コンテキスト・クラス・ローダーを使用してコンテキスト・ファクトリをロードしようとします。 コンテキスト・クラス・ローダーがnullの場合、システム・クラス・ローダーが使用されます。
   service configuration errorの場合はJAXBExceptionがスローされます。
4. 提供されたクラス・ローダーを使用してリソース/META-INF/services/javax.xml.bind.JAXBContextを探します。 クラス・ローダー・パラメータを持たないメソッドは、Thread.currentThread().getContextClassLoader()を使用します。 そのようなリソースが存在する場合、その内容はプロバイダ・ファクトリ・クラスとみなされます。 この構成メソッドは非推奨です。
5. 最後に、上記のすべての手順が失敗した場合、残りの検索は指定されていません。 つまり、推奨される動作では、ハードコードされたプラットフォームのデフォルトのJAXB実装が検索されます。 ルックアップのこの段階は、Java SEが最後の手段として独自のJAXB実装を持つことができるようにすることです。

プロバイダ・ファクトリ・クラスが検出されると、コンテキスト作成はcreateContext(...)メソッドの1つに委譲されます。 下位互換性の理由から、プロバイダ・ファクトリ・クラスを実装する方法は2つあります:

1. クラスはJAXBContextFactoryの実装です。 引数なしのコンストラクタも実装する必要があります。 他のステップで見つかった場合は3、引数なしのコンストラクタを使用する新しいインスタンスが最初に作成されます。 その後、このインスタンスに対して適切なインスタンス・メソッドが呼び出されます。
2. クラスは上記のインタフェースの実装ではなく、次の静的メソッドのシグネチャを実装することが義務付けられています:

   
    public static JAXBContext createContext(
                                         String contextPath,
                                         ClassLoader classLoader,
                                         Map<String,Object> properties ) throws JAXBException
   
    public static JAXBContext createContext(
                                         Class[] classes,
                                         Map<String,Object> properties ) throws JAXBException
    

   このシナリオでは、インスタンス・メソッドの代わりに適切な静的メソッドが使用されます。 この方法はServiceLoaderと互換性がないため、ステップ3では使用できません。

アプローチ1 (JAXBContextFactory)と2 (インタフェースなし、静的メソッド)のどちらを使用するかにかかわらず、与えられたメソッドcreateContext(...)の動作に違いはありません。

APIの注:

リソース/META-INF/services/javax.xml.bind.JAXBContext (ステップ4で説明した)を使用するサービス検出メソッドは、下位互換性を可能にするためだけにサポートされています。標準のServiceLoaderメカニズム(ステップ3で説明した)に移行することを強く推奨します。 ここでの違いは、リソース名であり、サービス型名と一致しません。

また、JAXBContextFactoryインタフェースを実装するプロバイダを使用する方が静的メソッドを定義するものよりも優先されます。JAXB_CONTEXT_FACTORYプロパティはプロパティ"javax.xml.bind.context.factory"よりも優先されます

実装上の注意:

最後のステップで、Glassfish AS環境が検出された場合は、その特定のサービス・ローダーを使用してファクトリ・クラスを検索します。

導入されたバージョン:

1.6, JAXB 1.0

関連項目:

Marshaller, Unmarshaller, 「S 7.4.1 Java言語仕様における"名前付きパッケージ"」

フィールドのサマリー

フィールド

修飾子と型	フィールド	説明
static String	JAXB_CONTEXT_FACTORY	新しいJAXBContextオブジェクトを作成可能なクラスの名前を含むプロパティの名前です。

コンストラクタのサマリー

コンストラクタ

修飾子	コンストラクタ	説明
protected	JAXBContext()

メソッドのサマリー

修飾子と型	メソッド	説明
Binder<Node>	createBinder()	W3C DOM用のBinderを作成します。
<T> Binder<T>	createBinder(Class<T> domType)	関連付けされた、またはインプレースの非整列化または整列化に使用できるBinderオブジェクトを作成します。
JAXBIntrospector	createJAXBIntrospector()	JAXBオブジェクトをイントロスペクションするために使用できるJAXBIntrospectorオブジェクトを作成します。
abstract Marshaller	createMarshaller()	Javaコンテンツ・ツリーをXMLデータに変換するために使用できるMarshallerオブジェクトを作成します。
abstract Unmarshaller	createUnmarshaller()	XMLデータをJavaコンテンツ・ツリーに変換するために使用できるUnmarshallerオブジェクトを作成します。
abstract Validator	createValidator()	非推奨。 JAXB2.0以降
void	generateSchema(SchemaOutputResolver outputResolver)	このコンテキストのスキーマ文書を生成します。
static JAXBContext	newInstance(Class<?>... classesToBeBound)	JAXBContextクラスの新しいインスタンスを作成します。
static JAXBContext	newInstance(Class<?>[] classesToBeBound, Map<String,?> properties)	JAXBContextクラスの新しいインスタンスを作成します。
static JAXBContext	newInstance(String contextPath)	JAXBContextクラスの新しいインスタンスを作成します。
static JAXBContext	newInstance(String contextPath, ClassLoader classLoader)	JAXBContextクラスの新しいインスタンスを作成します。
static JAXBContext	newInstance(String contextPath, ClassLoader classLoader, Map<String,?> properties)	JAXBContextクラスの新しいインスタンスを作成します。

クラス java.lang.Objectで宣言されたメソッド

clone、equals、finalize、getClass、hashCode、notify、notifyAll、toString、wait、wait、wait

フィールドの詳細

JAXB_CONTEXT_FACTORY

public static final String JAXB_CONTEXT_FACTORY

新しいJAXBContextオブジェクトを作成可能なクラスの名前を含むプロパティの名前です。

関連項目:

定数フィールド値

コンストラクタの詳細

JAXBContext

protected JAXBContext()

メソッドの詳細

newInstance

public static JAXBContext newInstance(String contextPath)
                               throws JAXBException

JAXBContextクラスの新しいインスタンスを作成します。

これは、newInstance(String,ClassLoader)メソッドを呼び出すための簡易メソッドです。現在のスレッドのコンテキスト・クラス・ローダーを使用します。

例外:

JAXBException - JAXBContextの作成中に次のようなエラーが発生した場合

1. パッケージ内でObjectFactory.classまたはjaxb.indexが見つからない
2. contextPathに含まれるグローバル要素間であいまいさがある
3. コンテキスト・ファクトリ・プロバイダ・プロパティの値が見つからない
4. 同じcontextPathに異なるプロバイダからのスキーマ派生パッケージが混在している
5. パッケージがjava.xml.bindモジュールに対してオープンしていない

newInstance

public static JAXBContext newInstance(String contextPath,
                                      ClassLoader classLoader)
                               throws JAXBException

JAXBContextクラスの新しいインスタンスを作成します。

クライアント・アプリケーションは、コロン(:、\u003A)で区切られたJavaパッケージ名のリストであるコンテキスト・パスを提供する必要があります。これには、スキーマ派生クラスおよび完全修飾JAXB注釈付きクラスの両方またはいずれか一方が含まれます。 スキーマ派生コードは、パッケージごとに生成されたObjectFactory.classによってJAXBContextに登録されます。 あるいは、コンテキスト・パスにリストするのではなく、プログラマが注釈を指定したJAXBマップ・クラスを次の形式でjaxb.indexリソース・ファイルにリストすることもできます。 Javaパッケージは、スキーマ派生クラスとユーザー注釈JAXBクラスの両方を含むことができます。 また、Javaパッケージに、処理すべきJAXBパッケージ注釈が含まれることもあります(JLSのセクション7.4.1名前付きパッケージを参照)。

contextPathにリストされる各パッケージは、次の条件の 1つまたは両方を満たす必要があります。これを満たさない場合、JAXBExceptionがスローされます。

1. ObjectFactory.classを含むこと
2. jaxb.indexを含むこと

jaxb.indexの形式

このファイルには、改行で区切れられたクラス名のリストが含まれます。 空白文字とタブ文字、および空白行は無視されます。 コメント文字は#(0x23)で、行の最初のコメント文字に続く文字はすべて無視されます。 ファイルはUTF-8で符号化されている必要があります。 また、newInstance(Class...)で定義されたとおり、リストされたクラスから到達可能なクラスがJAXBContextに登録されます。

jaxb.indexファイルで発生するクラス名の制約は、次のとおりです。

• 「.class」で終わってはならない。
• jaxb.indexファイルを含むパッケージに対して相対的にクラス名が解決される。 jaxb.indexファイルを含むパッケージに直接発生するクラスのみが許可される。
• 完全指定されたクラス名は許可されない。 入れ子または内部クラスを指定する際は、現在のパッケージに対して相対的に修飾されたクラス名のみが許可される。

スキーマ・カスタマイズ<jaxb:globalBindings valueClass="false">によって有効化される、JAXB 1.0スキーマからJavaへのインタフェース/実装バインディングとの互換性を維持するため、JAXBプロバイダはコンテキスト・パス上の各パッケージにjavax.xml.bind.context.factoryプロパティの値を含むjaxb.propertiesファイルが含まれ、すべての値が同じプロバイダに解決されることを保証します。 この要件は、JAXB注釈付きクラスには適用されません。

contextPathにリストされたさまざまなパッケージにまたがってグローバルXML要素名の競合が発生した場合、JAXBExceptionがスローされます。

同じコンテキスト・パス内に複数のJAXBプロバイダから生成されたインタフェース/実装バインディングが混在する場合、JAXBExceptionがスローされる可能性があります。

JAXB実装の検出に関連する手順は、クラスjavadocで説明します。

パラメータ:

contextPath - スキーマ派生クラスおよび/またはjava to schema (JAXB-annotated)マップ・クラスを含むJavaパッケージ名のリスト。 contextPathの名前付きモジュールに含まれるパッケージは、少なくともjava.xml.bindモジュールに対してopenでなければなりません。

classLoader - このクラス・ローダーが実装クラスの場所の特定に使用される。

戻り値:

JAXBContextの新しいインスタンス

例外:

JAXBException - JAXBContextの作成中に次のようなエラーが発生した場合

1. パッケージ内でObjectFactory.classまたはjaxb.indexが見つからない
2. contextPathに含まれるグローバル要素間であいまいさがある
3. コンテキスト・ファクトリ・プロバイダ・プロパティの値が見つからない
4. 同じcontextPathに異なるプロバイダからのスキーマ派生パッケージが混在している
5. パッケージがjava.xml.bindモジュールに対してオープンしていない

newInstance

public static JAXBContext newInstance(String contextPath,
                                      ClassLoader classLoader,
                                      Map<String,?> properties)
                               throws JAXBException

JAXBContextクラスの新しいインスタンスを作成します。

これは、newInstance(String, ClassLoader)とほとんど同じですが、このバージョンではJAXBContextのインスタンス化を設定するためにプロバイダ固有のプロパティを渡すことができます。

プロパティの解釈は、実装に委ねられます。 実装は、理解できないプロパティを検出した場合は、JAXBExceptionをスローする必要があります。

パラメータ:

contextPath - スキーマ派生クラスおよび/またはjava to schema (JAXB-annotated)マップ・クラスを含むJavaパッケージ名のリスト。 contextPathの名前付きモジュールに含まれるパッケージは、少なくともjava.xml.bindモジュールに対してopenでなければなりません。

classLoader - このクラス・ローダーが実装クラスの場所の特定に使用される。

properties - プロバイダ固有のプロパティ。 nullでもよいが、空マップで渡す場合と同じことを意味する。

戻り値:

JAXBContextの新しいインスタンス

例外:

JAXBException - JAXBContextの作成中に次のようなエラーが発生した場合

1. パッケージ内でObjectFactory.classまたはjaxb.indexが見つからない
2. contextPathに含まれるグローバル要素間であいまいさがある
3. コンテキスト・ファクトリ・プロバイダ・プロパティの値が見つからない
4. 同じcontextPathに異なるプロバイダからのスキーマ派生パッケージが混在している
5. パッケージがjava.xml.bindモジュールに対してオープンしていない

導入されたバージョン:

1.6, JAXB 2.0

newInstance

public static JAXBContext newInstance(Class<?>... classesToBeBound)
                               throws JAXBException

JAXBContextクラスの新しいインスタンスを作成します。

クライアント・アプリケーションは、新しいコンテキスト・オブジェクトが認識する必要があるクラスのリストを提供する必要があります。 新しいコンテキストは、指定されたすべてのクラスを認識するだけでなく、指定されたクラスから静的に直接または間接的に参照されているすべてのクラスも認識するようになります。 参照されているクラスのサブクラスおよびXmlTransient参照クラスは、JAXBContextに登録されません。 たとえば、次のJavaコードでは、newInstance(Foo.class)を呼び出した場合、新しく作成されたJAXBContextでFooとBarの両方が認識されるようになりますが、ZotとFooBarは認識されません。

 class Foo {
      @XmlTransient FooBar c;
      Bar b;
 }
 class Bar { int x; }
 class Zot extends Bar { int y; }
 class FooBar { }
 

そのため、一般的なクライアント・アプリケーションでは、トップレベル・クラスを指定するだけで済みますが、注意深く指定する必要があります。

JAXBContextに登録された各Javaパッケージに対して、オプションのパッケージ注釈が存在する場合、それらが処理される必要があります(JLSのセクション7.4.1「名前付きパッケージ」を参照)。

JAXB実装の検出に関連する手順は、クラスjavadocで説明します。

パラメータ:

classesToBeBound - 新しいJAXBContextによって認識されるJavaクラスのリスト。 名前付きモジュールにあるclassesToBeBoundのクラスは、openから少なくともjava.xml.bindモジュールまでのパッケージ内になければなりません。 空でもよいが、その場合は仕様定義済みクラスだけを認識しているJAXBContextが返される。

戻り値:

JAXBContextの新しいインスタンス。

例外:

JAXBException - JAXBContextの作成中に次のようなエラーが発生した場合(ただし、これらに限定されない)。

1. JAXB実装が検出されない
2. クラスがJAXB注釈を誤って使用している
3. クラス間に重複する注釈がある(たとえば、同じ型名を持つ2つのクラス)
4. JAXB実装がプロバイダ固有の帯域外情報を見つけられない場合(開発時に生成された追加ファイルなど)
5. classesToBeBoundはjava.xml.bindモジュールに対してオープンしていません

IllegalArgumentException - パラメータにnullが含まれる場合(つまり、newInstance(null);)

導入されたバージョン:

1.6, JAXB 2.0

newInstance

public static JAXBContext newInstance(Class<?>[] classesToBeBound,
                                      Map<String,?> properties)
                               throws JAXBException

JAXBContextクラスの新しいインスタンスを作成します。

JAXBContextのこのインスタンス化に対してpropertiesを構成するnewInstance(Class...)のオーバーロードです。

プロパティの解釈は、実装に委ねられます。 実装は、理解できないプロパティを検出した場合は、JAXBExceptionをスローする必要があります。

パラメータ:

classesToBeBound - 新しいJAXBContextによって認識されるJavaクラスのリスト。 名前付きモジュールにあるclassesToBeBoundのクラスは、openから少なくともjava.xml.bindモジュールまでのパッケージ内になければなりません。 空でもよいが、その場合は仕様定義済みクラスだけを認識しているJAXBContextが返される。

properties - プロバイダ固有のプロパティ。 nullでもよいが、空マップで渡す場合と同じことを意味する。

戻り値:

JAXBContextの新しいインスタンス。

例外:

JAXBException - JAXBContextの作成中に次のようなエラーが発生した場合(ただし、これらに限定されない)。

1. JAXB実装が検出されない
2. クラスがJAXB注釈を誤って使用している
3. クラス間に重複する注釈がある(たとえば、同じ型名を持つ2つのクラス)
4. JAXB実装がプロバイダ固有の帯域外情報を見つけられない場合(開発時に生成された追加ファイルなど)
5. classesToBeBoundはjava.xml.bindモジュールに対してオープンしていません

IllegalArgumentException - パラメータにnullが含まれる場合(つまり、newInstance(null,someMap);)

導入されたバージョン:

1.6, JAXB 2.0

createUnmarshaller

public abstract Unmarshaller createUnmarshaller()
                                         throws JAXBException

XMLデータをJavaコンテンツ・ツリーに変換するために使用できるUnmarshallerオブジェクトを作成します。

戻り値:

Unmarshallerオブジェクト

例外:

JAXBException - Unmarshallerオブジェクトの作成中にエラーが発生した場合

createMarshaller

public abstract Marshaller createMarshaller()
                                     throws JAXBException

Javaコンテンツ・ツリーをXMLデータに変換するために使用できるMarshallerオブジェクトを作成します。

戻り値:

Marshallerオブジェクト

例外:

JAXBException - Marshallerオブジェクトの作成中にエラーが発生した場合

createValidator

@Deprecated
public abstract Validator createValidator()
                                   throws JAXBException

非推奨。

JAXB2.0以降

Validatorは、JAXB 2.0ではオプションであり、非推奨です。 詳細は、Validatorに関するjavadocを参照してください。

Javaコンテンツ・ツリーをそれのソース・スキーマに照らし合わせて検証するために使用できるValidatorオブジェクトを作成します。

戻り値:

Validatorオブジェクト

例外:

JAXBException - Validatorオブジェクトの作成中にエラーが発生した場合

createBinder

public <T> Binder<T> createBinder(Class<T> domType)

関連付けされた、またはインプレースの非整列化または整列化に使用できるBinderオブジェクトを作成します。

パラメータ:

domType - そのDOM Nodeクラスを渡すことによって使用するDOM APIを選択する。

戻り値:

常に新しい有効なBinderオブジェクト。

例外:

UnsupportedOperationException - domTypeに対応するDOM APIが実装によってサポートされていない場合。

導入されたバージョン:

1.6, JAXB 2.0

createBinder

public Binder<Node> createBinder()

W3C DOM用のBinderを作成します。

戻り値:

常に新しい有効なBinderオブジェクト。

導入されたバージョン:

1.6, JAXB 2.0

createJAXBIntrospector

public JAXBIntrospector createJAXBIntrospector()

JAXBオブジェクトをイントロスペクションするために使用できるJAXBIntrospectorオブジェクトを作成します。

戻り値:

常にnull以外の有効なJAXBIntrospectorオブジェクトを返す。

例外:

UnsupportedOperationException - JAXB 1.0実装でこのメソッドを呼び出した場合、UnsupportedOperationExceptionがスローされる。

導入されたバージョン:

1.6, JAXB 2.0

generateSchema

public void generateSchema(SchemaOutputResolver outputResolver)
                    throws IOException

このコンテキストのスキーマ文書を生成します。

パラメータ:

outputResolver - このオブジェクトは、スキーマの送信先となる出力を制御する。

例外:

IOException - SchemaOutputResolverがIOExceptionをスローする場合。

UnsupportedOperationException - JAXB 1.0実装でこのメソッドを呼び出した場合、UnsupportedOperationExceptionがスローされる。

導入されたバージョン:

1.6, JAXB 2.0