idlj - IDL-to-Java コンパイラ (RMI-IIOP バージョン)

idlj は、指定された IDL ファイルから Java バインディングを生成します。

形式

idlj [ options ] idl-file

options の順番は任意ですが、idl-file よりも前に指定しなければなりません。

機能説明

IDL-to-Java コンパイラは、指定された IDL ファイルに対して Java バインディングを生成します。バインディングについては、OMG Web サイトの IDL to Java のドキュメントを参照してください。

クライアントバインディングおよびサーババインディングの発行

My.idl という名前の IDL ファイルに対して Java バインディングを生成するには、次のコマンドを実行します。

idlj My.idl

クライアント側のバインディングが生成されます。このコマンドは、次のコマンドと等価です。

idlj -fclient My.idl

クライアント側のバインディングには、サーバ側のスケルトンは取り込まれていません。 インタフェースに対してサーバ側のバインディングを生成するには、次のコマンドを実行します。

idlj -fserver My.idl

サーバ側のバインディングには、クライアント側のバインディングおよびスケルトンが取り込まれています。これらは、すべて ImplBase (継承モデル) クラスです。 クライアント側とサーバ側の両方のバインディングを生成する場合は、次の等価なコマンドのうちの 1 つを使用します。

idlj -fclient -fserver My.idl
idlj -fall My.idl

デフォルトのサーバ側のモデルは、継承モデルです。 My.idl 内で My インタフェースが定義されている場合は、_MyImplBase.java というファイルが生成されます。 My に対してその実装を提供し、この実装は _MyImplBase から継承しなければなりません。

Tie モデルと呼ばれる別のサーバ側モデルがあります。 このサーバ側モデルは、委譲モデルです。 次のコマンドによって、Tie モデルに対するバインディングが生成されます。

idlj -fserverTIE My.idl
idlj -fallTIE My.idl

My インタフェースに対して、My_Tie.java が生成されます。 My_Tie のコンストラクタは、My を受け取ります。 My に対してその実装を提供する必要があります。ただし、この実装は、My インタフェース以外に、ほかのクラスから継承する必要はありません。 しかし、この実装を ORB と共に使用するには、My_Tie 内で実装をラップしなければなりません。 たとえば、次のように指定します。

MyImpl myImpl = new MyImpl ();
My_Tie tie = new My_Tie (myImpl);
orb.connect (tie);

ほかの実装から継承しなければならない場合、標準の継承モデルではなく Tie モデルを使用することがあります。 Java の場合は、インタフェースの継承の個数に制限はありませんが、クラスの継承に使用できるスロットは 1 つだけです。 継承モデルを使用した場合は、そのスロットが占有されます。 Tie モデルを使用した場合は、そのスロットが使用されず、ユーザが独自の目的で使用することができます。 ただし、間接参照のレベルが 1 つ導入されるという欠点があります。つまり、メソッドを呼び出すときに余分なメソッド呼び出しが発生します。

発行済みファイルの代替位置の指定

発行済みファイルをカレントディレクトリ以外のディレクトリに配置する場合は、次のコマンドでコンパイラを呼び出します。

idlj -td /altdir My.idl

My インタフェースの場合、このバインディングは、./My.java ではなく、/altdir/My.java などに発行されます。

インクルードファイルの代替位置の指定

My.idl にほかの IDL ファイル MyOther.idl が取り込まれている場合は、コンパイラではローカルディレクトリに MyOther.idl が格納されていると見なされます。 たとえば、このファイルが /includes に格納されている場合は、次のコマンドでコンパイラを呼び出します。

idlj -i /includes My.idl

たとえば、/moreIncludes に格納されている Another.idl が My.idl に取り込まれている場合は、次のコマンドでコンパイラを呼び出します。

idlj -i /includes -i /moreIncludes My.idl

この形式でファイルを取り込む場合、コマンドが複雑になります。このため、別の方法で、インクルードファイルの検索先をコンパイラに指定することができます。 この方法は、環境変数の概念と同じです。 CLASSPATH に指定されているディレクトリ上に、idl.config という名前のファイルを作成します。 次に、idl.config に次の形式の行を記述します。

includes=/includes;/moreIncludes

