." Copyright 2001-2006 Sun Microsystems, Inc.  All Rights Reserved.

." 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 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,

." CA 95054 USA or visit www.sun.com if you need additional information or

." have any questions.

."

.TH idlj 1 "04 May 2009"

." Generated from HTML by html2man (author: Eric Armstrong)

.SH "名前"

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

.LP

.RS 3

.LP

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

.RE

.SH "形式"

.LP

.nf

\f3

.fl

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

.fl

\fP

.LP

.LP

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

.LP

.SH "説明"

.LP

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

.na

\f2OMG IDL to Java Language Mapping Specification\fP @

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

.SS 

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

.RS 3

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

これにより、クライアント側のバインディングが生成されます。 このコマンドは、次のコマンドと等価です。 \f2idlj \fP\f4\-fclient\fP\f2 My.idl\fP

.LP

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

サーバー側のバインディングには、クライアント側のバインディングに加えて、スケルトンが組み込まれてています。 これらは、すべて \f2POA\fP (継承モデル) クラスです。クライアント側とサーバー側の両方のバインディングを生成する場合は、次のコマンド (どれも等価) のうちの 1 つを使用します。 \f2idlj \fP\f4\-fclient \-fserver\fP\f2 My.idl\fP

.br

\f2idlj \fP\f4\-fall\fP\f2 My.idl\fP

.LP

サーバー側のモデルとしては、2 つのモデルが可能です。それは、継承モデルと、Tie 委譲モデルです。

.LP

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

\f2MyPOA.java\fP は 

\f2org.omg.PortableServer.Servant\fP @

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

.LP

\f2Portable Object Adapter (POA)\fP @

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 自身からも呼び出され、場合によってはサーバントの動作を制御するためにユーザーがオーバーライドすることもあります。

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

\f2idlj \fP\f4\-fclient \-fserver\fP\f2 \fP\f4\-oldImplBase\fP\f2 My.idl\fP

\f2idlj \fP\f4\-fall\fP\f2 \fP\f4\-oldImplBase\fP\f2 My.idl\fP

.LP

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

.LP

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

\f2idlj \fP\f4\-fall\fP\f2 My.idl\fP

.br

\f2idlj \fP\f4\-fallTIE\fP\f2 My.idl\fP

.LP

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

    // Get reference to rootpoa & activate the POAManager

    // create servant and register it with the ORB

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

    // obtain the objectRef for the tie

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

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

\f2idlj \fP\f4\-oldImplBase\fP\f2 \fP\f4\-fall\fP\f2 My.idl\fP

\f2idlj \fP\f4\-oldImplBase\fP\f2 \fP\f4\-fallTIE\fP\f2 My.idl\fP

.LP

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

    // create servant and register it with the ORB

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

    // obtain the objectRef for the tie

.SS 

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

.RS 3

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

.RS 3

\f2idlj \fP\f4\-td /altdir\fP\f2 My.idl\fP

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

.SS 

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

.RS 3

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

.LP

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

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

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

.na

\f2CLASSPATH の設定\fP @

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

.SS 

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

.RS 3

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

.LP

\f2#include <MyOther.idl>\fP

\f2interface My\fP

\f2{\fP

\f2};\fP

\f4MyOther.idl\fP 

\f2interface MyOther\fP

\f2{\fP

\f2};\fP\  

.LP

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

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

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

\f2#include <MyOther.idl>\fP

.br

\f2interface My\fP

.br

\f2{\fP

.br

\f2\  #include <Embedded.idl>\fP

.br

\f2};\ \fP  \f4MyOther.idl\fP

\f2interface MyOther\fP

.br

\f2{\fP

.br

\f2};\ \fP  \f4Embedded.idl\fP

\f2enum E {one, two, three};\fP\  

このとき、次のコマンドを実行すると、 \f2idlj My.idl\fP

次のような一連の Java ファイルが生成されます。 \f2./MyHolder.java\fP

