1 '\" t
   2 .\" Copyright 2006 Sun Microsystems, Inc.  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 .TH idlj 1 "05 Jul 2012"
  24 .SH "名前"
  25 idlj - IDL-to-Java コンパイラ
  26 .LP
  27 .B idlj
  28 は、指定された IDL ファイルから Java バインディングを生成します。
  29 .SH "形式"
  30 .B idlj
  31 [
  32 .IB options
  33 ]
  34 .B idl-file
  35 .LP
  36 .BR idl-file
  37 には、Interface Definition Language (IDL) 定義が格納されている
  38 ファイルの名前を指定します。
  39 .BR Options
  40 は任意の順序で指定できますが、
  41 .BR idl-file
  42 よりも前に指定する必要があります。
  43 .SH "機能説明"
  44 IDL-to-Java コンパイラは、指定された IDL ファイルに対して Java 
  45 バインディングを生成します。
  46 バインディングの詳細は、「\f2OMG IDL to Java Language Language Mapping Specification\fP」
  47 .fi
  48 (http://docs.oracle.com/javase/6/docs/technotes/guides/idl/mapping/jidlMapping.html) 
  49 を参照してください。
  50 IDL-to-Java コンパイラの旧リリースのなかには、
  51 .BR idltojava という名前が付けられていたものがあります。
  52 .SH "クライアントバインディングとサーババインディングの発行"
  53 
  54 .LP
  55 .BR My.idl
  56 という名前の IDL ファイルに対して Java バインディングを生成
  57 するには、次のように指定します。
  58 .LP
  59 .RS
  60 .ft 3
  61 .nf
  62 idlj My.idl
  63 .fi
  64 .ft 1
  65 .RE
  66 .LP
  67 クライアント側のバインディングを生成する上記のコマンドは、
  68 次のようにも指定できます。
  69 .LP
  70 .RS
  71 .ft 3
  72 .nf
  73 idlj -fclient My.idl
  74 .fi
  75 .ft 1
  76 .RE
  77 .LP
  78 クライアント側のバインディングには、サーバ側のスケルトンは
  79 取り込まれていません。インタフェースに対してサーバ側のバインディング
  80 を生成するには、次のように指定します。
  81 .LP
  82 .RS
  83 .ft 3
  84 .nf
  85 idlj -fserver My.idl
  86 .fi
  87 .ft 1
  88 .RE
  89 .LP
  90 サーバ側のバインディングには、クライアント側のバインディングのほか
  91 にスケルトンが取り込まれています。これらはすべて、POA (継承モデル) 
  92 クラスです。クライアント側とサーバ側の両方のバインディングを生成する
  93 には、以下の等価コマンドのどちらか一方を使用してください。
  94 .LP
  95 .RS
  96 .ft 3
  97 .nf
  98 idlj -fclient -fserver My.idl
  99 .br
 100 idlj -fall My.idl
 101 .fi
 102 .ft 1
 103 .RE
 104 .LP
 105 サーバ側モデルとしては、継承モデルと Tie 委譲モデルの 2 種類を
 106 利用できます。
 107 .LP
 108 デフォルトのサーバ側モデルは、ポータブルサーバント継承モデルです。
 109 .BR My.idl
 110 でインタフェース My が定義されていると、ファイル 
 111 .BR MyPOA.java が生成されます。ユーザは、
 112 .BR My に対してその実装を提供する必要があります。この実装は、
 113 .BR MyPOA から継承しなければなりません。
 114 .LP
 115 .BR MyPOA.java は、
 116 .na
 117 \f2org.omg.PortableServer.Servant\fP 
 118 .fi
 119 (http://docs.oracle.com/javase/6/docs/api/org/omg/PortableServer/Servant.html) 
 120 を拡張するストリームベースのスケルトンであり、このスケルトンが実装する 
 121 IDL インタフェースに関連した
 122 .BR InvokeHandler
 123 インタフェースとオペレーションインタフェースを実装します。
 124 .LP
 125 .na
 126 \f2Portable Object Adapter (POA)\fP
 127 .fi
 128 (http://docs.oracle.com/javase/6/docs/technotes/guides/idl/POA.html) の
 129 .BR PortableServer 
 130 モジュールは、ネイティブ Servant 型を定義します。Java プログラミング言語では、
 131 .BR Servant
 132 型は、Java 
 133 .BR org.omg.PortableServer.Servant
 134 クラスにマップされます。
 135 これはすべての
 136 .BR POA
 137 サーバント実装の基底クラスとして機能し、アプリケーション開発者が呼び出せる
 138 多数のメソッドを提供します。また、POA 自体が呼び出したり、サーバント動作を
 139 制御するためにユーザが上書きしたりできるメソッドも提供します。
 140 .LP
 141 継承モデルには、J2SE 1.4 より前のバージョンの Java プログラミング言語
 142 と互換性のあるサーバ側バインディングを生成するために
 143 .BR -oldImplBase
 144 フラグを使用するというオプションもあります。
 145 \f2\-oldImplBase\fP フラグの使用は非標準であることに注意してください。これらの API はまもなく非推奨となります。このフラグを使用するのは、J2SE 1.3 で記述された既存のサーバとの互換性を確保する必要がある場合だけにしてください。その場合、既存の MAKEFILE を変更し、\f2\-oldImplBase\fP フラグを \f2idlj\fP コンパイラに追加する必要があります。そうしないと、POA ベースのサーバ側マッピングが生成されてしまいます。
 146 下位互換を維持したサーバ側
 147 バインディングを生成するには、次のように指定します。
 148 .LP
 149 .RS
 150 .ft 3
 151 .nf
 152 idlj -fclient -fserver -oldImplBase My.idl
 153 .br
 154 idlj -fall -oldImplBase My.idl
 155 .fi
 156 .ft 1
 157 .RE
 158 .LP
 159 .BR My.idl
 160 内でインタフェース My が定義されていると、ファイル 
 161 .I _MyImpleBase.java
 162 が生成されます。ユーザは、
 163 .BR My
 164 に対してその実装を提供する必要があります。この実証は、
 165 .I _MyImplBase
 166  から継承しなければなりません。
 167 .LP
 168 もう一方のサーバ側モデルは、Tie モデルと呼ばれます。これは、
 169 委譲モデルです。Tie モデルは Tie とスケルトンを同時には生成
 170 できないため、これらは別々に生成する必要があります。次のコ
 171 マンドは、Tie モデルに対してバインディングを生成します。
 172 .LP
 173 .RS
 174 .ft 3
 175 .nf
 176 idlj -fall My.idl
 177 .br
 178 idlj -fallTIE My.idl
 179 .fi
 180 .ft 1
 181 .RE
 182 .LP
 183 インタフェース 
 184 .BR My
 185 の場合、2 つめのコマンドは 
 186 .BR MyPOATie.java
 187  を生成します。
 188 .BR MyPOATie
 189 のコンストラクタは、delegate を受け取ります。
 190 この例ではデフォルトの POA モデルを使用しているので、コンストラクタは \f2poa\fP も必要とします。
 191 ユーザは、delegate 
 192 に対して実装を提供する必要があります。ただし、インタフェース 
 193 .BR MyOperations
 194 を継承すればよく、ほかのクラスから継承する必要はありません。
 195 しかし、この実装を ORB と共に使用するには、
 196 .BR MyPOATie 
 197 内に実装をラップする必要があります。例を示します。
 198 .nf
 199 \f3
 200 .fl
 201     ORB orb = ORB.init(args, System.getProperties());
 202 .fl
 203 
 204 .fl
 205     // rootpoa への参照を取得し、POAManager を有効にします
 206 .fl
 207     POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
 208 .fl
 209     rootpoa.the_POAManager().activate();
 210 .fl
 211 
 212 .fl
 213     // サーバントを作成し、それを ORB に登録します
 214 .fl
 215     MyServant myDelegate = new MyServant();
 216 .fl
 217     myDelegate.setORB(orb); 
 218 .fl
 219 
 220 .fl
 221     // Tie を作成します。サーバントが delegate になります。
 222 .fl
 223     MyPOATie tie = new MyPOATie(myDelegate, rootpoa);
 224 .fl
 225 
 226 .fl
 227     // Tie の objectRef を取得します
 228 .fl
 229     My ref = tie._this(orb);
 230 .fl
 231 \fP
 232 .fi
 233 
 234 .LP
 235 実装をほかの実装から継承しなければならない場合は、標準の継承モデル
 236 の代わりに Tie モデルを使用することもできます。Java は任意の数の
 237 インタフェース継承を認めていますが、クラスの継承に使用できる
 238 スロットは 1 つだけです。継承モデルを使用すると、このスロットが占
 239 有されます。Tie モデルを使用すると、スロットをユーザ自身の使用の
 240 ために解放できます。ただし、一定レベルの間接参照を引き起こすと
 241 いう欠点があります。つまり、メソッドを呼び出すと、余分なメソッド呼
 242 び出しが 1 つ発生します。
 243 .LP
 244 1.4 よりも前の J2SE バージョンで IDL-to-Java 言語
 245 マッピングのバージョンと互換性があるサーバ側の Tie モデルバインディングを生成
 246 するには、次のように指定します。
 247 .LP
 248 .RS
 249 .ft 3
 250 .nf
 251 idlj -oldImplBase -fall My.idl
 252 .br
 253 idlj -oldImplBase -fallTIE My.idl
 254 .fi
 255 .ft 1
 256 .RE
 257 .LP
 258 インタフェース
 259 .BR My
 260 の場合、このコマンドは
 261 .I My_Tie.java
 262 を生成します。
 263 .I My_Tie
 264 のコンストラクタは、
 265 .BR impl
 266 を受け取ります。ユーザは、
 267 .BR impl
 268 に対して実装を提供する必要があります。ただし、インタフェース 
 269 .BR HelloOperations
 270 を継承すればよく、ほかのクラスから継承する必要はありません。
 271 しかし、この実装を ORB と共に使用するには、
 272 .BR My_Tie
 273  内に実装をラップする必要があります。例を示します。
 274 .LP
 275 .nf
 276 \f3
 277 .fl
 278     ORB orb = ORB.init(args, System.getProperties());
 279 .fl
 280 
 281 .fl
 282     // サーバントを作成し、それを ORB に登録します
 283 .fl
 284     MyServant myDelegate = new MyServant();
 285 .fl
 286     myDelegate.setORB(orb); 
 287 .fl
 288 
 289 .fl
 290     // Tie を作成します。サーバントが delegate になります。
 291 .fl
 292     MyPOATie tie = new MyPOATie(myDelegate);
 293 .fl
 294 
 295 .fl
 296     // Tie の objectRef を取得します
 297 .fl
 298     My ref = tie._this(orb);
 299 .fl
 300 \fP
 301 .fi
 302 
 303 .LP
 304 .SH "発行されたファイルの代替場所の指定"
 305 .br
 306 発行されたファイルを現在のディレクトリ以外のディレクトリに保存したい場合は、
 307 次のようにコンパイラを呼び出してください。
 308 .LP
 309 .RS
 310 .ft 3
 311 .nf
 312 idlj -td /altdir My.idl
 313 .fi
 314 .ft 1
 315 .RE
 316 .LP
 317 インタフェース 
 318 .BR My
 319 の場合、バインディングは
 320 .BR ./My.java
 321  ではなく 
 322 .BR /altdir/My.java
 323 などに対して発行されます。
 324 .SH "インクルードファイルの代替場所の指定"
 325 .BR My.idl
 326 にほかの idl ファイル、
 327 .BR MyOther.idl 
 328 が取り込まれている場合、コンパイラは 
 329 .BR MyOther.idl 
 330 がローカルディレクトリに存在すると見なします。たとえば、
 331 .BR MyOther.idl 
 332 が 
 333 .BR /includes
 334 に存在する場合は、次のコマンドでコンパイラを呼び出します。
 335 .LP
 336 .RS
 337 .ft 3
 338 .nf
 339 idlj -i /includes My.idl
 340 .fi
 341 .ft 1 
 342 .RE
 343 .LP
 344 .BR たとえば、My.idl が
 345 .BR /moreIncludes
 346 に存在する
 347 .BR Another.idl 
 348 も取り込んでいる場合は、次のコマンドでコンパイラを呼び出します。
 349 .LP
 350 .RS
 351 .ft 3
 352 .nf
 353 idlj -i /includes -i /moreIncludes My.idl
 354 .fi
 355 .ft 1 
 356 .RE
 357 .LP
 358 この形式でファイルを取り込むと、コマンドが非常に長くなることがあります。
 359 このため、インクルードファイルの検索場所をコンパイラに知らせる方法が
 360 別に用意されています。この方法は、環境変数の概念に似ています。まず、
 361 CLASSPATH にリストされているディレクトリ内に、
 362 .BR idl.config
 363 という名前のファイルを作成します。そして、
 364 .BR idl.config
 365 内に次の形式の行を 1 つ作成します。
 366 .LP
 367 .RS
 368 .ft 3
 369 .nf
 370 includes=/includes;/moreIncludes
 371 .fi
 372 .ft 1 
 373 .RE
 374 .LP
 375 コンパイラはこのファイルを見つけ、インクルードリストに読み込みます。
 376 この例では 2 つのディレクトリ間の区切り文字はセミコロン (;) であること
 377 に注意してください。
 378 この区切り文字はプラットフォームによって異なります。Windows プラットフォームではセミコロンを使用し、UNIX プラットフォームではコロンを使用する、などのようになります。
 379 インクルードの詳
 380 細は、
 381 .na
 382 \f2CLASSPATH\ のドキュメント (Solaris: 
 383 .fi
 384 https://docs.oracle.com/javase/6/docs/technotes/tools/solaris/classpath.html) 
 385 (Windows: 
 386 .fi
 387 https://docs.oracle.com/javase/6/docs/technotes/tools/windows/classpath.html) 
 388 を参照してください。
 389 .SH "インクルードファイルに対するバインディングの発行"
 390 デフォルトでは、コマンド行 idl ファイルに定義されているインタフェース、
 391 構造体などに対してのみ、Java バインディングが生成されます。インクルード
 392 ファイルに定義されているタイプの Java バインディングは生成されません。
 393 例として、次の 2 つの idl ファイルを考えてみましょう。
 394 .TP
 395 .B My.idl
 396 .LP
 397 .RS
 398 #include <MyOther.idl> 
 399 .br
 400 interface My 
 401 .br
 402 { 
 403 .br
 404 }; 
 405 .RE
 406 .TP
 407 .B MyOther.idl
 408 .LP
 409 .RS
 410 interface MyOther 
 411 .br
 412 { 
 413 .br
 414 };
 415 .RE
 416 .LP
 417 次のコマンドは、
 418 .BR My
 419 に対する Java バインディングしか生成しません。
 420 .LP
 421 .RS
 422 .ft 3
 423 .nf
 424 idlj My.idl
 425 .fi
 426 .ft 1
 427 .RE
 428 .LP
 429 .BR My.idl
 430 内に定義されているすべてのタイプ、および 
 431 .BR My.idl
 432 に取り込まれているファイル (この例では 
 433 .BR MyOther.idl
 434 ) 内に定義されているすべてのタイプを生成するには、
 435 次のコマンドを使用してください。
 436 .LP
 437 .RS
 438 .ft 3
 439 .nf
 440 idlj -emitAll My.idl 
 441 .fi
 442 .ft 1
 443 .RE
 444 .LP
 445 このデフォルトの規則については、次の点に注意する必要があります。
 446 グローバルスコープに出現する 
 447 .BR #include
 448 文は、記述どおりに処理されます。これらの 
 449 .BR #include
 450 文は、インポート文と見なすことができます。一部の囲みスコープ内に
 451 出現する #include 文は、通常の 
 452 .BR #include
 453 文として扱われます。つまり、インクルードファイル内のコードは
 454 オリジナルファイル内に出現しているかのように扱われ、これに
 455 対して Java バインディングが発行されます。例を示します。
 456 .TP
 457 .B My.idl
 458 .LP
 459 .RS
 460 #include <MyOther.idl> 
 461 .br
 462 interface My 
 463 .br
 464 { 
 465 .br
 466   #include <Embedded.idl> 
 467 .br
 468 }; 
 469 .RE
 470 .TP
 471 .B MyOther.idl
 472 .LP
 473 .RS
 474 interface MyOther 
 475 .br
 476 { 
 477 .br
 478 }; 
 479 .RE
 480 .TP
 481 .B Embedded.idl
 482 .LP
 483 .RS
 484 enum E {one, two, three};
 485 .RE
 486 .LP
 487 次のコマンドを実行すると、
 488 .LP
 489 .RS
 490 .ft 3
 491 .nf
 492 idlj My.idl
 493 .fi
 494 .ft 1
 495 .RE
 496 .LP
 497 以下の Java ファイルのリストが生成されます。
 498 .LP
 499 .B ./MyHolder.java\fP
 500 .br
 501 .B ./MyHelper.java\fP
 502 .br
 503 .B ./_MyStub.java\fP
 504 .br
 505 .B ./MyPackage\fP
 506 .br
 507 .B ./MyPackage/EHolder.java\fP
 508 .br
 509 .B ./MyPackage/EHelper.java\fP
 510 .br
 511 .B ./MyPackage/E.java\fP
 512 .br
 513 .B ./My.java\fP
 514 .LP
 515 .BR MyOther.java
 516 は生成されないことに注意してください。これは、インポートに類似した
 517 .BR #include
 518 で定義されているためです。しかし、通常の
 519 .BR #include
 520 に定義された 
 521 .BR E.java
 522 は生成されます。
 523 .BR Embedded.idl
 524 はインタフェース My のスコープ内に取り込まれているため、
 525 .BR My
 526 のスコープ内 (つまり 
 527 .BR MyPackage
 528 ) に生成されます。
 529 .LP
 530 上記の例で 
 531 .BI -emitAll
 532 フラグが使用されていた場合は、すべてのインクルードファイル内に
 533 定義されているすべてのタイプが発行されます。
 534 .SH "パッケージ接頭辞の挿入"
 535 あなたが次の IDL ファイルを作成した ABC という名の企業に勤務していると
 536 仮定してください。
 537 .TP
 538 .B Widgets. idl
 539 module Widgets 
 540 .br
 541 { 
 542 .br
 543   interface W1 {...}; 
 544 .br
 545   interface W2 {...}; 
 546 .br
 547 }; 
 548 .LP
 549 このファイルに対して IDL-to-Java コンパイラを実行すると、パッケージ
 550 Widgets 内の W1 と W2 に対して Java バインディングが生成されます。
 551 しかし、業界規約では、企業のパッケージは 
 552 .BR com.<company name>
 553 という名前のパッケージ内に配置しなければならないと規定されています。
 554 そのため、この 
 555 .BR Widgets
 556 パッケージのままでは不十分です。規定に従うには、
 557 .BR com.abc.Widgets
 558 でなければなりません。
 559 .BR Widgets
 560 モジュールにこのパッケージ接頭辞を配置するには、次のコマンドを
 561 実行してください。
 562 .LP
 563 .RS
 564 .ft 3
 565 .nf
 566 idlj -pkgPrefix Widgets com.abc Widgets.idl
 567 .fi
 568 .ft 1
 569 .RE
 570 .LP
 571 .BR Widgets.idl 
 572 を取り込んでいる IDL ファイルが存在する場合は、そのコマンド内にも 
 573 .BI \-pkgPrefix 
 574 フラグを指定する必要があります。このフラグを指定しないと、IDL ファイルは
 575 .BR com.abc.Widgets
 576 パッケージではなく 
 577 .BR Widgets
 578 パッケージを検索します。
 579 .LP
 580 接頭辞を必要とするこれらのパッケージが多数存在する場合は、前述した 
 581 .BR idl.config
 582 ファイルに配置する方が簡単でしょう。各パッケージ接頭辞行は、次の書式で記述します。
 583 .LP
 584 .RS
 585 .ft 3
 586 .nf
 587 PkgPrefix.<type>=<prefix>
 588 .fi
 589 .ft 1
 590 .RE
 591 .LP
 592 この書式に従うと、上記例の行は次のようになります。
 593 .LP
 594 .RS
 595 .ft 3
 596 .nf
 597 PkgPrefix.Widgets=com.abc
 598 .fi
 599 .ft 1
 600 .RE
 601 .LP
 602 このオプションを使用しても、リポジトリ ID には影響を与えません。
 603 .SH "コンパイル前のシンボルの定義"
 604 バインディング内にデバッグコードを取り込む場合などに IDL ファイル内
 605 にコンパイル用のシンボルが定義されていないときは、それらのシンボル
 606 を定義する必要があることがあります。次のコマンド
 607 .LP
 608 .RS
 609 .ft 3
 610 .nf
 611 idlj -d MYDEF My.idl
 612 .fi
 613 .ft 1
 614 .RE
 615 .LP
 616 は、My.idl 内に 
 617 .BR #define
 618 .BR MYDEF
 619 という行を含めるのと同じです。
 620 .SH "既存のバインディングの保持"
 621 Java バインディングファイルが既に存在する場合は、
 622 .BI \-keep 
 623 フラグを使用してコンパイラによる上書きを防止できます。デフォルトでは、
 624 既に存在するかどうかにかかわらずすべてのファイルが生成されます。
 625 ファイルをカスタマイズ (カスタマイズはその内容がよほど適切でない限り推奨
 626 されません) してある場合は、
 627 .BI \-keep 
 628 オプションが非常に役立ちます。次のコマンド
 629 .LP
 630 .RS
 631 .ft 3
 632 .nf
 633 idlj -keep My.idl
 634 .fi
 635 .ft 1
 636 .RE
 637 .LP
 638 は、まだ存在していないすべてのクライアント側バインディングを発行します。
 639 .SH "コンパイルの進捗の表示"
 640 IDL-to-Java コンパイラは、その実行段階でステータスメッセージを
 641 生成します。この生成を詳細 (verbose) モードにするには、
 642 .BR -v
 643 オプションを使用してください。
 644 .LP
 645 .RS
 646 .ft 3
 647 .nf
 648 idlj -v My.idl
 649 .fi
 650 .ft 1
 651 .RE
 652 .LP
 653 デフォルトでは、コンパイラは詳細モードで動作しません。
 654 .SH "バージョン情報の表示"
 655 IDL-to-Java コンパイラのビルドバージョンを表示するには、コマンド行で
 656 .BI \-version
 657 オプションを指定してください。
 658 .LP
 659 .RS
 660 .ft 3
 661 .nf
 662 idlj -version 
 663 .fi
 664 .ft 1
 665 .RE
 666 .LP
 667 コンパイラが生成したバインディング内に、バージョン情報も表示されます。
 668 コマンド行に指定されるその他のオプションは無視されます。
 669 .SH "オプション"
 670 .TP
 671 .BI \-d " symbol"
 672 これは、IDL ファイルに次の行を指定するのと同じです。
 673 .LP
 674 .RS
 675 .ft 3
 676 .nf
 677 #define symbol
 678 .fi
 679 .ft 1
 680 .RE
 681 .TP
 682 .BI \-emitAll
 683 .BR #include
 684 ファイル内に指定されているものも含め、すべてのタイプを発行します。
 685 .TP
 686 .BI \-fside
 687 発行するバインディングを定義します。
 688 .BI side
 689 には、
 690 .BR client
 691 、
 692 .BR server
 693 、
 694 .BR serverTIE
 695 、
 696 .BR all
 697 、
 698 .BR allTIE
 699 のうちいずれか 1 つを指定します。
 700 .BR -fserverTIE
 701 と 
 702 .BR -fallTIE
 703 オプションを指定すると、委譲モデルスケルトンが発行されます。
 704 フラグを指定しない場合は、
 705 .BR -fclient
 706 と見なされます。
 707 .TP
 708 .BI \-i " include-path"
 709 デフォルトでは、現在のディレクトリでインクルードファイルが
 710 検索されます。このオプションを使用すると、ほかのディレクトリを
 711 追加できます。 
 712 .TP
 713 .BI \-keep
 714 生成されるファイルが既に存在する場合、既存ファイルを上書きしません。
 715 デフォルトでは、既存ファイルが上書きされます。
 716 .TP
 717 .BI \-noWarn
 718 警告メッセージを表示しないようにします。
 719 .TP
 720 .BI \-oldImplBase
 721 1.4 より前の JDK ORB と互換性のあるスケルトンを生成します。
 722 デフォルトでは、POA 継承モデルのサーバ側バインディングが生成されます。
 723 このオプションは、
 724 .BR ImplBase
 725 継承モデルクラスであるサーバ側バインディングを生成することによって、
 726 旧バージョンの Java プログラミング言語との下位互換性を提供します。
 727 .TP
 728 .BI \-pkgPrefix " type prefix"
 729 ファイルスコープで 
 730 .BI type 
 731 が検出された場合、そのタイプに対して生成されるすべてのファイルについて、
 732 生成される Java パッケージ名に
 733 .BI prefix 
 734 という接頭辞を付けます。
 735 .BI type 
 736 は、トップレベルモジュールの単純名か、モジュールの外部で定義された 
 737 IDL タイプの単純名です。
 738 .TP
 739 .BI \-pkgTranslate " type package"
 740 特定の識別子内でモジュール名 \f2type\fP が見つかった場合、生成された Java パッケージ内のすべてのファイルに対して、その識別子内のモジュール名を \f2package\fP で置き換えます。
 741 .BR pkgPrefix 
 742 変更が初めに行われることに注意してください。
 743 .BI type 
 744 はトップレベルモジュールの単純名か、モジュールの外部で定義された IDL タイプの
 745 単純名のいずれかであり、パッケージのフルネームと正確に一致する必要があります。
 746 
 747 .LP
 748 特定の識別子に一致する変換が 2 つ以上見つかった場合、もっとも長い一致が選択されます。たとえば、引数を次のように指定したとします。
 749 .nf
 750 \f3
 751 .fl
 752   \-pkgTranslate foo bar \-pkgTranslate foo.baz buzz.fizz
 753 .fl
 754 \fP
 755 .fi
 756 .LP
 757 このとき、次の変換が実行されます。
 758 .nf
 759 \f3
 760 .fl
 761 foo          => bar
 762 .fl
 763 foo.boo      => bar.boo
 764 .fl
 765 foo.baz      => buzz.fizz
 766 .fl
 767 foo.baz.bar  => buzz.fizz.bar
 768 .fl
 769 \fP
 770 .fi
 771 .LP
 772 次のパッケージ名は変換できません。
 773 .RS 3
 774 .TP 2
 775 *
 776 \f2org\fP 
 777 .TP 2
 778 *
 779 \f2org.omg\fP または \f2org.omg\fP のサブパッケージ
 780 .RE
 781 .LP
 782 これらのパッケージの変換を試みると、コンパイル不可能なコードが生成されます。
 783 これらのパッケージを 
 784 .BR \-pkgTranslate
 785 の後の最初の引数として使用すると、エラーとして扱われます。
 786 .RE
 787 .TP
 788 .BI \-skeletonName " xxx%yyy"
 789 .BI xxx%yyy
 790 をスケルトンの名前付けのパターンとして使用します。デフォルトは次のとおりです。
 791 .LP
 792 .RS
 793 .TP 2
 794 \(bu POA 基底クラス 
 795 (
 796 .BR \-fserver
 797 または
 798 .BR \-fall
 799 ) の場合、%POA
 800 .TP 2
 801 \(bu 
 802 .BR \-oldImplBase
 803 クラス (
 804 .BR \-oldImplBase
 805 および、
 806 .BR \-fserver
 807 または
 808 .BR \-fall
 809 ) の場合、_%ImplBase
 810 .RE
 811 .TP
 812 .BI \-td " dir"
 813 出力ディレクトリとして、現在のディレクトリではなく
 814 .BI dir
 815 を使用します。
 816 .TP
 817 .BI \-tieName " xxx%yyy"
 818 パターンに応じて Tie に名前を付けます。デフォルトは次のとおりです。
 819 .LP
 820 .RS
 821 .TP 2
 822 \(bu POA Tie 基底クラス (
 823 .BR \-fserverTie
 824 または 
 825 .BR \-fallTie
 826 ) の場合、%POATie
 827 .TP 2
 828 \(bu 
 829 .BR oldImplBase Tie
 830 クラス (
 831 .BR \-oldImplBase
 832 および、
 833 .BR \-fserverTie
 834 または
 835 .BR \-fallTie
 836 のいずれか) の場合、%_Tie
 837 .RE
 838 .TP
 839 .BI \-nowarn, \-verbose
 840 詳細モードにします。
 841 .TP
 842 .BI \-version
 843 バージョン情報を表示して終了します。
 844 .LP
 845 オプションの詳細は、「機能説明」の節を参照してください。
 846 .SH "制限事項"
 847 .LP
 848 .TP 2
 849 \(bu グローバルスコープ内でエスケープされた識別子は、
 850 IDL プリミティブ型 (
 851 .BR Object 
 852 または 
 853 .BR ValueBase
 854 ) と同じスペルであってはなりません。これは、シンボルテーブルがこれらの
 855 識別子を使用してすでにロードされているためです。これらを定義し直すと、
 856 それらの本来の定義を上書きすることになります (この制限は永続的に
 857 適用される見込み)。
 858 .TP 2
 859 \(bu IDL の fixed 型はサポートされていません。
 860 .SH "既知の問題"
 861 .LP
 862 
 863 .LP
 864 .RS 3
 865 .TP 2
 866 *
 867 グローバル識別子のインポートは生成されません。エクスポートされていないローカル実装を呼び出すと例外が発生しますが、その原因はおそらく \f2ServerDelegate\fP DSI コード内の \f2NullPointerException\fP です。
 868 .RE
 869 
 870 .LP
 871 
 872 .LP
 873