." DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

."

." This code is free software; you can redistribute it and/or modify it

." under the terms of the GNU General Public License version 2 only, as

." published by the Free Software Foundation.

."

." This code is distributed in the hope that it will be useful, but WITHOUT

." ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

." FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

." version 2 for more details (a copy is included in the LICENSE file that

." accompanied this code).

."

." You should have received a copy of the GNU General Public License version

." 2 along with this work; if not, write to the Free Software Foundation,

." Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

."

." Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

." or visit www.oracle.com if you need additional information or have any

." questions.

."

.LP

.SH "名前"

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

.LP

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

.SH "形式"

.LP

.nf

\f3

.fl

idlj [ \fP\f3options\fP\f3 ] \fP\f4idl\-file\fP\f3

.fl

\fP

.fi

.LP

.LP

\f2idl\-file\fP は、インタフェース定義言語 (IDL) による定義が入ったファイルの名前です。\f2options\fP の順番は任意ですが、\f2idl\-file\fP よりも前に指定しなければなりません。

.LP

.SH "説明"

.LP

.LP

IDL\-to\-Java コンパイラは、指定された IDL ファイルについて Java バインディングを生成します。バインディングの詳細は、

.na

\f2OMG IDL to Java Language Mapping Specification\fP @

.fi

http://java.sun.com/javase/6/docs/technotes/guides/idl/mapping/jidlMapping.html を参照してください。IDL\-to\-Java コンパイラの以前のリリースの中には、\f2idltojava\fP という名前だったものがあります。

.LP

.SS 

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

.LP

.LP

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

.LP

.nf

\f3

.fl

idlj My.idl

.fl

\fP

.fi

.LP

.LP

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

.LP

.nf

\f3

.fl

idlj \fP\f3\-fclient\fP My.idl

.fl

.fi

.LP

.LP

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

.LP

.nf

\f3

.fl

idlj \fP\f3\-fserver\fP My.idl

.fl

.fi

.LP

.LP

サーバー側のバインディングには、クライアント側のバインディングのほかに、スケルトンも含まれています。これらはすべて、 \f2POA\fP (つまり継承モデル) クラスです。クライアント側とサーバー側の両方のバインディングを生成する場合は、次のコマンド (どれも等価) のうちの 1 つを使用します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-fclient \-fserver\fP My.idl

.fl

idlj \f3\-fall\fP My.idl

.fl

.fi

.LP

.LP

サーバー側で可能なモデルは 2 つあります。継承モデルと Tie 委譲モデルです。

.LP

.LP

デフォルトのサーバー側のモデルは、「移殖可能サーバント継承モデル」です。\f2My.idl\fP 内で \f2My\fP インタフェースが定義されている場合は、\f2MyPOA.java\fP というファイルが生成されます。この実装は \f2My\fP に提供し、\f2MyPOA\fP を継承する必要があります。

.LP

.LP

\f2MyPOA.java\fP は 

.na

\f2org.omg.PortableServer.Servant\fP @

.fi

http://java.sun.com/javase/6/docs/api/org/omg/PortableServer/Servant.html を拡張するストリームベースのスケルトンで、スケルトンが実装する IDL インタフェースに関連付けられている \f2InvokeHandler\fP インタフェースとオペレーションインタフェースを実装します。

.LP

.LP

.na

\f2Portable Object Adapter (POA)\fP @

.fi

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 そのものによって呼び出され、サーバントの動作を制御するためにユーザーがオーバーライドできるメソッドも提供します。

.LP

.LP

継承モデルのもう 1 つのオプションは、\f2\-oldImplBase\fP フラグを使用することで、J2SE 1.4 より前のバージョンの Java プログラミング言語と互換性のあるサーバー側バインディングを生成することです。ただし、\f2\-oldImplBase\fP フラグを使用するのは、標準的な手法ではありません。これらの API は今後非推奨になる予定です。このフラグを使用するのは、J2SE 1.3 で記述された既存のサーバーとの互換性が必要な場合だけです。その場合には既存の MAKEFILE を変更し、\f2idlj\fP コンパイラに \f2\-oldImplBase\fP フラグを追加する必要があります。そうしないと、POA ベースのサーバー側マッピングが生成されます。下位互換性のあるサーバー側バインディングを生成するには、次のコマンドを使用します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-fclient \-fserver\fP \f3\-oldImplBase\fP My.idl

.fl

idlj \f3\-fall\fP \f3\-oldImplBase\fP My.idl

.fl

.fi

.LP

.LP

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

.LP