コンパイラは、このファイルを検索し、インクルードリストを読み込みます。 この例では、ディレクトリの間の区切り文字はセミコロン (;) になっています。 ただし、区切り文字は、プラットフォームに依存します。 たとえば、NT ではセミコロン、AIX ではコロンになります。

インクルードファイルに対するバインディングの発行

デフォルトでは、コマンド行で IDL ファイルに定義したインタフェースおよび構造体などにのみ、Java バインディングが生成されます。 インクルードファイルに定義されている種類の Java バインディングは生成されません。 たとえば、次の 2 つの IDL ファイルを想定します。

---

My.idl

#include <MyOther.idl>
interface My
{
};


---

MyOther.idl

interface MyOther
{
}; 

---

次のコマンドでは、My に対する Java バインディングのみが生成されます。

idlj My.idl

My.idl、および My.idl にインクルードされているファイル (この例の場合、MyOther.idl) に定義されているすべての Java バインディングを生成するには、次のコマンドを使用します。

idlj -emitAll My.idl

デフォルトの規則に関して注意しなければならないことがあります。 グローバルスコープに指定した #include 文は、記述したとおりに処理されます。 これらの #include 文は、インポート文と見なすことができます。囲むスコープ内に指定されている #include 文は、通常の #include 文として処理されます。つまり、インクルードファイル内のコードは、元のファイルに指定されている場合と同じように処理され、Java バインディングが発行されます。 例を示します。

---

My.idl

#include <MyOther.idl>
interface My
{
  #include <Embedded.idl>
}; 

---

MyOther.idl

interface MyOther
{
}; 

---

Embedded.idl

enum E {one, two, three}; 

---

次のコマンドを実行します。

idlj My.idl

次の Java ファイルが生成されます。

./MyHolder.java
./MyHelper.java
./_MyStub.java
./MyPackage
./MyPackage/EHolder.java
./MyPackage/EHelper.java
./MyPackage/E.java
./My.java

インポート文と見なされる #include に定義されているため、MyOther.java は生成されません。 ただし、E.java は、通常の #include に定義されているため生成されます。 また、Embedded.idl は、My インタフェースのスコープ内に取り込まれているので、My のスコープ内に生成されます (つまり、MyPackage 内)。

上記の例で -emitAll フラグが使用されていた場合は、すべてのインクルードファイルの Java バインディングがすべて発行されます。

パッケージの接頭辞の挿入

ABC という名前の会社が、次の IDL ファイルを構築したと仮定します。

---


Widgets.idl

module Widgets
{
  interface W1 {...};
  interface W2 {...};
}; 

---

このファイルに対して IDL-to-Java コンパイラを実行すると、Widgets パッケージ内の W1 および W2 に対して Java バインディングが生成されます。 しかし、業界の規約によって、会社のパッケージは com.<会社名> という名前のパッケージ内に配置しなければなりません。 Widgets パッケージを変更する必要があります。 規約に従って、パッケージは com.abc.Widgets になります。このパッケージの接頭辞を Widgets モジュールに配置するには、次のコマンドを実行します。

idlj -pkgPrefix Widgets com.abc Widgets.idl

Widgets.idl を取り込んでいる IDL ファイルが存在する場合は、そのコマンドにも -pkgPrefix フラグが必要です。 Widgets.idl を取り込んでいる IDL ファイルが存在しない場合は、IDL ファイルは、com.abc.Widgets パッケージではなく Widgets パッケージを検索します。

接頭辞が必要なパッケージがいくつか存在する場合は、前述した idl.config ファイルに配置する方が簡単です。 各パッケージの接頭辞行は、次の形式で記述します。

PkgPrefix.<type>=<prefix>

上記の例の場合は、次のように指定します。

PkgPrefix.Widgets=com.abc

コンパイル前のシンボルの定義

コンパイル用のシンボルが IDL ファイルに定義されていない場合は、定義する必要があります。たとえば、バインディング内にデバッグコードを取り込むときに必要になります。 次のコマンドを実行します。

idlj -d MYDEF My.idl

このコマンドは、My.idl に #define MYDEF という行を指定した場合と等価です。

既存のバインディングの保持

Java バインディングファイルがすでに存在する場合は、-keep フラグを指定すると、コンパイラによる上書きを回避できます。 デフォルトでは、すでに存在するかどうかにかかわらず、すべてのファイルが生成されます。 これらのファイルをカスタマイズした場合 (ただし、それらの内容が正確であるとき以外はカスタマイズするべきではない)、-keep オプションは有用です。次のコマンドを実行します。