.br

\f2./MyHelper.java\fP

.br

\f2./_MyStub.java\fP

.br

\f2./MyPackage\fP

.br

\f2./MyPackage/EHolder.java\fP

.br

\f2./MyPackage/EHelper.java\fP

.br

\f2./MyPackage/E.java\fP

.br

\f2./My.java\fP

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

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

.LP

.SS 

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

.LP

.RS 3

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

.br

\f4Widgets.idl\fP 

.LP

\f2module Widgets\fP

.br

\f2{\fP

.br

\f2\  interface W1 {...};\fP

.br

\f2\  interface W2 {...};\fP

.br

\f2};\fP\  

.LP

このファイルに対して IDL\-to\-Java コンパイラを実行すると、\f2W1\fP および \f2W2\fP に対する Java バインディングが \f2Widgets\fP パッケージ内に生成されます。しかし、業界の慣例によると、会社のパッケージは、\f2com.<会社名>\fP という名前のパッケージ内に置くことになっています。そのため、\f2Widgets\fP パッケージでは不十分です。慣例に従うには、パッケージを \f2com.abc.Widgets\fP にする必要があります。このパッケージ接頭辞を \f2Widgets\fP モジュールに付加するには、次のコマンドを実行します。 \f2idlj \fP\f4\-pkgPrefix Widgets com.abc\fP\f2 Widgets.idl\fP

.LP

\f2Widgets.idl\fP をインクルードしている IDL ファイルがある場合は、そのコマンドにも \f2\-pkgPrefix\fP フラグが必要です。このフラグを指定しないと、その IDL ファイルは、\f2com.abc.Widgets\fP パッケージではなく、\f2Widgets\fP パッケージを検索することになります。 

.LP

接頭辞が必要なパッケージがいくつもある場合は、前述の \f2idl.config\fP ファイルで接頭辞を指定するのが簡単です。パッケージの接頭辞を指定する行は、それぞれ次の形式で記述します。

.LP

\f2PkgPrefix.<type>=<prefix>\fP

.LP

したがって、上記の例の場合は、次のように記述します。  \f2PkgPrefix.Widgets=com.abc\fP

.LP

.LP

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

.LP

.RE

.SS 

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

.LP

.RS 3

.LP

コンパイル用のシンボルが IDL ファイル内で定義されていない場合は、そのシンボルを定義する必要があります。 これは、たとえば、バインディング内にデバッグコードを組み入れるときに使用します。次のコマンドは、 \f2idlj \fP\f4\-d\fP\f2 MYDEF My.idl\fP

.LP

\f2My.idl\fP 内に \f2#define MYDEF\fP という行を指定した場合と等価です。

.RE

.SS 

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

.LP

.RS 3

.LP

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

.LP

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

.RE

.SS 

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

.LP

.RS 3

.LP

IDL\-to\-Java コンパイラは、実行の各段階で状態メッセージを生成します。「冗長」モード (メッセージが多いモード) にするには、\f2\-v\fP オプションを使用します。 \f2idlj \fP\f4\-v\fP\f2 My.idl\fP

.LP

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

.RE

.SS 

バージョン情報の表示

.LP

.RS 3

.LP

.LP

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

.LP

.LP

\f2idlj \-version\fP

.LP

.LP

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

.LP

.RE

.SH "オプション"

.LP

.LP

.RS 3

.TP 3

\-d symbol 

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

.RS 3

.LP

.nf

\f3

.fl

#define \fP\f4symbol\fP\f3

.fl

\fP

.fi

.RE

.TP 3

\-emitAll 

\f2#include\fP ファイル内で定義されているものも含めて、すべての型を発行します。 

.TP 3

\-fside 

発行するバインディングを定義します。 \f2side\fP は、\f2client\fP、\f2server\fP、\f2serverTIE\fP、\f2all\fP、\f2allTIE\fP のどちらかです。\f2\-fserverTIE\fP または \f2\-fallTIE\fP オプションを指定すると、委譲モデルスケルトンが発行されます。このフラグを指定しなかった場合は、\f2\-fclient\fP が指定されたものと見なされます。 