.LP

もう 1 つのサーバー側モデルは、Tie モデルと呼ばれるものです。このサーバー側モデルは、委譲モデルです。Tie とスケルトンを同時に生成することはできないため、それらは別々に生成しなければなりません。次のコマンドによって、Tie モデル用のバインディングが生成されます。

.LP

.nf

\f3

.fl

idlj \fP\f3\-fall\fP My.idl

.fl

idlj \f3\-fallTIE\fP My.idl

.fl

.fi

.LP

.LP

\f2My\fP というインタフェースの場合、上記の 2 番目のコマンドにより、\f2MyPOATie.java\fP が生成されます。\f2MyPOATie\fP のコンストラクタは、\f2delegate\fP を取ります。この例では、デフォルトの POA モデルを使用しているため、コンストラクタにも \f2poa\fP が必要です。\f2delegate\fP に対して実装を提供しなければなりませんが、この実装は \f2MyOperations\fP インタフェースから継承する必要があるだけで、その他のクラスから継承する必要はありません。しかし、この実装を ORB と一緒に使用するには、\f2MyPOATie\fP 内で実装をラップしなければなりません。たとえば、次のようにします。

.LP

.nf

\f3

.fl

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

.fl

.fl

    // Get reference to rootpoa & activate the POAManager

.fl

    POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");

.fl

    rootpoa.the_POAManager().activate();

.fl

.fl

    // create servant and register it with the ORB

.fl

    MyServant myDelegate = new MyServant();

.fl

    myDelegate.setORB(orb); 

.fl

.fl

    // create a tie, with servant being the delegate.

.fl

    MyPOATie tie = new MyPOATie(myDelegate, rootpoa);

.fl

.fl

    // obtain the objectRef for the tie

.fl

    My ref = tie._this(orb);

.fl

\fP

.fi

.LP

.LP

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

.LP

.LP

IDL のバージョンから J2SE 1.4 より前のバージョンの Java 言語へのマッピングと互換性のある、サーバー側の Tie モデルのバインディングを生成するには、次のコマンドを使用します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-oldImplBase\fP \f3\-fall\fP My.idl

.fl

idlj \f3\-oldImplBase\fP \f3\-fallTIE\fP My.idl

.fl

.fi

.LP

.LP

\f2My\fP というインタフェースの場合、これにより \f2My_Tie.java\fP が生成されます。\f2My_Tie\fP のコンストラクタは、\f2impl\fP を取ります。\f2impl\fP に対して実装を提供しなければなりませんが、その実装は \f2HelloOperations\fP インタフェースから継承する必要があるだけで、その他のクラスから継承する必要はありません。しかし、この実装を ORB と一緒に使用するには、\f2My_Tie\fP 内で実装をラップしなければなりません。たとえば、次のようにします。

.LP

.nf

\f3

.fl

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

.fl

.fl

    // create servant and register it with the ORB

.fl

    MyServant myDelegate = new MyServant();

.fl

    myDelegate.setORB(orb); 

.fl

.fl

    // create a tie, with servant being the delegate.

.fl

    MyPOATie tie = new MyPOATie(myDelegate);

.fl

.fl

    // obtain the objectRef for the tie

.fl

    My ref = tie._this(orb);

.fl

\fP

.fi

.LP

.SS 

発行されたファイルの代替位置の指定

.LP

.LP

発行されたファイルをカレントディレクトリ以外のディレクトリに置くには、次のようなコマンドでコンパイラを呼び出します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-td /altdir\fP My.idl

.fl

.fi

.LP

.LP

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

.LP

.SS 

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

.LP

.LP

\f2My.idl\fP にもう 1 つの IDL ファイル \f2MyOther.idl\fP がインクルードされている場合、コンパイラは、ローカルディレクトリに \f2MyOther.idl\fP があるものと想定します。もしそのファイルが、たとえば \f2/includes\fP にある場合は、次のようなコマンドでコンパイラを呼び出します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-i /includes\fP My.idl

.fl

.fi

.LP

.LP

また、もし \f2My.idl\fP に、たとえば \f2/moreIncludes\fP にある \f2Another.idl\fP もインクルードされているのであれば、次のようなコマンドでコンパイラを呼び出します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-i /includes \-i /moreIncludes\fP My.idl

.fl

.fi

.LP

.LP

このような形式でインクルードを指定すると、コマンドが長くて複雑になります。そこで、インクルードファイルを検索する場所をコンパイラに指示するための別の方法が用意されています。この方法は、環境変数の考え方と似ています。CLASSPATH にリストされているディレクトリ内に \f2idl.config\fP という名前のファイルを作成します。その \f2idl.config\fP の中に、次のような形式の行を入れます。

