sourCEntral - mobile manpages

pdf

idlj

名前

idlj - IDL-to-Java コンパイラ

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 Language Mapping Specification
(http://java.sun.com/javase/6/docs/technotes/guides/idl/mapping/jidlMapping.html) を参照してください。 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 種類を 利用できます。

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

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

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

継承モデルには、J2SE 1.4 より前のバージョンの Java プログラミング言語 と互換性のあるサーバ側バインディングを生成するために -oldImplBase フラグを使用するというオプションもあります。 −oldImplBase フラグの使用は非標準であることに注意してください。これらの API はまもなく非推奨となります。このフラグを使用するのは、J2SE 1.3 で記述された既存のサーバとの互換性を確保する必要がある場合だけにしてください。その場合、既存の MAKEFILE を変更し、−oldImplBase フラグを idlj コンパイラに追加する必要があります。そうしないと、POA ベースのサーバ側マッピングが生成されてしまいます。 下位互換を維持したサーバ側 バインディングを生成するには、次のように指定します。

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 を受け取ります。 この例ではデフォルトの POA モデルを使用しているので、コンストラクタは poa も必要とします。 ユーザは、delegate に対して実装を提供する必要があります。ただし、インタフェース MyOperations を継承すればよく、ほかのクラスから継承する必要はありません。 しかし、この実装を ORB と共に使用するには、 MyPOATie 内に実装をラップする必要があります。例を示します。
ORB orb = ORB.init(args, System.getProperties());

// rootpoa への参照を取得し、POAManager を有効にします
POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
rootpoa.the_POAManager().activate();

// サーバントを作成し、それを ORB に登録します
MyServant myDelegate = new MyServant();
myDelegate.setORB(orb);

// Tie を作成します。サーバントが delegate になります。
MyPOATie tie = new MyPOATie(myDelegate, rootpoa);

// Tie の objectRef を取得します
My ref = tie._this(orb);

実装をほかの実装から継承しなければならない場合は、標準の継承モデル の代わりに 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
内に実装をラップする必要があります。例を示します。

ORB orb = ORB.init(args, System.getProperties());

// サーバントを作成し、それを ORB に登録します
MyServant myDelegate = new MyServant();
myDelegate.setORB(orb);

// Tie を作成します。サーバントが delegate になります。
MyPOATie tie = new MyPOATie(myDelegate);

// Tie の objectRef を取得します
My ref = tie._this(orb);

発行されたファイルの代替場所の指定

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

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 つのディレクトリ間の区切り文字はセミコロン (;) であること に注意してください。 この区切り文字はプラットフォームによって異なります。Windows プラットフォームではセミコロンを使用し、UNIX プラットフォームではコロンを使用する、などのようになります。 インクルードの詳 細は、 CLASSPATH のドキュメント (Solaris:
http://java.sun.com/javase/6/docs/technotes/tools/solaris/classpath.html) (Windows:
http://java.sun.com/javase/6/docs/technotes/tools/windows/classpath.html) を参照してください。

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

デフォルトでは、コマンド行 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 ファイルのリストが生成されます。

./MyHolder.java
./MyHelper.java
./_MyStub.java
./MyPackage
./MyPackage/EHolder.java
./MyPackage/EHelper.java
./MyPackage/E.java
./My.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 には、 clientserverserverTIEallallTIE のうちいずれか 1 つを指定します。 -fserverTIE-fallTIE オプションを指定すると、委譲モデルスケルトンが発行されます。 フラグを指定しない場合は、 -fclient と見なされます。

−i include-path

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

−keep

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

−noWarn

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

−oldImplBase

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

−pkgPrefix type prefix

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

−pkgTranslate type package

特定の識別子内でモジュール名 type が見つかった場合、生成された Java パッケージ内のすべてのファイルに対して、その識別子内のモジュール名を package で置き換えます。 pkgPrefix 変更が初めに行われることに注意してください。 type はトップレベルモジュールの単純名か、モジュールの外部で定義された IDL タイプの 単純名のいずれかであり、パッケージのフルネームと正確に一致する必要があります。

特定の識別子に一致する変換が 2 つ以上見つかった場合、もっとも長い一致が選択されます。たとえば、引数を次のように指定したとします。
−pkgTranslate foo bar −pkgTranslate foo.baz buzz.fizz

このとき、次の変換が実行されます。
foo => bar
foo.boo => bar.boo
foo.baz => buzz.fizz
foo.baz.bar => buzz.fizz.bar

次のパッケージ名は変換できません。

*

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

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

−nowarn,−verbose

詳細モードにします。

−version

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

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

制限事項


グローバルスコープ内でエスケープされた識別子は、

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

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

既知の問題

*

グローバル識別子のインポートは生成されません。エクスポートされていないローカル実装を呼び出すと例外が発生しますが、その原因はおそらく ServerDelegate DSI コード内の NullPointerException です。

pdf