idlj -keep My.idl

既存のクライアント側のバインディングが検出されなかった場合にのみ発行されます。

コンパイルの進捗状況の表示

IDL-to-Java コンパイラでは、実行の各段階で状態メッセージが生成されます。 「冗長」モードにするには、-v オプションを使用します。

idlj -v My.idl

デフォルトでは、コンパイラは冗長モードでは実行されません。

バージョン情報の表示

IDL-to-Java コンパイラのビルドバージョンを表示するには、コマンド行で -version オプションを指定します。

idlj -version

バージョン情報は、コンパイラによって生成されたバインディング内にも書き込まれます。 コマンド行にオプションを指定しても、無視されます。

オプション

-d symbol

このオプションは、IDL ファイルに次の行を追加した場合と等価です。

#define symbol

-emitAll

#include ファイルに指定されているものも含めて、すべての Java バインディングが発行されます。

-fside

発行するバインディングを定義します。side には、client、server、serverTIE、all、または allTIE から 1 つを選択します。 このフラグを指定しなかった場合は、-fclient と見なされます。

-i include-path

デフォルトでは、カレントディレクトリでインクルードファイルが検索されます。 このオプションを使用すると、ほかのディレクトリを追加できます。

-keep

生成されるファイルがすでに存在している場合は、上書きされません。 デフォルトでは、上書きされます。

-pkgPrefix type prefix

type がファイルのスコープで検出された場合は、その種類に対して生成されたすべてのファイルについて、生成される Java パッケージ名に prefix という接頭辞が追加されます。type は、トップレベルのモジュール、またはすべてのモジュールの外部で定義された IDL 型の単純名です。

-td dir

カレントディレクトリ以外の出力ディレクトリには、dir を使用します。

-nowarn, -verbose

冗長モードです。

-version

バージョン情報を表示して終了します。

オプションについての詳細は、「機能説明」を参照してください。

制約

• グローバルスコープ内でエスケープされている識別子は、IDL プリミティブ型、Object、または ValueBase と同じ綴りであってはなりません。 シンボルテーブルがこれらの識別子を使用してロードされており、それらを再定義すると元の定義が上書きされるためです。 おそらく恒久的な制約です。
• ローカルスタブ、および値をローカルに渡すときのコピーのセマンティクスが存在しません。POA の実装待ちです。
• IDL 型の fixed はサポートされていません。
• 生成されたスタブを直列化することはできません。IDL/Java マッピングの仕様 1998-08-22 の 25.3.1.3 節に要求事項が指定されていないためです。
• octet 型の定数は宣言できません。

既知の問題点

• IDL コンパイラによって生成された IDL valuetype に対する Java バインディングは、「Objects By Value」仕様の最新の OMG に完全には準拠していません。完全に準拠したバインディングは、コンパイラの今後のリリースでサポートされます。
• コンパイラによって IDL valuetype の定義に基づいて生成された Java クラスに、引数なしのコンストラクタが生成されていないことがあります。 この問題が発生した場合は、生成されたコードを編集して、public または protected の引数なしのコンストラクタを空で追加してください。
• コンパイラのコンパイル処理が正常終了しても、出力の生成に失敗することがあります。この問題が発生した場合は、-emitAll オプションを指定してください。
• コンパイラでは、推奨されていない CORBA::Principal 型は認識されません。
• 同一スコープ内に同じ名前を持つ定数とメソッドまたは属性を宣言しても、エラーは発生しません。 次の IDL では、エラーが発生するべきですが、発生しません。

      interface t {
        const long foo = 1;
        attribute long foo;
      };

• 次の IDL をコンパイルすると、エラーが発生し、「S is an undeclared type」がインタフェース B に表示されます。しかし、このエラーは本来発生するべきではありません。

      interface A { struct S { short s; }; };
      interface B:A { typedef S new_S;
                      exception ex {S f1;}; // Error for "S" here
      };

• union のデフォルト句に別の union を定義した場合は、生成された Java クラスでコンパイルエラーが発生します。 この問題を回避するには、内部の union の外部に nested union を定義してください。