1 '\" t
   2 .\" Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved.
   3 .\" DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   4 .\"
   5 .\" This code is free software; you can redistribute it and/or modify it
   6 .\" under the terms of the GNU General Public License version 2 only, as
   7 .\" published by the Free Software Foundation.
   8 .\"
   9 .\" This code is distributed in the hope that it will be useful, but WITHOUT
  10 .\" ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11 .\" FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12 .\" version 2 for more details (a copy is included in the LICENSE file that
  13 .\" accompanied this code).
  14 .\"
  15 .\" You should have received a copy of the GNU General Public License version
  16 .\" 2 along with this work; if not, write to the Free Software Foundation,
  17 .\" Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18 .\"
  19 .\" Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20 .\" or visit www.oracle.com if you need additional information or have any
  21 .\" questions.
  22 .\"
  23 .\" Title: idlj
  24 .\" Language: Japanese
  25 .\" Date: 2013年11月21日
  26 .\" SectDesc: Java IDLおよびRMI-IIOPツール
  27 .\" Software: JDK 8
  28 .\" Arch: 汎用
  29 .\" Part Number: E58103-01
  30 .\" Doc ID: JSSON
  31 .\"
  32 .if n .pl 99999
  33 .TH "idlj" "1" "2013年11月21日" "JDK 8" "Java IDLおよびRMI-IIOPツール"
  34 .\" -----------------------------------------------------------------
  35 .\" * Define some portability stuff
  36 .\" -----------------------------------------------------------------
  37 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  38 .\" http://bugs.debian.org/507673
  39 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
  40 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  41 .ie \n(.g .ds Aq \(aq
  42 .el       .ds Aq '
  43 .\" -----------------------------------------------------------------
  44 .\" * set default formatting
  45 .\" -----------------------------------------------------------------
  46 .\" disable hyphenation
  47 .nh
  48 .\" disable justification (adjust text to left margin only)
  49 .ad l
  50 .\" -----------------------------------------------------------------
  51 .\" * MAIN CONTENT STARTS HERE *
  52 .\" -----------------------------------------------------------------
  53 .SH "名前"
  54 idlj \- 指定されたインタフェース定義言語(IDL)ファイルに対してJavaバインディングを生成します。
  55 .SH "概要"
  56 .sp
  57 .if n \{\
  58 .RS 4
  59 .\}
  60 .nf
  61 \fBidlj\fR [ \fIoptions\fR ] \fIidlfile\fR
  62 .fi
  63 .if n \{\
  64 .RE
  65 .\}
  66 .PP
  67 \fIoptions\fR
  68 .RS 4
  69 コマンド行オプション。オプションを参照してください。optionsの順番は任意ですが、\fBidlfile\fRよりも前に指定する必要があります。
  70 .RE
  71 .PP
  72 \fIidlfile\fR
  73 .RS 4
  74 インタフェース定義言語(IDL)による定義が含まれるファイルの名前。
  75 .RE
  76 .SH "説明"
  77 .PP
  78 IDL\-to\-Javaコンパイラは、指定されたIDLファイルに対してJavaバインディングを生成します。バインディングの詳細は、http://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping\&.htmlにある
  79 Java IDL: Java言語マッピングへのIDLを参照してください。
  80 .PP
  81 IDL\-to\-Javaコンパイラの以前のリリースの中には、\fBidltojava\fRという名前だったものがあります。
  82 .SS "クライアント・バインディングおよびサーバー・バインディングの発行"
  83 .PP
  84 次の\fBidlj\fRコマンドは、クライアント側バインディングを含む\fBMy\&.idl\fRという名前のIDLファイルを生成します。
  85 .sp
  86 .if n \{\
  87 .RS 4
  88 .\}
  89 .nf
  90 \fBidlj My\&.idl\fR
  91  
  92 .fi
  93 .if n \{\
  94 .RE
  95 .\}
  96 .PP
  97 前の構文は次と同等です。
  98 .sp
  99 .if n \{\
 100 .RS 4
 101 .\}
 102 .nf
 103 \fBidlj \-fclient My\&.idl\fR
 104  
 105 .fi
 106 .if n \{\
 107 .RE
 108 .\}
 109 .PP
 110 次の例では、サーバー側バインディングを生成し、クライアント側バインディングおよびスケルトンを含めており、これらはすべて、POA (継承モデル)です。
 111 .sp
 112 .if n \{\
 113 .RS 4
 114 .\}
 115 .nf
 116 \fBidlg \-fserver My\&.idl\fR
 117  
 118 .fi
 119 .if n \{\
 120 .RE
 121 .\}
 122 .PP
 123 クライアント側とサーバー側の両方のバインディングを生成する場合は、次のコマンド(どれも等価)のうちの1つを使用します。
 124 .sp
 125 .if n \{\
 126 .RS 4
 127 .\}
 128 .nf
 129 \fBidlj \-fclient \-fserver My\&.idl\fR
 130 \fBidlj \-fall My\&.idl\fR
 131  
 132 .fi
 133 .if n \{\
 134 .RE
 135 .\}
 136 .PP
 137 サーバー側で可能なモデルは2つあります。移殖可能サーバント継承モデルとTieモデルです。Tie委譲モデルを参照してください。
 138 .PP
 139 \fB移殖可能サーバント継承モデル\fR. デフォルトのサーバー側のモデルは、移殖可能サーバント継承モデルです。\fBMy\&.idl\fR内で\fBMy\fRインタフェースが定義されている場合は、\fBMyPOA\&.java\fRというファイルが生成されます。\fBMy\fRインタフェースの実装を提供する必要があり、\fBMy\fRインタフェースは\fBMyPOA\fRクラスから継承する必要があります。\fBMyPOA\&.java\fRは、http://docs\&.oracle\&.com/javase/8/docs/api/org/omg/PortableServer/Servant\&.htmlにある
 140 \fBorg\&.omg\&.PortableServer\&.Servant\fRクラスを拡張するストリームベースのスケルトンです。
 141 .PP
 142 \fBMy\fRインタフェースは、スケルトンが実装するIDLインタフェースに関連付けられている\fBcallHandler\fRインタフェースと操作インタフェースを実装します。
 143 .PP
 144 ポータブル・オブジェクト・アダプタ(POA)の\fBPortableServer\fRモジュールは、ネイティブの\fBServant\fR型を定義します。http://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/POA\&.htmlにある
 145 ポータブル・オブジェクト・アダプタ(POA)を参照してください。
 146 .PP
 147 Javaプログラミング言語では、\fBServant\fR型はJavaの\fBorg\&.omg\&.PortableServer\&.Servant\fRクラスにマップされます。これは、すべてのPOAサーバント実装のベース・クラスとして機能し、アプリケーション・プログラマが呼び出すことのできるいくつかのメソッド、およびPOAによって呼び出され、サーバントの動作を制御するためにユーザーがオーバーライドできるメソッドを提供します。
 148 .PP
 149 継承モデルのもう1つのオプションは、\fB\-oldImplBase\fRフラグを使用して、Java SE 1\&.4より前のリリースのJavaプログラミング言語と互換性のあるサーバー側バインディングを生成することです。\-\fBoldImplBase\fRフラグは非標準で、これらのAPIは非推奨です。このフラグを使用するのは、Java SE 1\&.3で記述された既存のサーバーとの互換性が必要な場合のみです。その場合、既存のmakeファイルを変更して、\fB\-oldImplBase\fRフラグを\fBidlj\fRコンパイラに追加する必要があります。それ以外の場合、POAベースのサーバー側マッピングが生成されます。後方互換性のあるサーバー側バインディングを生成するには、次を実行します。
 150 .sp
 151 .if n \{\
 152 .RS 4
 153 .\}
 154 .nf
 155 \fBidlj \-fclient \-fserver \-oldImplBase My\&.idl\fR
 156 \fBidlj \-fall \-oldImplBase My\&.idl\fR
 157  
 158 .fi
 159 .if n \{\
 160 .RE
 161 .\}
 162 .PP
 163 \fBMy\&.idl\fR内で\fBMy\fRインタフェースが定義されている場合は、\fB_MyImplBase\&.java\fRというファイルが生成されます。\fBMy\fRインタフェースの実装を提供する必要があり、\fBMy\fRインタフェースは\fB_MyImplBase\fRクラスから継承する必要があります。
 164 .PP
 165 \fBTie委譲モデル\fR. もう1つのサーバー側モデルは、Tieモデルと呼ばれるものです。このサーバー側モデルは、委譲モデルです。Tieとスケルトンを同時に生成することはできないため、それらは別々に生成する必要があります。次のコマンドによって、Tieモデル用のバインディングが生成されます。
 166 .sp
 167 .if n \{\
 168 .RS 4
 169 .\}
 170 .nf
 171 \fBidlj \-fall My\&.idl\fR
 172 \fBidlj \-fallTIE My\&.idl\fR
 173  
 174 .fi
 175 .if n \{\
 176 .RE
 177 .\}
 178 .PP
 179 \fBMy\fRインタフェースの場合、2番目のコマンドにより、\fBMyPOATie\&.java\fRが生成されます。\fBMyPOATie\fRクラスへのコンストラクタは、delegateを取ります。この例では、デフォルトのPOAモデルを使用しているため、コンストラクタにもPOAが必要です。delegateに対して実装を提供する必要がありますが、この実装は\fBMyOperations\fRインタフェースから継承する必要があるのみで、その他のクラスから継承する必要はありません。これをORBと一緒に使用するには、たとえば次のように\fBMyPOATie\fRクラス内で実装をラップする必要があります。
 180 .sp
 181 .if n \{\
 182 .RS 4
 183 .\}
 184 .nf
 185 \fBORB orb = ORB\&.init(args, System\&.getProperties());\fR
 186 \fB \fR
 187 \fB// Get reference to rootpoa & activate the POAManager\fR
 188 \fBPOA rootpoa = (POA)orb\&.resolve_initial_references("RootPOA");\fR
 189 \fBrootpoa\&.the_POAManager()\&.activate();\fR
 190 \fB \fR
 191 \fB// create servant and register it with the ORB\fR
 192 \fBMyServant myDelegate = new MyServant();\fR
 193 \fBmyDelegate\&.setORB(orb); \fR
 194 \fB \fR
 195 \fB// create a tie, with servant being the delegate\&.\fR
 196 \fBMyPOATie tie = new MyPOATie(myDelegate, rootpoa);\fR
 197 \fB \fR
 198 \fB// obtain the objectRef for the tie\fR
 199 \fBMy ref = tie\&._this(orb);\fR
 200  
 201 .fi
 202 .if n \{\
 203 .RE
 204 .\}
 205 .PP
 206 他の実装から継承する必要がある場合、標準の継承モデルではなくTieモデルを使用することもできます。Javaの場合は、インタフェースの継承の個数に制限はありませんが、クラスの継承に使用できるスロットは1つのみです。継承モデルを使用した場合は、そのスロットが占有されます。Tieモデルを使用すると、そのスロットが使用されず、ユーザーが独自の目的で使用できます。この方法には、間接性のレベルが1つ導入されるという短所があります。メソッドを呼び出すときに、余分なメソッド呼出しが1回発生します。
 207 .PP
 208 サーバー側の生成の場合、Java SE 1\&.4より前のバージョンのJava言語にマッピングするIDLのバージョンと互換性のある、Tieモデルのバインディングです。
 209 .sp
 210 .if n \{\
 211 .RS 4
 212 .\}
 213 .nf
 214 \fBidlj \-oldImplBase \-fall My\&.idl\fR
 215 \fBidlj \-oldImplBase \-fallTIE My\&.idl\fR
 216  
 217 .fi
 218 .if n \{\
 219 .RE
 220 .\}
 221 .PP
 222 \fBMy\fRインタフェースの場合、これにより、\fBMy_Tie\&.java\fRが生成されます。\fBMy_Tie\fRクラスへのコンストラクタは、\fBimpl\fRオブジェクトを取ります。\fBimpl\fRに対して実装を提供する必要がありますが、その実装は\fBHelloOperations\fRインタフェースから継承する必要があるのみで、その他のクラスから継承する必要はありません。しかし、これをORBと一緒に使用するには、たとえば次のように\fBMy_Tie\fR内で実装をラップする必要があります。
 223 .sp
 224 .if n \{\
 225 .RS 4
 226 .\}
 227 .nf
 228 \fBORB orb = ORB\&.init(args, System\&.getProperties());\fR
 229  
 230 \fB// create servant and register it with the ORB\fR
 231 \fBMyServant myDelegate = new MyServant();\fR
 232 \fBmyDelegate\&.setORB(orb); \fR
 233 \fB \fR
 234 \fB// create a tie, with servant being the delegate\&.\fR
 235 \fBMyPOATie tie = new MyPOATie(myDelegate);\fR
 236 \fB \fR
 237 \fB// obtain the objectRef for the tie\fR
 238 \fBMy ref = tie\&._this(orb);\fR
 239  
 240 .fi
 241 .if n \{\
 242 .RE
 243 .\}
 244 .SS "発行されたファイルの代替位置の指定"
 245 .PP
 246 発行されたファイルを現在のディレクトリ以外のディレクトリに置くには、\fBi\fR\fBdlj \-td /altdir My\&.idl\fRのコマンドでコンパイラを呼び出します。
 247 .PP
 248 
 249 \fBMy\fRインタフェースの場合、バインディングは、\fB\&./My\&.java\fRではなく、\fB/altdir/My\&.java\fRなどに発行されます。
 250 .SS "インクルード・ファイルの代替位置の指定"
 251 .PP
 252 \fBMy\&.idl\fRファイルが別の\fBidl\fRファイルである\fBMyOther\&.idl\fRをインクルードする場合、コンパイラでは、\fBMyOther\&.idl\fRファイルがローカル・ディレクトリに存在することを前提としています。たとえば、それが\fB/includes\fRにある場合は、次のようなコマンドでコンパイラを呼び出します。
 253 .sp
 254 .if n \{\
 255 .RS 4
 256 .\}
 257 .nf
 258 \fBidlj \-i /includes My\&.idl\fR
 259  
 260 .fi
 261 .if n \{\
 262 .RE
 263 .\}
 264 .PP
 265 たとえば、\fB/moreIncludes\fRにある\fBAnother\&.idl\fRも\fBMy\&.idl\fRにインクルードされているのであれば、次のようなコマンドでコンパイラを呼び出します。
 266 .sp
 267 .if n \{\
 268 .RS 4
 269 .\}
 270 .nf
 271 \fBidlj \-i /includes \-i /moreIncludes My\&.idl\fR
 272  
 273 .fi
 274 .if n \{\
 275 .RE
 276 .\}
 277 .PP
 278 このような形式の\fBinclude\fRは長くなるため、インクルード・ファイルを検索する場所をコンパイラに指示するための別の方法が用意されています。この方法は、環境変数の考え方と似ています。\fBCLASSPATH\fR変数に一覧表示されているディレクトリ内にidl\&.configという名前のファイルを作成します。その\fBidl\&.config\fRの中に、次のような形式の行を入れます。
 279 .sp
 280 .if n \{\
 281 .RS 4
 282 .\}
 283 .nf
 284 \fBincludes=/includes;/moreIncludes\fR
 285  
 286 .fi
 287 .if n \{\
 288 .RE
 289 .\}
 290 .PP
 291 コンパイラは、このファイルを検索し、インクルード・リストを読み込みます。この例では、ディレクトリの間の区切り文字はセミコロン(;)になっています。この区切り文字は、プラットフォームによって異なります。Windowsプラットフォームではセミコロンを使用し、Solaris、LinuxおよびOS Xプラットフォームではコロンを使用します。
 292 .SS "インクルード・ファイルに対するバインディングの発行"
 293 .PP
 294 デフォルトでは、コマンド行に指定した\fBidl\fRファイルで定義されているインタフェースや構造体などについてのみ、Javaバインディングが生成されます。インクルードされたファイルで定義されている型については生成されません。たとえば、次の2つの\fBidl\fRファイルについて考えてみます。
 295 .sp
 296 .if n \{\
 297 .RS 4
 298 .\}
 299 .nf
 300 \fBMy\&.idl file:\fR
 301 \fB \fR
 302 \fB#include <MyOther\&.idl>\fR
 303 \fBinterface My\fR
 304 \fB{\fR
 305 \fB};\fR
 306 \fB \fR
 307 \fBMyOther\&.idl file:\fR
 308 \fB \fR
 309 \fBinterface MyOther\fR
 310 \fB{\fR
 311 \fB};\fR
 312  
 313 .fi
 314 .if n \{\
 315 .RE
 316 .\}
 317 .PP
 318 デフォルトのルールに関して警告があります。グローバル・スコープに表示される\fB#include\fR文は、前述のとおりに処理されます。これらの\fB#include\fR文は、インポート文と見なすことができます。囲まれたスコープ内に表示される\fB#include\fR文は、本当の意味での\fB#include\fR文として処理されます。つまり、インクルードされたファイルにあるコードが、元のファイルにそのまま表示されているかのように処理され、それに対してJavaバインディングが発行されます。次はその例です。
 319 .sp
 320 .if n \{\
 321 .RS 4
 322 .\}
 323 .nf
 324 \fBMy\&.idl file:\fR
 325 \fB \fR
 326 \fB#include <MyOther\&.idl>\fR
 327 \fBinterface My\fR
 328 \fB{\fR
 329 \fB  #include <Embedded\&.idl>\fR
 330 \fB};\fR
 331 \fB \fR
 332 \fBMyOther\&.idl file:\fR
 333 \fB \fR
 334 \fBinterface MyOther\fR
 335 \fB{\fR
 336 \fB};\fR
 337 \fB \fR
 338 \fBEmbedded\&.idl\fR
 339 \fB \fR
 340 \fBenum E {one, two, three};\fR
 341  
 342 .fi
 343 .if n \{\
 344 .RE
 345 .\}
 346 .PP
 347 \fB idlj My\&.idl \fRを実行して、Javaファイルの次のリストを生成します。インポート文とみなされる\fB#include\fRに定義されていたため、\fBMyOther\&.java\fRは生成されませんでした。ただし、本当の意味での\fB#include\fRで定義されていたため、\fBE\&.java\fRは生成されました。\fBEmbedded\&.idl\fRファイルが\fBMy\fRインタフェースのスコープ内にインクルードされているため、\fBMy\fRのスコープ内(つまり、\fBMyPackage\fR内)に生成されています。\fB\-emitAll\fRフラグを使用した場合、インクルードされたすべてのファイルにあるすべての型が発行されます。
 348 .sp
 349 .if n \{\
 350 .RS 4
 351 .\}
 352 .nf
 353 \fB\&./MyHolder\&.java\fR
 354 \fB\&./MyHelper\&.java\fR
 355 \fB\&./_MyStub\&.java\fR
 356 \fB\&./MyPackage\fR
 357 \fB\&./MyPackage/EHolder\&.java\fR
 358 \fB\&./MyPackage/EHelper\&.java\fR
 359 \fB\&./MyPackage/E\&.java\fR
 360 \fB\&./My\&.java\fR
 361  
 362 .fi
 363 .if n \{\
 364 .RE
 365 .\}
 366 .SS "パッケージの接頭辞の挿入"
 367 .PP
 368 ABCという名前の会社のために作業していて、次のようなIDLファイルを構築したとしましょう。
 369 .sp
 370 .if n \{\
 371 .RS 4
 372 .\}
 373 .nf
 374 \fBWidgets\&.idl file:\fR
 375 \fB \fR
 376 \fBmodule Widgets\fR
 377 \fB{\fR
 378 \fB  interface W1 {\&.\&.\&.};\fR
 379 \fB  interface W2 {\&.\&.\&.};\fR
 380 \fB};\fR
 381  
 382 .fi
 383 .if n \{\
 384 .RE
 385 .\}
 386 .PP
 387 IDL\-to\-Javaコンパイラを介してこのファイルを実行した場合、W1およびW2に対するJavaバインディングは、\fBWidgets\fRパッケージ内に格納されます。業界の慣例によると、会社のパッケージは、\fBcom\&.<company name>\fRという名前のパッケージ内に置くことになっています。この慣例に従うには、パッケージ名を\fBcom\&.abc\&.Widgets\fRにする必要があります。このパッケージ接頭辞をWidgetsモジュールに付加するには、次のコマンドを実行します。
 388 .sp
 389 .if n \{\
 390 .RS 4
 391 .\}
 392 .nf
 393 \fBidlj \-pkgPrefix Widgets com\&.abc Widgets\&.idl\fR
 394  
 395 .fi
 396 .if n \{\
 397 .RE
 398 .\}
 399 .PP
 400 Widgets\&.idlをインクルードしているIDLファイルがある場合は、そのコマンドにも\fB\-pkgPrefix\fRフラグが必要です。このフラグを指定しないと、そのIDLファイルは、\fBcom\&.abc\&.Widgets\fRパッケージではなく、\fBWidgets\fRパッケージを検索することになります。
 401 .PP
 402 接頭辞が必要なパッケージがいくつもある場合は、前述のidl\&.configファイルで接頭辞を指定するのが簡単です。各パッケージの接頭辞行は、\fBPkgPrefix\&.<type>=<prefix>\fRの形式にする必要があります。前述の例の行では、\fBPkgPrefix\&.Widgets=com\&.abc\fRになります。このオプションは、リポジトリIDには影響しません。
 403 .SS "コンパイル前のシンボルの定義"
 404 .PP
 405 コンパイル用のシンボルがIDLファイル内で定義されていない場合は、そのシンボルを定義する必要があります。これは、たとえば、バインディング内にデバッグ・コードを組み入れるときに使用します。コマンド\fBidlj \-d MYDEF My\&.idl \fRは、My\&.idl内に行\fB#define MYDEF\fRを配置した場合と同等になります。
 406 .SS "既存のバインディングの保持"
 407 .PP
 408 Javaバインディング・ファイルがすでに存在する場合は、\fB\-keep\fRフラグを指定すると、コンパイラによる上書きを回避できます。デフォルトでは、すでに存在するかどうかにかかわらず、すべてのファイルが生成されます。これらのファイルをカスタマイズした場合(ただし、それらの内容が正確であるとき以外はカスタマイズは避ける)、\fB\-keep\fRオプションは有用です。コマンド\fBidlj \-keep My\&.idl\fRは、すでに存在しないすべてのクライアント側バインディングを発行します。
 409 .SS "コンパイルの進捗状況の表示"
 410 .PP
 411 IDL\-to\-Javaコンパイラは、実行の各段階で状態メッセージを生成します。\fB\-v\fRオプションを使用して、\fBidlj \-v My\&.idl\fRのような冗長モードをアクティブ化します。
 412 .PP
 413 デフォルトでは、コンパイラは冗長モードでは実行されません。
 414 .SS "バージョン情報の表示"
 415 .PP
 416 IDL\-to\-Javaコンパイラのビルド・バージョンを表示するには、コマンド行\fBidlj \-version\fRで\fB\-version\fRオプションを指定します。
 417 .PP
 418 バージョン情報は、コンパイラによって生成されたバインディング内にも書き込まれています。このオプションをコマンド行に指定すると、それ以外のオプションを指定しても、すべて無視されます。
 419 .SH "オプション"
 420 .PP
 421 \-d \fIsymbol\fR
 422 .RS 4
 423 このオプションは、IDLファイルに次のような行を追加した場合と等価です。
 424 .sp
 425 .if n \{\
 426 .RS 4
 427 .\}
 428 .nf
 429 \fB#define \fR\fB\fIsymbol\fR\fR
 430  
 431 .fi
 432 .if n \{\
 433 .RE
 434 .\}
 435 .RE
 436 .PP
 437 \-demitAll
 438 .RS 4
 439 \fB#include\fRファイル内で定義されているものも含めて、すべての型を発行します。
 440 .RE
 441 .PP
 442 \-fside
 443 .RS 4
 444 発行するバインディングを定義します。\fBside\fRパラメータには、\fBclient\fR、\fBserver\fR、\fBserverTIE\fR、\fBall\fRまたは\fBallTIE\fRを指定できます。\fB\-fserverTIE\fRまたは\fB\-fallTIE\fRオプションを指定すると、委譲モデル・スケルトンが発行されます。フラグを指定しない場合、\fB\-fclient\fRにデフォルト設定されます。
 445 .RE
 446 .PP
 447 \-i \fIinclude\-path\fR
 448 .RS 4
 449 デフォルトでは、インクルード・ファイルは現在のディレクトリから検索されます。このオプションを指定すると、他のディレクトリを追加できます。
 450 .RE
 451 .PP
 452 \-i \fIkeep\fR
 453 .RS 4
 454 生成されるファイルがすでに存在している場合は、そのファイルが上書きされません。デフォルトでは、上書きされます。
 455 .RE
 456 .PP
 457 \-noWarn
 458 .RS 4
 459 警告メッセージを表示しないようにします。
 460 .RE
 461 .PP
 462 \-oldImplBase
 463 .RS 4
 464 1\&.4より前のJDK ORBと互換性のあるスケルトンを生成します。デフォルトでは、POA継承モデルのサーバー側バインディングが生成されます。このオプションを指定すると、\fBImplBase\fR継承モデルのクラスであるサーバー側バインディングが生成されるので、以前のリリースのJavaプログラミング言語との後方互換性が得られます。
 465 .RE
 466 .PP
 467 \-pkgPrefix \fItype\fR \fIprefix\fR
 468 .RS 4
 469 \fBtype\fRがファイル・スコープで検出された場合は、その型に対して生成されるすべてのファイルについて、生成されるJavaパッケージ名に\fBprefix\fRという接頭辞が付加されます。typeは、トップレベル・モジュールの単純名か、どのモジュールよりも外側で定義されたIDL型の単純名のどちらかです。
 470 .RE
 471 .PP
 472 \-pkgTranslate \fItype\fR \fIpackage\fR
 473 .RS 4
 474 識別子の中にモジュール名typeが検出されると、生成されるJavaパッケージ内のすべてのファイルについて、識別子の中のその名前がpackageで置き換えられます。最初に\fBpkgPrefix\fRの変更が行われます。typeの値は、トップレベルのモジュールの単純名、またはすべてのモジュールの外部で定義されたIDL型の単純名で、完全なパッケージ名に正確に一致する必要があります。
 475 .sp
 476 複数の変換が識別子に一致する場合、次の例に示すように、最も長い一致が選択されます。
 477 .sp
 478 \fBコマンド\fR:
 479 .sp
 480 .if n \{\
 481 .RS 4
 482 .\}
 483 .nf
 484 \fBpkgTranslate type pkg \-pkgTranslate type2\&.baz pkg2\&.fizz\fR
 485  
 486 .fi
 487 .if n \{\
 488 .RE
 489 .\}
 490 \fB結果の変換\fR:
 491 .sp
 492 .if n \{\
 493 .RS 4
 494 .\}
 495 .nf
 496 \fBtype => pkg\fR
 497 \fBtype\&.ext => pkg\&.ext\fR
 498 \fBtype\&.baz => pkg2\&.fizz\fR
 499 \fBtype2\&.baz\&.pkg => pkg2\&.fizz\&.pkg\fR
 500  
 501 .fi
 502 .if n \{\
 503 .RE
 504 .\}
 505 パッケージ名\fBorg\fR、\fBorg\fR\&.o\fBmg\fR、または\fBorg\&.omg\fRのサブパッケージは、変換できません。これらのパッケージ名を変換しようとすると、互換性のないコードが生成され、\fB\-pkgTranslate\fRの後の最初の引数としてそれらのパッケージを使用すると、エラーとして扱われます。
 506 .RE
 507 .PP
 508 \-skeletonName \fIxxx%yyy\fR
 509 .RS 4
 510 \fBxxx%yyy\fRが、スケルトンに名前を付けるパターンとして使用されます。デフォルトは次のとおりです。\fBPOA\fRベース・クラスの場合は\fB%POA\fR
 511 (\fB\-fserver\fRまたは\fB\-fall\fR)、\fBoldImplBase\fRクラスの場合は\fB_%ImplBase\fR
 512 (\-\fBoldImplBase\fR)および(\fB\-fserver\fRまたは\fB\-fall\fR))。
 513 .RE
 514 .PP
 515 \-td \fIdir\fR
 516 .RS 4
 517 出力ディレクトリとして、現在のディレクトリではなく、\fIdir\fRが使用されます。
 518 .RE
 519 .PP
 520 \-tieName \fIxxx%yyy\fR
 521 .RS 4
 522 パターンに従って、\fBxxx%yyy\fRを使用します。デフォルトは次のとおりです。\fBPOA\fRベース・クラスの場合は\fB%POA\fR
 523 (\fB\-fserverTieまたは\-fallTie\fR)、\fBoldImplBase\fR
 524 tieクラスの場合は\fB_%Tie\fR
 525 (\-\fBoldImplBase\fR)および(\fB\-fserverTie\fRまたは\fB\-fallTie\fR))。
 526 .RE
 527 .PP
 528 \-nowarn、\-verbose
 529 .RS 4
 530 リリース情報を表示して終了します。
 531 .RE
 532 .PP
 533 \-version
 534 .RS 4
 535 リリース情報を表示して終了します。
 536 .RE
 537 .SH "制限事項"
 538 .PP
 539 グローバル・スコープ内のエスケープされた識別子は、IDLプリミティブ型の\fBObject\fRまたは\fBValueBase\fRと同じ綴りにしないでください。これは、シンボル表がこれらの識別子でプリロードされているためです。これらの再定義を許可すると、元の定義が上書きされます。これは、おそらく恒久的な制約です。
 540 .PP
 541 \fBfixed\fRというIDL型はサポートされていません。
 542 .SH "既知の問題"
 543 .PP
 544 グローバル識別子についてインポートが生成されません。予期されないローカル\fBimpl\fRオブジェクトを呼び出すと、例外を受け取ります。しかし、その原因は、\fBServerDelegate\fR
 545 DSIコード内の\fBNullPointerException\fRにあるようです。
 546 .br
 547 'pl 8.5i
 548 'bp