idlj(1)

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

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

形式
idlj [ options ] idl-file

idl-file には、Interface Definition Language (IDL) 定義が格納されている ファイルの名前を指定します。 Options は任意の順序で指定できますが、 idl-file よりも前に指定する必要があります。

機能説明
IDL-to-Java コンパイラは、指定された IDL ファイルに対して Java バインディングを生成します。バインディングの詳細は、『OMG IDL to Java Language Mapping Specification』を参照してください。 IDL-to-Java コンパイラの旧リリースのなかには、 idltojavaという名前が付けられていたものがあります。

クライアントバインディングとサーババインディングの発行
My.idl という名前の IDL ファイルに対して Java バインディングを生成 するには、次のように指定します。

    idlj My.idl

クライアント側のバインディングを生成する上記のコマンドは、 次のようにも指定できます。

    idlj -fclient My.idl

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

    idlj -fserver My.idl

サーバ側のバインディングには、クライアント側のバインディングのほか にスケルトンが取り込まれています。これらはすべて、POA (継承モデル) クラスです。クライアント側とサーバ側の両方のバインディングを生成する には、以下の等価コマンドのどちらか一方を使用してください。

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

サーバ側モデルとしては、継承モデルと Tie モデルの 2 種類を 利用できます。

1.4 における新機能: デフォルトのサーバ側モデルは、 Portable Servant Inheritance Model です。 My.idl でインタフェース My が定義されていると、ファイル MyPOA.javaが生成されます。ユーザは、 Myに対してその実装を提供する必要があります。この実装は、 MyPOAから継承しなければなりません。

MyPOA.javaは、 org.omg.PortableServer.Servant を拡張するストリームベースのスケルトンであり、このスケルトンが実装する IDL インタフェースに関連した InvokeHandler インタフェースとオペレーションインタフェースを実装します。

Portable Object Adapter (POA) の PortableServer モジュールは、ネイティブ Servant 型を定義します。Java プログラミング言語では、 Servant 型は、Java org.omg.PortableServer.Servant クラスにマップされます。これはすべての (POA) サーバント実装の基底クラスとして機能し、アプリケーション開発者が呼び出せる 多数のメソッドを提供します。また、POA 自体が呼び出したり、サーバント動作を 制御するためにユーザが上書きしたりできるメソッドも提供します。

継承モデルには、旧バージョンの Java プログラミング言語 (J2SE 1.4 より前) と互換性のあるサーバ側バインディングを生成するために -oldImplBase フラグを使用するというオプションもあります。下位互換を維持したサーバ側 バインディングを生成するには、次のように指定します。

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

My.idl 内でインタフェース My が定義されていると、ファイル _MyImpleBase.java が生成されます。ユーザは、 My に対してその実装を提供する必要があります。この実証は、 _MyImplBase
 から継承しなければなりません。

もう一方のサーバ側モデルは、Tie モデルと呼ばれます。これは、 委譲モデルです。Tie モデルは Tie とスケルトンを同時には生成 できないため、これらは別々に生成する必要があります。次のコ マンドは、Tie モデルに対してバインディングを生成します。

    idlj -fall My.idl
    idlj -fallTIE My.idl

インタフェース My の場合、2 つめのコマンドは MyPOATie.java
 を生成します。 MyPOATie のコンストラクタは、delegate を受け取ります。ユーザは、delegate に対して実装を提供する必要があります。ただし、インタフェース MyOperations を継承すればよく、ほかのクラスから継承する必要はありません。 しかし、この実装を ORB と共に使用するには、 MyPOATie 内に実装をラップする必要があります。例を示します。

    MyImpl myImpl = new MyImpl ();
    My POATie tie = new MyPOATie (myImpl);
    orb.connect (tie);