.TP 3

\-i include\-path 

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

.TP 3

\-keep 

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

.TP 3

\-noWarn 

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

.TP 3

\-oldImplBase 

v1.4 より前の JDK ORB と互換性のあるスケルトンを生成します。デフォルトでは、POA 継承モデルのサーバー側バインディングが生成されます。このオプションを指定すると、\f2ImplBase\fP 継承モデルのクラスであるサーバー側バインディングが生成されるので、古いバージョンの Java プログラミング言語との下位互換性が得られます。 

.TP 3

\-pkgPrefix type prefix 

\f2type\fP がファイルスコープで検出された場合は、その型に対して生成されるすべてのファイルについて、生成される Java パッケージ名に \f2prefix\fP という接頭辞が付加されます。\f2type\fP は、トップレベルモジュールの単純名か、どのモジュールよりも外側で定義された IDL 型の単純名のどちらかです。 

.TP 3

\-pkgTranslate type package 

識別子の中にモジュール名 \f2type\fP が検出されると、生成される Java パッケージ内のすべてのファイルについて、識別子の中のその名前が \f2package\fP で置き換えられます。最初に \f2pkgPrefix\fP を変更します。\f2type\fP は、トップレベルのモジュール、またはすべてのモジュールの外部で定義された IDL 型の単純名です。 そして、完全なパッケージ名に正確に一致しなければなりません。 

.LP

1 つの識別子の中で複数の変換がマッチする場合は、もっとも長いマッチが選ばれます。たとえば、次のような引数が指定されている場合は、 

次のような変換が実施されます。 

次のパッケージ名を変換することはできません。 

o

o

\f2org.omg\fP、または \f2org.omg\fP のサブパッケージ 

これらのパッケージ名を変換しようとすると、互換性のないコードが生成されます。 そして、\f2\-pkgTranslate\fP のあとの最初の引数としてそれらのパッケージを使用すると、エラーとして扱われます。  

.TP 3

\-skeletonName xxx%yyy 

\f2xxx%yyy\fP が、スケルトンに名前を付けるパターンとして使用されます。デフォルトは、次のとおりです。 

.RS 3

o

\f2POA\fP 基底クラスの場合は「%POA」(\f2\-fserver\fP または \f2\-fall\fP) 

o

\f2oldImplBase\fP クラスの場合は「_%ImplBase」(\f2\-oldImplBase\fP かつ (\f2\-fserver\fP または \f2\-fall\fP)) 

.TP 3

\-td dir 

出力ディレクトリとして、カレントディレクトリではなく、\f2dir\fP が使用されます。 

.TP 3

\-tieName xxx%yyy 

このパターンに従って Tie に名前が付けられます。デフォルトは、次のとおりです。 

.RS 3

.TP 2

o

\f2POA\fP Tie 基底クラスの場合は「%POATie」(\f2\-fserverTie\fP または \f2\-fallTie\fP) 

o

\f2oldImplBase\fP Tie クラスの場合は「%_Tie」(\f2\-oldImplBase\fP かつ (\f2\-fserverTie\fP または \f2\-fallTie\fP)) 

.RE

.TP 3

\-verbose 

冗長モードになります。 

.TP 3

\-version 

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

.RE

.LP

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

.SH "制約"

o

グローバルスコープ内のエスケープされた識別子は、IDL プリミティブ型の \f2Object\fP または \f2ValueBase\fP と同じ綴りであってはなりません。これらの識別子については、シンボルテーブルが事前にロードされており、これらの識別子の再定義を許可すると元の定義が上書きされてしまいます。これは、おそらく恒久的な制約です。 

.TP 2

o

\f2fixed\fP という IDL 型はサポートされていません。 

.RE