.LP

.nf

\f3

.fl

includes=/includes;/moreIncludes

.fl

\fP

.fi

.LP

.LP

コンパイラは、このファイルを検索し、インクルードリストを読み込みます。この例では、ディレクトリの間の区切り文字はセミコロン (;) になっています。この区切り文字は、プラットフォームによって異なります。たとえば、Windows プラットフォームではセミコロンですが、Unix プラットフォームではコロンです。 \f2インクルード\fPの詳細については、

.na

\f2CLASSPATH の設定\fP @

.fi

http://java.sun.com/javase/6/docs/technotes/tools/index.html#general を参照してください。

.LP

.SS 

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

.LP

.LP

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

.LP

.LP

.LP

\f4My.idl\fP

.LP

.nf

\f3

.fl

#include <MyOther.idl>

.fl

interface My

.fl

{

.fl

};

.fl

\fP

.fi

.LP

.LP

.LP

\f4MyOther.idl\fP

.LP

.nf

\f3

.fl

interface MyOther

.fl

{

.fl

};

.fl

\fP

.fi

.LP

.LP

.LP

次のコマンドでは、\f2My\fP に対する Java バインディングだけが生成されます。

.LP

.nf

\f3

.fl

idlj My.idl

.fl

\fP

.fi

.LP

.LP

\f2My.idl\fP で定義されている型と、\f2My.idl\fP にインクルードされたファイル (この例では \f2MyOther.idl\fP) で定義されている型すべてについて Java バインディングを生成するには、次のコマンドを使用します。

.LP

.nf

\f3

.fl

idlj \fP\f3\-emitAll\fP My.idl

.fl

.fi

.LP

.LP

このデフォルトの規則に関して注意しなければならないことがあります。グローバルスコープに指定した \f2#include\fP 文は、前述のとおりに処理されます。これらの \f2#include\fP 文は、インポート文と見なすことができます。それに対して、他の定義に囲まれたスコープ内に指定した \f2#include\fP 文は、本当の意味での \f2#include\fP 文として処理されます。つまり、インクルードされたファイルにあるコードが、元のファイルにそのまま指定されているかのように処理され、それに対して Java バインディングが発行されます。次はその例です。

.LP

.LP

.LP

\f4My.idl\fP

.LP

.nf

\f3

.fl

#include <MyOther.idl>

.fl

interface My

.fl

{

.fl

  #include <Embedded.idl>

.fl

};

.fl

\fP

.fi

.LP

.LP

.LP

\f4MyOther.idl\fP

.LP

.nf

\f3

.fl

interface MyOther

.fl

{

.fl

};

.fl

\fP

.fi

.LP

.LP

.LP

\f4Embedded.idl\fP

.LP

.nf

\f3

.fl

enum E {one, two, three};

.fl

\fP

.fi

.LP

.LP

.LP

このとき、次のコマンドを実行すると、

.LP

.nf

\f3

.fl

idlj My.idl

.fl

\fP

.fi

.LP

.LP

次のような一連の Java ファイルが生成されます。

.LP

.nf

\f3

.fl

./MyHolder.java

.fl

./MyHelper.java

.fl

./_MyStub.java

.fl

./MyPackage

.fl

./MyPackage/EHolder.java

.fl

./MyPackage/EHelper.java

.fl

./MyPackage/E.java

.fl

./My.java

.fl

\fP

.fi

.LP

.LP

インポート文と見なされる \f2#include\fP に定義されているため、\f2MyOther.java\fP は生成されません。ただし、本当の意味での \f2#include\fP で定義されているため、\f2E.java\fP は生成されます。さらに、\f2Embedded.idl\fP が \f2My\fP インタフェースのスコープ内にインクルードされていたため、\f2My\fP のスコープ内 (つまり、\f2MyPackage\fP 内) に生成されています。

.LP

.LP

上記の例で \f2\-emitAll\fP フラグを使用すれば、インクルードされたすべてのファイルにあるすべての型が発行されます。

.LP

.SS 

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

.LP

.LP

ABC という名前の会社のために作業していて、次のような IDL ファイルを構築したとしましょう。

.LP

.LP

.LP

\f4Widgets.idl\fP

.LP

.nf

\f3

.fl

module Widgets

.fl

{

.fl

  interface W1 {...};

.fl

  interface W2 {...};

.fl

};