実装をほかの実装から継承しなければならない場合は、標準の継承モデル の代わりに Tie モデルを使用することもできます。Java は任意の数の インタフェース継承を認めていますが、クラスの継承に使用できる スロットは 1 つだけです。継承モデルを使用すると、このスロットが占 有されます。Tie モデルを使用すると、スロットをユーザ自身の使用の ために解放できます。ただし、一定レベルの間接参照を引き起こすと いう欠点があります。つまり、メソッドを呼び出すと、余分なメソッド呼 び出しが 1 つ発生します。

1.4 よりも前の J2SE バージョンで旧バージョンの IDL-to-Java 言語 マッピングと互換性があるサーバ側の Tie モデルバインディングを生成 するには、次のように指定します。

    idlj -oldImplBase -fall My.idl
    idlj -oldImplBase -fallTIE My.idl

インタフェース My の場合、このコマンドは My_Tie.java を生成します。 My_Tie のコンストラクタは、 impl を受け取ります。ユーザは、 impl に対して実装を提供する必要があります。ただし、インタフェース HelloOperations を継承すればよく、ほかのクラスから継承する必要はありません。 しかし、この実装を ORB と共に使用するには、 My_Tie
 内に実装をラップする必要があります。例を示します。

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

発行されたファイルの代替場所の指定
発行されたファイルを現在のディレクトリ以外のディレクトリに保存したい場合は、 次のようにコンパイラを呼び出してください。

    idlj -td /altdir My.idl

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

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

    idlj -i /includes My.idl

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

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

この形式でファイルを取り込むと、コマンドが非常に長くなることがあります。 このため、インクルードファイルの検索場所をコンパイラに知らせる方法が 別に用意されています。この方法は、環境変数の概念に似ています。まず、 CLASSPATH にリストされているディレクトリ内に、 idl.config という名前のファイルを作成します。そして、 idl.config 内に次の形式の行を 1 つ作成します。

    includes=/includes;/moreIncludes

コンパイラはこのファイルを見つけ、インクルードリストに読み込みます。 この例では 2 つのディレクトリ間の区切り文字はセミコロン (;) であること に注意してください。この区切り文字は、NT ではセミコロン、Solaris では コロンというようにプラットフォームによって異なります。インクルードの詳 細は、CLASSPATH (Solaris)、CLASSPATH (Linux)、CLASSPATH (Windows) のドキュメントを参照してください。

インクルードファイルに対するバインディングの発行
デフォルトでは、コマンド行 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 ) 内に定義されているすべてのタイプを生成するには、 次のコマンドを使用してください。

    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 ファイルのリストが生成されます。

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

上記の例で -emitAll フラグが使用されていた場合は、すべてのインクルードファイル内に 定義されているすべてのタイプが発行されます。

パッケージ接頭辞の挿入
あなたが次の IDL ファイルを作成した ABC という名の企業に勤務していると 仮定してください。

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

このファイルに対して IDL-to-Java コンパイラを実行すると、パッケージ Widgets 内の W1 と W2 に対して Java バインディングが生成されます。 しかし、業界規約では、企業のパッケージは com.<companyname> という名前のパッケージ内に配置しなければならないと規定されています。 そのため、この Widgets パッケージのままでは不十分です。規定に従うには、 com.abc.Widgets でなければなりません。 Widgets モジュールにこのパッケージ接頭辞を配置するには、次のコマンドを 実行してください。

    idlj -pkgPrefix Widgets com.abc Widgets.idl

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

接頭辞を必要とするこれらのパッケージが多数存在する場合は、前述した idl.config ファイルに配置する方が簡単でしょう。各パッケージ接頭辞行は、次の書式で記述します。

    PkgPrefix.<type>=<prefix>

この書式に従うと、上記例の行は次のようになります。

    PkgPrefix.Widgets=com.abc

このオプションを使用しても、リポジトリ ID には影響を与えません。

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

    idlj -d MYDEF My.idl

My.idl 内に #define MYDEF という行を含めるのに同じです。

