Last Change: 2018-09-07, 16:50
powered by manpag.es
idlj − 指定されたインタフェース定義言語(IDL)ファイルに対してJavaバインディングを生成します。
idlj [ options ] idlfile
options
コマンド行オプション。オプションを参照してください。optionsの順番は任意ですが、idlfileよりも前に指定する必要があります。
idlfile
インタフェース定義言語(IDL)による定義が含まれるファイルの名前。
IDL−to−Javaコンパイラは、指定されたIDLファイルに対してJavaバインディングを生成します。バインディングの詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping.htmlにある Java IDL: Java言語マッピングへのIDLを参照してください。
IDL−to−Javaコンパイラの以前のリリースの中には、idltojavaという名前だったものがあります。
クライアント・バインディングおよびサーバー・バインディングの発行
次のidljコマンドは、クライアント側バインディングを含むMy.idlという名前のIDLファイルを生成します。
idlj My.idl
前の構文は次と同等です。
idlj −fclient My.idl
次の例では、サーバー側バインディングを生成し、クライアント側バインディングおよびスケルトンを含めており、これらはすべて、POA (継承モデル)です。
idlg −fserver My.idl
クライアント側とサーバー側の両方のバインディングを生成する場合は、次のコマンド(どれも等価)のうちの1つを使用します。
idlj −fclient −fserver My.idl
idlj −fall My.idl
サーバー側で可能なモデルは2つあります。移殖可能サーバント継承モデルとTieモデルです。Tie委譲モデルを参照してください。
移殖可能サーバント継承モデル. デフォルトのサーバー側のモデルは、移殖可能サーバント継承モデルです。My.idl内でMyインタフェースが定義されている場合は、MyPOA.javaというファイルが生成されます。Myインタフェースの実装を提供する必要があり、MyインタフェースはMyPOAクラスから継承する必要があります。MyPOA.javaは、http://docs.oracle.com/javase/8/docs/api/org/omg/PortableServer/Servant.htmlにある org.omg.PortableServer.Servantクラスを拡張するストリームベースのスケルトンです。
Myインタフェースは、スケルトンが実装するIDLインタフェースに関連付けられているcallHandlerインタフェースと操作インタフェースを実装します。
ポータブル・オブジェクト・アダプタ(POA)のPortableServerモジュールは、ネイティブのServant型を定義します。http://docs.oracle.com/javase/8/docs/technotes/guides/idl/POA.htmlにある ポータブル・オブジェクト・アダプタ(POA)を参照してください。
Javaプログラミング言語では、Servant型はJavaのorg.omg.PortableServer.Servantクラスにマップされます。これは、すべてのPOAサーバント実装のベース・クラスとして機能し、アプリケーション・プログラマが呼び出すことのできるいくつかのメソッド、およびPOAによって呼び出され、サーバントの動作を制御するためにユーザーがオーバーライドできるメソッドを提供します。
継承モデルのもう1つのオプションは、−oldImplBaseフラグを使用して、Java SE 1.4より前のリリースのJavaプログラミング言語と互換性のあるサーバー側バインディングを生成することです。−oldImplBaseフラグは非標準で、これらのAPIは非推奨です。このフラグを使用するのは、Java SE 1.3で記述された既存のサーバーとの互換性が必要な場合のみです。その場合、既存のmakeファイルを変更して、−oldImplBaseフラグをidljコンパイラに追加する必要があります。それ以外の場合、POAベースのサーバー側マッピングが生成されます。後方互換性のあるサーバー側バインディングを生成するには、次を実行します。
idlj −fclient −fserver −oldImplBase My.idl
idlj −fall −oldImplBase My.idl
My.idl内でMyインタフェースが定義されている場合は、_MyImplBase.javaというファイルが生成されます。Myインタフェースの実装を提供する必要があり、Myインタフェースは_MyImplBaseクラスから継承する必要があります。
Tie委譲モデル. もう1つのサーバー側モデルは、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());
// Get reference to rootpoa & activate the POAManager
POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
rootpoa.the_POAManager().activate();
// create servant and register it with the ORB
MyServant myDelegate = new MyServant();
myDelegate.setORB(orb);
// create a tie, with servant being the delegate.
MyPOATie tie = new MyPOATie(myDelegate, rootpoa);
// obtain the objectRef for the tie
My ref = tie._this(orb);
他の実装から継承する必要がある場合、標準の継承モデルではなくTieモデルを使用することもできます。Javaの場合は、インタフェースの継承の個数に制限はありませんが、クラスの継承に使用できるスロットは1つのみです。継承モデルを使用した場合は、そのスロットが占有されます。Tieモデルを使用すると、そのスロットが使用されず、ユーザーが独自の目的で使用できます。この方法には、間接性のレベルが1つ導入されるという短所があります。メソッドを呼び出すときに、余分なメソッド呼出しが1回発生します。
サーバー側の生成の場合、Java SE 1.4より前のバージョンのJava言語にマッピングするIDLのバージョンと互換性のある、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());
// create servant and register it with the ORB
MyServant myDelegate = new MyServant();
myDelegate.setORB(orb);
// create a tie, with servant being the delegate.
MyPOATie tie = new MyPOATie(myDelegate);
// obtain the objectRef for the tie
My ref = tie._this(orb);
発行されたファイルの代替位置の指定
発行されたファイルを現在のディレクトリ以外のディレクトリに置くには、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
このような形式のincludeは長くなるため、インクルード・ファイルを検索する場所をコンパイラに指示するための別の方法が用意されています。この方法は、環境変数の考え方と似ています。CLASSPATH変数に一覧表示されているディレクトリ内にidl.configという名前のファイルを作成します。そのidl.configの中に、次のような形式の行を入れます。
includes=/includes;/moreIncludes
コンパイラは、このファイルを検索し、インクルード・リストを読み込みます。この例では、ディレクトリの間の区切り文字はセミコロン(;)になっています。この区切り文字は、プラットフォームによって異なります。Windowsプラットフォームではセミコロンを使用し、Solaris、LinuxおよびOS Xプラットフォームではコロンを使用します。
インクルード・ファイルに対するバインディングの発行
デフォルトでは、コマンド行に指定したidlファイルで定義されているインタフェースや構造体などについてのみ、Javaバインディングが生成されます。インクルードされたファイルで定義されている型については生成されません。たとえば、次の2つのidlファイルについて考えてみます。
My.idl file:
#include <MyOther.idl>
interface My
{
};
MyOther.idl file:
interface MyOther
{
};
デフォルトのルールに関して警告があります。グローバル・スコープに表示される#include文は、前述のとおりに処理されます。これらの#include文は、インポート文と見なすことができます。囲まれたスコープ内に表示される#include文は、本当の意味での#include文として処理されます。つまり、インクルードされたファイルにあるコードが、元のファイルにそのまま表示されているかのように処理され、それに対してJavaバインディングが発行されます。次はその例です。
My.idl file:
#include <MyOther.idl>
interface My
{
#include <Embedded.idl>
};
MyOther.idl file:
interface MyOther
{
};
Embedded.idl
enum E {one, two, three};
idlj My.idl を実行して、Javaファイルの次のリストを生成します。インポート文とみなされる#includeに定義されていたため、MyOther.javaは生成されませんでした。ただし、本当の意味での#includeで定義されていたため、E.javaは生成されました。Embedded.idlファイルがMyインタフェースのスコープ内にインクルードされているため、Myのスコープ内(つまり、MyPackage内)に生成されています。−emitAllフラグを使用した場合、インクルードされたすべてのファイルにあるすべての型が発行されます。
./MyHolder.java
./MyHelper.java
./_MyStub.java
./MyPackage
./MyPackage/EHolder.java
./MyPackage/EHelper.java
./MyPackage/E.java
./My.java
パッケージの接頭辞の挿入
ABCという名前の会社のために作業していて、次のようなIDLファイルを構築したとしましょう。
Widgets.idl file:
module Widgets
{
interface W1 {...};
interface W2 {...};
};
IDL−to−Javaコンパイラを介してこのファイルを実行した場合、W1およびW2に対するJavaバインディングは、Widgetsパッケージ内に格納されます。業界の慣例によると、会社のパッケージは、com.<company name>という名前のパッケージ内に置くことになっています。この慣例に従うには、パッケージ名を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コンパイラは、実行の各段階で状態メッセージを生成します。−vオプションを使用して、idlj −v My.idlのような冗長モードをアクティブ化します。
デフォルトでは、コンパイラは冗長モードでは実行されません。
バージョン情報の表示
IDL−to−Javaコンパイラのビルド・バージョンを表示するには、コマンド行idlj −versionで−versionオプションを指定します。
バージョン情報は、コンパイラによって生成されたバインディング内にも書き込まれています。このオプションをコマンド行に指定すると、それ以外のオプションを指定しても、すべて無視されます。
−d symbol
このオプションは、IDLファイルに次のような行を追加した場合と等価です。
#define symbol
−demitAll
#includeファイル内で定義されているものも含めて、すべての型を発行します。
−fside
発行するバインディングを定義します。sideパラメータには、client、server、serverTIE、allまたはallTIEを指定できます。−fserverTIEまたは−fallTIEオプションを指定すると、委譲モデル・スケルトンが発行されます。フラグを指定しない場合、−fclientにデフォルト設定されます。
−i include−path
デフォルトでは、インクルード・ファイルは現在のディレクトリから検索されます。このオプションを指定すると、他のディレクトリを追加できます。
−i 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型の単純名で、完全なパッケージ名に正確に一致する必要があります。
複数の変換が識別子に一致する場合、次の例に示すように、最も長い一致が選択されます。
コマンド:
pkgTranslate type pkg −pkgTranslate type2.baz pkg2.fizz
結果の変換:
type => pkg
type.ext => pkg.ext
type.baz => pkg2.fizz
type2.baz.pkg => pkg2.fizz.pkg
パッケージ名org、org.omg、またはorg.omgのサブパッケージは、変換できません。これらのパッケージ名を変換しようとすると、互換性のないコードが生成され、−pkgTranslateの後の最初の引数としてそれらのパッケージを使用すると、エラーとして扱われます。
−skeletonName xxx%yyy
xxx%yyyが、スケルトンに名前を付けるパターンとして使用されます。デフォルトは次のとおりです。POAベース・クラスの場合は%POA (−fserverまたは−fall)、oldImplBaseクラスの場合は_%ImplBase (−oldImplBase)および(−fserverまたは−fall))。
−td dir
出力ディレクトリとして、現在のディレクトリではなく、dirが使用されます。
−tieName xxx%yyy
パターンに従って、xxx%yyyを使用します。デフォルトは次のとおりです。POAベース・クラスの場合は%POA (−fserverTieまたは−fallTie)、oldImplBase tieクラスの場合は_%Tie (−oldImplBase)および(−fserverTieまたは−fallTie))。
−nowarn、−verbose
リリース情報を表示して終了します。
−version
リリース情報を表示して終了します。
グローバル・スコープ内のエスケープされた識別子は、IDLプリミティブ型のObjectまたはValueBaseと同じ綴りにしないでください。これは、シンボル表がこれらの識別子でプリロードされているためです。これらの再定義を許可すると、元の定義が上書きされます。これは、おそらく恒久的な制約です。
fixedというIDL型はサポートされていません。
グローバル識別子についてインポートが生成されません。予期されないローカルimplオブジェクトを呼び出すと、例外を受け取ります。しかし、その原因は、ServerDelegate DSIコード内のNullPointerExceptionにあるようです。