idlj.1 revision 2362
2N/A." or visit www.oracle.com if you need additional information or have any
\f2idl\-file\fP は、インタフェース定義言語 (IDL) による定義が入ったファイルの名前です。\f2options\fP の順番は任意ですが、\f2idl\-file\fP よりも前に指定しなければなりません。
http://java.sun.com/javase/6/docs/technotes/guides/idl/mapping/jidlMapping.html を参照してください。IDL\-to\-Java コンパイラの以前のリリースの中には、\f2idltojava\fP という名前だったものがあります。
これにより、クライアント側のバインディングが生成されます。 このコマンドは、次のコマンドと等価です。 \f2idlj \fP\f4\-fclient\fP\f2 My.idl\fP
クライアント側のバインディングには、サーバー側のスケルトンは組み込まれていません。インタフェースに対してサーバー側のバインディングを生成するには、次のコマンドを実行します。 \f2idlj \fP\f4\-fserver\fP\f2 My.idl\fP
サーバー側のバインディングには、クライアント側のバインディングに加えて、スケルトンが組み込まれてています。 これらは、すべて \f2POA\fP (継承モデル) クラスです。クライアント側とサーバー側の両方のバインディングを生成する場合は、次のコマンド (どれも等価) のうちの 1 つを使用します。 \f2idlj \fP\f4\-fclient \-fserver\fP\f2 My.idl\fP
\f2idlj \fP\f4\-fall\fP\f2 My.idl\fP
デフォルトのサーバー側のモデルは、「移殖可能サーバント継承モデル」です。\f2My.idl\fP 内で \f2My\fP インタフェースが定義されている場合は、\f2MyPOA.java\fP というファイルが生成されます。\f2My\fP に対してその実装を提供し、この実装は \f2_MyPOA\fP から継承する必要があります。
\f2MyPOA.java\fP は
http://java.sun.com/javase/6/docs/api/org/omg/PortableServer/Servant.html を拡張するストリームベースのスケルトンで、スケルトンが実装する IDL インタフェースに関連付けられている \f2InvokeHandler\fP インタフェースとオペレーションインタフェースを実装します。
http://java.sun.com/javase/6/docs/technotes/guides/idl/POA.html の \f2PortableServer\fP モジュールは、ネイティブの \f2Servant\fP 型を定義します。Java プログラミング言語では、\f2Servant\fP 型は、Java の \f2org.omg.PortableServer.Servant\fP クラスにマッピングされています。これはあらゆる POA サーバント実装の基底クラスとなり多数のメソッドを提供します。 これらのメソッドはアプリケーションプログラマが呼び出すだけではなく、POA 自身からも呼び出され、場合によってはサーバントの動作を制御するためにユーザーがオーバーライドすることもあります。
継承モデルのもう 1 つのオプションは、\f2\-oldImplBase\fP フラグを使用して、J2SE 1.4 より前のバージョンの Java プログラミング言語と互換性のあるサーバー側バインディングを生成することです。ただし、\f2\-oldImplBase\fP フラグを使用するのは、標準的な手法ではありません。これらの API は推奨されていません。このフラグを使用するのは、J2SE 1.3 で記述された既存のサーバーとの互換性を保つ場合だけです。その場合、既存の MAKEFILE を変更して \f2idlj\fP コンパイラに \f2\-oldImplBase\fP フラグを追加する必要があります。 フラグを追加しない場合、POA ベースのサーバー側マッピングが生成されます。下位互換性のあるサーバー側バインディングを生成するには、次のコマンドを使用します。
\f2idlj \fP\f4\-fclient \-fserver\fP\f2 \fP\f4\-oldImplBase\fP\f2 My.idl\fP
\f2idlj \fP\f4\-fall\fP\f2 \fP\f4\-oldImplBase\fP\f2 My.idl\fP
\f2My.idl\fP 内で \f2My\fP インタフェースが定義されている場合は、\f2_MyImplBase.java\fP というファイルが生成されます。\f2My\fP に対してその実装を提供し、この実装は \f2_MyImplBase\fP から継承しなければなりません。
もう 1 つのサーバー側モデルは、Tie モデルと呼ばれるものです。このサーバー側モデルは、委譲モデルです。Tie とスケルトンを同時に生成することはできないため、それらは別々に生成しなければなりません。次のコマンドによって、Tie モデル用のバインディングが生成されます。
\f2idlj \fP\f4\-fall\fP\f2 My.idl\fP
\f2idlj \fP\f4\-fallTIE\fP\f2 My.idl\fP
\f2My\fP というインタフェースの場合、上記の 2 番目のコマンドにより、\f2MyPOATie.java\fP が生成されます。\f2MyPOATie\fP のコンストラクタは、\f2delegate\fP を取ります。この例では、デフォルトの POA モデルを使用しているため、コンストラクタにも \f2poa\fP が必要です。\f2delegate\fP に対して実装を提供しなければなりませんが、この実装は \f2MyOperations\fP インタフェースから継承する必要があるだけで、その他のクラスから継承する必要はありません。しかし、この実装を ORB と一緒に使用するには、\f2MyPOATie\fP 内で実装をラップしなければなりません。たとえば、次のようにします。
POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
rootpoa.the_POAManager().activate();
myDelegate.setORB(orb);
他の実装から継承しなければならない場合、標準の継承モデルではなく Tie モデルを使用することがあります。Java の場合は、インタフェースの継承の個数に制限はありませんが、クラスの継承に使用できるスロットは 1 つだけです。継承モデルを使用した場合は、そのスロットが占有されます。Tie モデルを使用した場合は、そのスロットが使用されず、ユーザーが独自の目的で使用することができます。ただし、間接参照のレベルが 1 つ導入されるという欠点があります。つまり、メソッドを呼び出すときに余分なメソッド呼び出しが発生します。
\f2idlj \fP\f4\-oldImplBase\fP\f2 \fP\f4\-fall\fP\f2 My.idl\fP
\f2idlj \fP\f4\-oldImplBase\fP\f2 \fP\f4\-fallTIE\fP\f2 My.idl\fP
\f2My\fP というインタフェースの場合、これにより \f2My_Tie.java\fP が生成されます。\f2My_Tie\fP のコンストラクタは、\f2impl\fP を取ります。\f2impl\fP に対して実装を提供しなければなりませんが、その実装は \f2HelloOperations\fP インタフェースから継承する必要があるだけで、その他のクラスから継承する必要はありません。しかし、この実装を ORB と一緒に使用するには、\f2My_Tie\fP 内で実装をラップしなければなりません。たとえば、次のようにします。
myDelegate.setORB(orb);
\f2idlj \fP\f4\-td /altdir\fP\f2 My.idl\fP
\f2My.idl\fP にもう 1 つの IDL ファイル \f2MyOther.idl\fP がインクルードされている場合、コンパイラは、ローカルディレクトリに \f2MyOther.idl\fP があるものと想定します。もしそのファイルが、たとえば \f2/includes\fP にある場合は、次のようなコマンドでコンパイラを呼び出します。 \f2idlj \fP\f4\-i /includes\fP\f2 My.idl\fP
また、もし \f2My.idl\fP に、たとえば \f2/moreIncludes\fP にある \f2Another.idl\fP もインクルードされているのであれば、次のようなコマンドでコンパイラを呼び出します。 \f2idlj \fP\f4\-i /includes \-i /moreIncludes\fP\f2 My.idl\fP
このような形式でインクルードを指定すると、コマンドが長くて複雑になります。 そこで、インクルードファイルを検索する場所をコンパイラに指示するための別の方法が用意されています。この方法は、環境変数の考え方と似ています。CLASSPATH にリストされているディレクトリ内に \f2idl.config\fP という名前のファイルを作成します。その \f2idl.config\fP の中に、次のような形式の行を入れます。 \f2includes=/includes;/moreIncludes\fP
コンパイラは、このファイルを検索し、インクルードリストを読み込みます。この例では、ディレクトリの間の区切り文字はセミコロン (;) になっています。この区切り文字は、プラットフォームによって異なります。たとえば、Windows プラットフォームではセミコロンですが、Unix プラットフォームではコロンです。 \f2インクルード\fPの詳細については、
http://java.sun.com/javase/6/docs/technotes/tools/index.html#general を参照してください。
デフォルトでは、コマンド行に指定した IDL ファイルで定義されているインタフェースや構造体などについてのみ、Java バインディングが生成されます。インクルードされたファイルで定義されている型については、Java バインディングは生成されません。たとえば、次の 2 つの IDL ファイルについて考えてみましょう。 \f4My.idl\fP
\f2#include <MyOther.idl>\fP
\f4MyOther.idl\fP
次のコマンドでは、\f2My\fP に対する Java バインディングだけが生成されます。 \f2idlj My.idl\fP
\f2My.idl\fP で定義されている型と、\f2My.idl\fP にインクルードされたファイル (この例では \f2MyOther.idl\fP) で定義されている型すべてについて Java バインディングを生成するには、次のコマンドを使用します。 \f2idlj \fP\f4\-emitAll\fP\f2 My.idl\fP
このデフォルトの規則に関して注意しなければならないことがあります。グローバルスコープに指定した \f2#include\fP 文は、前述のとおりに処理されます。これらの \f2#include\fP 文は、インポート文と見なすことができます。それに対して、他の定義に囲まれたスコープ内に指定した \f2#include\fP 文は、本当の意味での \f2#include\fP 文として処理されます。 つまり、インクルードされたファイルにあるコードが、元のファイルにそのまま指定されているかのように処理され、それに対して Java バインディングが発行されます。次に例を示します。 \f4My.idl\fP
\f2#include <MyOther.idl>\fP
\f2\ #include <Embedded.idl>\fP
\f2};\ \fP \f4MyOther.idl\fP
\f2};\ \fP \f4Embedded.idl\fP
このとき、次のコマンドを実行すると、 \f2idlj My.idl\fP
次のような一連の Java ファイルが生成されます。 \f2./MyHolder.java\fP
\f2./_MyStub.java\fP
\f2./MyPackage\fP
\f2./My.java\fP
インポート文と見なされる \f2#include\fP に定義されているため、\f2MyOther.java\fP は生成されません。ただし、本当の意味での \f2#include\fP で定義されているため、\f2E.java\fP は生成されます。さらに、\f2Embedded.idl\fP が \f2My\fP インタフェースのスコープ内にインクルードされていたため、\f2My\fP のスコープ内 (つまり、\f2MyPackage\fP 内) に生成されています。
\f4Widgets.idl\fP
このファイルに対して IDL\-to\-Java コンパイラを実行すると、\f2W1\fP および \f2W2\fP に対する Java バインディングが \f2Widgets\fP パッケージ内に生成されます。しかし、業界の慣例によると、会社のパッケージは、\f2com.<会社名>\fP という名前のパッケージ内に置くことになっています。そのため、\f2Widgets\fP パッケージでは不十分です。慣例に従うには、パッケージを \f2com.abc.Widgets\fP にする必要があります。このパッケージ接頭辞を \f2Widgets\fP モジュールに付加するには、次のコマンドを実行します。 \f2idlj \fP\f4\-pkgPrefix Widgets com.abc\fP\f2 Widgets.idl\fP
\f2Widgets.idl\fP をインクルードしている IDL ファイルがある場合は、そのコマンドにも \f2\-pkgPrefix\fP フラグが必要です。このフラグを指定しないと、その IDL ファイルは、\f2com.abc.Widgets\fP パッケージではなく、\f2Widgets\fP パッケージを検索することになります。
接頭辞が必要なパッケージがいくつもある場合は、前述の \f2idl.config\fP ファイルで接頭辞を指定するのが簡単です。パッケージの接頭辞を指定する行は、それぞれ次の形式で記述します。
コンパイル用のシンボルが IDL ファイル内で定義されていない場合は、そのシンボルを定義する必要があります。 これは、たとえば、バインディング内にデバッグコードを組み入れるときに使用します。次のコマンドは、 \f2idlj \fP\f4\-d\fP\f2 MYDEF My.idl\fP
\f2My.idl\fP 内に \f2#define MYDEF\fP という行を指定した場合と等価です。
Java バインディングファイルがすでに存在する場合は、\f2\-keep\fP フラグを指定すると、コンパイラによる上書きを回避できます。デフォルトでは、すでに存在するかどうかにかかわらず、すべてのファイルが生成されます。これらのファイルをカスタマイズした場合 (ただし、それらの内容が正確であるとき以外はカスタマイズは避ける)、\f2\-keep\fP オプションは有用です。次のコマンドは、 \f2idlj \fP\f4\-keep\fP\f2 My.idl\fP
IDL\-to\-Java コンパイラは、実行の各段階で状態メッセージを生成します。「冗長」モード (メッセージが多いモード) にするには、\f2\-v\fP オプションを使用します。 \f2idlj \fP\f4\-v\fP\f2 My.idl\fP
発行するバインディングを定義します。 \f2side\fP は、\f2client\fP、\f2server\fP、\f2serverTIE\fP、\f2all\fP、\f2allTIE\fP のどちらかです。\f2\-fserverTIE\fP または \f2\-fallTIE\fP オプションを指定すると、委譲モデルスケルトンが発行されます。このフラグを指定しなかった場合は、\f2\-fclient\fP が指定されたものと見なされます。
v1.4 より前の JDK ORB と互換性のあるスケルトンを生成します。デフォルトでは、POA 継承モデルのサーバー側バインディングが生成されます。このオプションを指定すると、\f2ImplBase\fP 継承モデルのクラスであるサーバー側バインディングが生成されるので、古いバージョンの Java プログラミング言語との下位互換性が得られます。
\f2type\fP がファイルスコープで検出された場合は、その型に対して生成されるすべてのファイルについて、生成される Java パッケージ名に \f2prefix\fP という接頭辞が付加されます。\f2type\fP は、トップレベルモジュールの単純名か、どのモジュールよりも外側で定義された IDL 型の単純名のどちらかです。
識別子の中にモジュール名 \f2type\fP が検出されると、生成される Java パッケージ内のすべてのファイルについて、識別子の中のその名前が \f2package\fP で置き換えられます。最初に \f2pkgPrefix\fP を変更します。\f2type\fP は、トップレベルのモジュール、またはすべてのモジュールの外部で定義された IDL 型の単純名です。 そして、完全なパッケージ名に正確に一致しなければなりません。
これらのパッケージ名を変換しようとすると、互換性のないコードが生成されます。 そして、\f2\-pkgTranslate\fP のあとの最初の引数としてそれらのパッケージを使用すると、エラーとして扱われます。
\f2oldImplBase\fP Tie クラスの場合は「%_Tie」(\f2\-oldImplBase\fP かつ (\f2\-fserverTie\fP または \f2\-fallTie\fP))
グローバルスコープ内のエスケープされた識別子は、IDL プリミティブ型の \f2Object\fP または \f2ValueBase\fP と同じ綴りであってはなりません。これらの識別子については、シンボルテーブルが事前にロードされており、これらの識別子の再定義を許可すると元の定義が上書きされてしまいます。これは、おそらく恒久的な制約です。