既存のバインディングの保持
Java バインディングファイルが既に存在する場合は、 -keep フラグを使用してコンパイラによる上書きを防止できます。デフォルトでは、 既に存在するかどうかにかかわらずすべてのファイルが生成されます。 ファイルをカスタマイズ (カスタマイズはその内容がよほど適切でない限り推奨 されません) してある場合は、 -keep オプションが非常に役立ちます。次のコマンドは、

    idlj -keep My.idl

まだ存在していないすべてのクライアント側バインディングを発行します。

コンパイルの進捗の表示
IDL-to-Java コンパイラは、その実行段階でステータスメッセージを 生成します。この生成を詳細 (verbose) モードにするには、 -v オプションを使用してください。

    idlj -v My.idl

デフォルトでは、コンパイラは詳細モードで動作しません。

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

    idlj -version

コンパイラが生成したバインディング内に、バージョン情報も表示されます。 コマンド行に指定されるその他のオプションは無視されます。

オプション

-d symbol
    これは、IDL ファイルに次の行を指定するのと同じです。

    #define symbol

-emitAll
    #include ファイル内に指定されているものも含め、すべてのタイプを発行します。

-fside
    発行するバインディングを定義します。 side には、 client 、 server 、 serverTIE 、 all 、 allTIE のうちいずれか 1 つを指定します。 -fserverTIE と -fallTIE オプションを指定すると、委譲モデルスケルトンが発行されます。 フラグを指定しない場合は、 -fclient と見なされます。

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

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

-noWarn
    警告メッセージを表示しないようにします。

-oldImplBase
    古い JDK ORB (1.4 より前) と互換性のあるスケルトンを生成します。 デフォルトでは、POA 継承モデルのサーバ側バインディングが生成されます。 このオプションは、 ImplBase 継承モデルクラスであるサーバ側バインディングを生成することによって、 旧バージョンの Java プログラミング言語との下位互換性を提供します。

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

-pkgTranslate type package
    このオプションは、 type またはモジュール名 type が見つかるたびに、生成される Java パッケージ内のすべてのファイルについて、 type を package に置き換えます。 pkgPrefix 変更が初めに行われることに注意してください。 type はトップレベルモジュールの単純名か、モジュールの外部で定義された IDL タイプの 単純名のいずれかであり、パッケージのフルネームと正確に一致する必要があります。 また、以下のパッケージ名は変換できません。

    • org

    • org.omg または org.omg のサブパッケージ

    これらのパッケージの変換を試みると、コンパイル不可能なコードが生成されます。 これらのパッケージを -pkgTranslate の後の最初の引数として使用すると、エラーとして扱われます。

-skeletonName xxx%yyy
    xxx%yyy をスケルトンの名前付けのパターンとして使用します。デフォルトは次のとおりです。

    • POA 基底クラス (
        -fserver または -fall ) の場合、%POA

    •   -oldImplBase クラス ( -oldImplBase および、 -fserver または -fall ) の場合、_%ImplBase

-td dir
    出力ディレクトリとして、現在のディレクトリではなく dir を使用します。

-tieName xxx%yyy
    パターンに応じて Tie に名前を付けます。デフォルトは次のとおりです。

    • POA Tie 基底クラス (
        -fserverTie または -fallTie ) の場合、%POATie

    •   oldImplBase クラス ( -oldImplBase および、 -fserverTie または -fallTie のいずれか) の場合、%_Tie

-nowarn,-verbose
    詳細モードにします。

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

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

制限事項

• グローバルスコープ内でエスケープされた識別子は、
    IDL プリミティブ型 ( Object または ValueBase ) と同じスペルであってはなりません。これは、シンボルテーブルがこれらの 識別子を使用してすでにロードされているためです。これらを定義し直すと、 それらの本来の定義を上書きすることになります (この制限は永続的に 適用される見込み)。

• IDL の fixed 型はサポートされていません。

既知の問題
現時点ではありません。