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