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