--- a/jdk/src/linux/doc/man/ja/idlj.1 Mon Jul 27 19:50:14 2015 +0200
+++ b/jdk/src/linux/doc/man/ja/idlj.1 Mon Jul 27 16:49:10 2015 -0700
@@ -1,12 +1,5 @@
'\" t
-.\" Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved.
-.\" Title: idlj
-.\" Language: English
-.\" Date: 2013年11月21日
-.\" SectDesc: Java IDLおよびRMI-IIOPツール
-.\" Software: JDK 8
-.\" Arch: 汎用
-.\"
+.\" Copyright (c) 2001, 2014, Oracle and/or its affiliates. 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
@@ -15,7 +8,7 @@
.\"
.\" 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
+.\" 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).
.\"
@@ -27,8 +20,17 @@
.\" or visit www.oracle.com if you need additional information or have any
.\" questions.
.\"
-.pl 99999
-.TH "idlj" "1" "2013年11月21日" "JDK 8" "Java IDLおよびRMI-IIOPツール"
+.\" Title: idlj
+.\" Language: Japanese
+.\" Date: 2013ǯ1121
+.\" SectDesc: Java IDLRMI-IIOPġ
+.\" Software: JDK 8
+.\" Arch:
+.\" Part Number: E58103-01
+.\" Doc ID: JSSON
+.\"
+.if n .pl 99999
+.TH "idlj" "1" "2013ǯ1121" "JDK 8" "Java IDLRMI-IIOPġ"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
@@ -48,15 +50,15 @@
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
-.SH "NAME"
-idlj \- 指定されたインタフェース定義言語(IDL)ファイルに対してJavaバインディングを生成します。
-.SH "概要"
+.SH "̾"
+idlj \- ꤵ줿ե(IDL)եФJavaХǥޤ
+.SH ""
.sp
.if n \{\
.RS 4
.\}
.nf
-\fIidlj\fR [ \fIoptions\fR ] \fIidlfile\fR
+\fBidlj\fR [ \fIoptions\fR ] \fIidlfile\fR
.fi
.if n \{\
.RE
@@ -64,378 +66,368 @@
.PP
\fIoptions\fR
.RS 4
-コマンドライン・オプション。オプションを参照してください。optionsの順番は任意ですが、\fIidlfile\fRよりも前に指定する必要があります。
+ޥɹԥץץȤƤoptionsν֤ǤդǤ\fBidlfile\fR˻ꤹɬפޤ
.RE
.PP
\fIidlfile\fR
.RS 4
-インタフェース定義言語(IDL)による定義が含まれるファイルの名前。
+ե(IDL)ˤޤޤե̾
.RE
-.SH "説明"
+.SH ""
.PP
-IDL\-to\-Javaコンパイラは、指定されたIDLファイルに対してJavaバインディングを生成します。バインディングの詳細は、http://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping\&.htmlにある
-Java IDL: Java言語マッピングへのIDLを参照してください。
+IDL\-to\-Javaѥϡꤵ줿IDLեФJavaХǥޤХǥξܺ٤ϡhttp://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping\&.htmlˤ
+Java IDL: JavaޥåԥؤIDLȤƤ
.PP
-IDL\-to\-Javaコンパイラの以前のリリースの中には、\fIidltojava\fRという名前だったものがあります。
-.SS "クライアント・バインディングおよびサーバー・バインディングの発行"
+IDL\-to\-JavaѥΰΥˤϡ\fBidltojava\fRȤ̾äΤޤ
+.SS "饤ȡХǥӥСХǥȯ"
.PP
-次の\fIidlj\fRコマンドは、クライアント側バインディングを含む\fIMy\&.idl\fRという名前のIDLファイルを生成します。
+\fBidlj\fRޥɤϡ饤¦Хǥޤ\fBMy\&.idl\fRȤ̾IDLեޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj My\&.idl
+\fBidlj My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-前の構文は次と同等です。
+ιʸϼƱǤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-fclient My\&.idl
+\fBidlj \-fclient My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-次の例では、サーバー側バインディングを生成し、クライアント側バインディングおよびスケルトンを含めており、これらはすべて、POA (継承モデル)です。
+ǤϡС¦Хǥ饤¦ХǥӥȥޤƤꡢϤ٤ơPOA (Ѿǥ)Ǥ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlg \-fserver My\&.idl
+\fBidlg \-fserver My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-クライアント側とサーバー側の両方のバインディングを生成する場合は、次のコマンド(どれも等価)のうちの1つを使用します。
+饤¦ȥС¦ξΥХǥϡΥޥ(ɤ)Τ1ĤѤޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-fclient \-fserver My\&.idl
-idlj \-fall My\&.idl
+\fBidlj \-fclient \-fserver My\&.idl\fR
+\fBidlj \-fall My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-サーバー側で可能なモデルは2つあります。移殖可能サーバント継承モデルとTieモデルです。Tie委譲モデルを参照してください。
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fB移殖可能サーバント継承モデル\fR
-.ps -1
-.br
+С¦Dzǽʥǥ2ĤޤܿǽХȷѾǥTieǥǤTieѾǥȤƤ
+.PP
+\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ˤ
+\fBorg\&.omg\&.PortableServer\&.Servant\fR饹ĥ륹ȥ١ΥȥǤ
+.PP
+\fBMy\fRեϡȥIDLե˴ϢդƤ\fBcallHandler\fRեեޤ
.PP
-デフォルトのサーバー側のモデルは、移殖可能サーバント継承モデルです。\fIMy\&.idl\fR内で\fIMy\fRインタフェースが定義されている場合は、\fIMyPOA\&.java\fRというファイルが生成されます。\fIMy\fRインタフェースの実装を提供する必要があり、\fIMy\fRインタフェースは\fIMyPOA\fRクラスから継承する必要があります。\fIMyPOA\&.java\fRは、http://docs\&.oracle\&.com/javase/8/docs/api/org/omg/PortableServer/Servant\&.htmlにある
-\fIorg\&.omg\&.PortableServer\&.Servant\fRクラスを拡張するストリームベースのスケルトンです。
-.PP
-\fIMy\fRインタフェースは、スケルトンが実装するIDLインタフェースに関連付けられている\fIcallHandler\fRインタフェースと操作インタフェースを実装します。
+ݡ֥롦֥ȡץ(POA)\fBPortableServer\fR⥸塼ϡͥƥ֤\fBServant\fRޤhttp://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/POA\&.htmlˤ
+ݡ֥롦֥ȡץ(POA)ȤƤ
.PP
-ポータブル・オブジェクト・アダプタ(POA)の\fIPortableServer\fRモジュールは、ネイティブの\fIServant\fR型を定義します。http://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/POA\&.htmlにある
-ポータブル・オブジェクト・アダプタ(POA)を参照してください。
+JavaץߥǤϡ\fBServant\fRJava\fBorg\&.omg\&.PortableServer\&.Servant\fR饹˥ޥåפޤϡ٤ƤPOAХȼΥ١饹ȤƵǽץꥱץޤƤӽФȤΤǤ뤤ĤΥåɡPOAˤäƸƤӽФ졢ХȤư椹뤿˥桼С饤ɤǤåɤޤ
.PP
-Javaプログラミング言語では、\fIServant\fR型はJavaの\fIorg\&.omg\&.PortableServer\&.Servant\fRクラスにマップされます。これは、すべてのPOAサーバント実装のベース・クラスとして機能し、アプリケーション・プログラマが呼び出すことのできるいくつかのメソッド、およびPOAによって呼び出され、サーバントの動作を制御するためにユーザーがオーバーライドできるメソッドを提供します。
-.PP
-継承モデルのもう1つのオプションは、\fI\-oldImplBase\fRフラグを使用して、Java SE 1\&.4より前のリリースのJavaプログラミング言語と互換性のあるサーバー側バインディングを生成することです。\-\fIoldImplBase\fRフラグは非標準で、これらのAPIは非推奨です。このフラグを使用するのは、Java SE 1\&.3で記述された既存のサーバーとの互換性が必要な場合のみです。その場合、既存のmakeファイルを変更して、\fI\-oldImplBase\fRフラグを\fIidlj\fRコンパイラに追加する必要があります。それ以外の場合、POAベースのサーバー側マッピングが生成されます。下位互換性のあるサーバー側バインディングを生成するには、次を実行します。
-.sp .5v
-.RE
+ѾǥΤ⤦1ĤΥץϡ\fB\-oldImplBase\fRե饰ѤơJava SE 1\&.4ΥJavaץߥȸߴΤ륵С¦Хǥ뤳ȤǤ\-\fBoldImplBase\fRե饰ɸǡAPI侩ǤΥե饰ѤΤϡJava SE 1\&.3ǵҤ줿¸ΥСȤθߴɬפʾΤߤǤξ硢¸makeեѹơ\fB\-oldImplBase\fRե饰\fBidlj\fRѥɲäɬפޤʳξ硢POA١ΥС¦ޥåԥޤߴΤ륵С¦Хǥˤϡ¹Ԥޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-fclient \-fserver \-oldImplBase My\&.idl
-idlj \-fall \-oldImplBase My\&.idl
+\fBidlj \-fclient \-fserver \-oldImplBase My\&.idl\fR
+\fBidlj \-fall \-oldImplBase My\&.idl\fR
+
+.fi
+.if n \{\
+.RE
+.\}
+.PP
+\fBMy\&.idl\fR\fBMy\fRեƤϡ\fB_MyImplBase\&.java\fRȤե뤬ޤ\fBMy\fRեμɬפꡢ\fBMy\fRե\fB_MyImplBase\fR饹Ѿɬפޤ
+.PP
+\fBTieѾǥ\fR. ⤦1ĤΥС¦ǥϡTieǥȸƤФΤǤΥС¦ǥϡѾǥǤTieȥȥƱ뤳ȤϤǤʤᡢ̡ɬפޤΥޥɤˤäơTieǥѤΥХǥޤ
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+\fBidlj \-fall My\&.idl\fR
+\fBidlj \-fallTIE My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-\fIMy\&.idl\fR内で\fIMy\fRインタフェースが定義されている場合は、\fI_MyImplBase\&.java\fRというファイルが生成されます。\fIMy\fRインタフェースの実装を提供する必要があり、\fIMy\fRインタフェースは\fI_MyImplBase\fRクラスから継承する必要があります。
-.if n \{\
-.sp
-.\}
-.RS 4
-.it 1 an-trap
-.nr an-no-space-flag 1
-.nr an-break-flag 1
-.br
-.ps +1
-\fBTie委譲モデル\fR
-.ps -1
-.br
-.PP
-もう1つのサーバー側モデルは、Tieモデルと呼ばれるものです。このサーバー側モデルは、委譲モデルです。Tieとスケルトンを同時に生成することはできないため、それらは別々に生成する必要があります。次のコマンドによって、Tieモデル用のバインディングが生成されます。
-.sp .5v
-.RE
-.sp
-.if n \{\
-.RS 4
-.\}
-.nf
-idlj \-fall My\&.idl
-idlj \-fallTIE My\&.idl
-.fi
-.if n \{\
-.RE
-.\}
-.PP
-\fIMy\fRインタフェースの場合、2番目のコマンドにより、\fIMyPOATie\&.java\fRが生成されます。\fIMyPOATie\fRクラスへのコンストラクタは、delegateを取ります。この例では、デフォルトのPOAモデルを使用しているため、コンストラクタにもPOAが必要です。delegateに対して実装を提供する必要がありますが、この実装は\fIMyOperations\fRインタフェースから継承する必要があるのみで、その他のクラスから継承する必要はありません。これをORBと一緒に使用するには、たとえば次のように\fIMyPOATie\fRクラス内で実装をラップする必要があります。
+\fBMy\fRեξ硢2ܤΥޥɤˤꡢ\fBMyPOATie\&.java\fRޤ\fBMyPOATie\fR饹ؤΥȥ饯ϡdelegateޤǤϡǥեȤPOAǥѤƤ뤿ᡢȥ饯ˤPOAɬפǤdelegateФƼɬפޤμ\fBMyOperations\fRեѾɬפΤߤǡ¾Υ饹ѾɬפϤޤORBȰ˻ѤˤϡȤмΤ褦\fBMyPOATie\fR饹Ǽåפɬפޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-ORB orb = ORB\&.init(args, System\&.getProperties());
-
-// Get reference to rootpoa & activate the POAManager
-POA rootpoa = (POA)orb\&.resolve_initial_references("RootPOA");
-rootpoa\&.the_POAManager()\&.activate();
+\fBORB orb = ORB\&.init(args, System\&.getProperties());\fR
+\fB \fR
+\fB// Get reference to rootpoa & activate the POAManager\fR
+\fBPOA rootpoa = (POA)orb\&.resolve_initial_references("RootPOA");\fR
+\fBrootpoa\&.the_POAManager()\&.activate();\fR
+\fB \fR
+\fB// create servant and register it with the ORB\fR
+\fBMyServant myDelegate = new MyServant();\fR
+\fBmyDelegate\&.setORB(orb); \fR
+\fB \fR
+\fB// create a tie, with servant being the delegate\&.\fR
+\fBMyPOATie tie = new MyPOATie(myDelegate, rootpoa);\fR
+\fB \fR
+\fB// obtain the objectRef for the tie\fR
+\fBMy ref = tie\&._this(orb);\fR
-// create servant and register it with the ORB
-MyServant myDelegate = new MyServant();
-myDelegate\&.setORB(orb);
-
-// create a tie, with servant being the delegate\&.
-MyPOATie tie = new MyPOATie(myDelegate, rootpoa);
-
-// obtain the objectRef for the tie
-My ref = tie\&._this(orb);
.fi
.if n \{\
.RE
.\}
.PP
-他の実装から継承する必要がある場合、標準の継承モデルではなくTieモデルを使用することもできます。Javaの場合は、インタフェースの継承の個数に制限はありませんが、クラスの継承に使用できるスロットは1つのみです。継承モデルを使用した場合は、そのスロットが占有されます。Tieモデルを使用すると、そのスロットが使用されず、ユーザーが独自の目的で使用できます。この方法には、間接性のレベルが1つ導入されるという短所があります。メソッドを呼び出すときに、余分なメソッド呼出しが1回発生します。
+¾μѾɬפ硢ɸηѾǥǤϤʤTieǥѤ뤳ȤǤޤJavaξϡեηѾθĿ¤Ϥޤ饹ηѾ˻ѤǤ륹åȤ1ĤΤߤǤѾǥѤϡΥåȤͭޤTieǥѤȡΥåȤѤ줺桼ȼŪǻѤǤޤˡˤϡΥ٥뤬1ƳȤû꤬ޤåɤƤӽФȤˡ;ʬʥåɸƽФ1ȯޤ
.PP
-サーバー側の生成の場合、Java SE 1\&.4より前のバージョンのJava言語にマッピングするIDLのバージョンと互換性のある、Tieモデルのバインディングです。
+С¦ξ硢Java SE 1\&.4ΥСJava˥ޥåԥIDLΥСȸߴΤ롢TieǥΥХǥǤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-oldImplBase \-fall My\&.idl
-idlj \-oldImplBase \-fallTIE My\&.idl
+\fBidlj \-oldImplBase \-fall My\&.idl\fR
+\fBidlj \-oldImplBase \-fallTIE My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-\fIMy\fRインタフェースの場合、これにより、\fIMy_Tie\&.java\fRが生成されます。\fIMy_Tie\fRクラスへのコンストラクタは、\fIimpl\fRオブジェクトを取ります。\fIimpl\fRに対して実装を提供する必要がありますが、その実装は\fIHelloOperations\fRインタフェースから継承する必要があるのみで、その他のクラスから継承する必要はありません。しかし、これをORBと一緒に使用するには、たとえば次のように\fIMy_Tie\fR内で実装をラップする必要があります。
+\fBMy\fRեξ硢ˤꡢ\fBMy_Tie\&.java\fRޤ\fBMy_Tie\fR饹ؤΥȥ饯ϡ\fBimpl\fR֥Ȥޤ\fBimpl\fRФƼɬפޤμ\fBHelloOperations\fRեѾɬפΤߤǡ¾Υ饹ѾɬפϤޤORBȰ˻ѤˤϡȤмΤ褦\fBMy_Tie\fRǼåפɬפޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-ORB orb = ORB\&.init(args, System\&.getProperties());
-
-// create servant and register it with the ORB
-MyServant myDelegate = new MyServant();
-myDelegate\&.setORB(orb);
+\fBORB orb = ORB\&.init(args, System\&.getProperties());\fR
-// create a tie, with servant being the delegate\&.
-MyPOATie tie = new MyPOATie(myDelegate);
+\fB// create servant and register it with the ORB\fR
+\fBMyServant myDelegate = new MyServant();\fR
+\fBmyDelegate\&.setORB(orb); \fR
+\fB \fR
+\fB// create a tie, with servant being the delegate\&.\fR
+\fBMyPOATie tie = new MyPOATie(myDelegate);\fR
+\fB \fR
+\fB// obtain the objectRef for the tie\fR
+\fBMy ref = tie\&._this(orb);\fR
-// obtain the objectRef for the tie
-My ref = tie\&._this(orb);
.fi
.if n \{\
.RE
.\}
-.SS "発行されたファイルの代替位置の指定"
+.SS "ȯԤ줿եذ֤λ"
.PP
-発行されたファイルを現在のディレクトリ以外のディレクトリに置くには、\fIi\fR\fIdlj \-td /altdir My\&.idl\fRのコマンドでコンパイラを呼び出します。
+ȯԤ줿եߤΥǥ쥯ȥʳΥǥ쥯ȥ֤ˤϡ\fBi\fR\fBdlj \-td /altdir My\&.idl\fRΥޥɤǥѥƤӽФޤ
.PP
-\fIMy\fRインタフェースの場合、バインディングは、\fI\&./My\&.java\fRではなく、\fI/altdir/My\&.java\fRなどに発行されます。
-.SS "インクルード・ファイルの代替位置の指定"
+\fBMy\fRեξ硢Хǥϡ\fB\&./My\&.java\fRǤϤʤ\fB/altdir/My\&.java\fRʤɤȯԤޤ
+.SS "롼ɡեذ֤λ"
.PP
-\fIMy\&.idl\fRファイルが別の\fIidl\fRファイルである\fIMyOther\&.idl\fRをインクルードする場合、コンパイラでは、\fIMyOther\&.idl\fRファイルがローカル・ディレクトリに存在することを前提としています。たとえば、それが\fI/includes\fRにある場合は、次のようなコマンドでコンパイラを呼び出します。
+\fBMy\&.idl\fRե뤬̤\fBidl\fRեǤ\fBMyOther\&.idl\fR롼ɤ硢ѥǤϡ\fBMyOther\&.idl\fRե뤬롦ǥ쥯ȥ¸ߤ뤳ȤȤƤޤȤС줬\fB/includes\fRˤϡΤ褦ʥޥɤǥѥƤӽФޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-i /includes My\&.idl
+\fBidlj \-i /includes My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-たとえば、\fI/moreIncludes\fRにある\fIAnother\&.idl\fRも\fIMy\&.idl\fRにインクルードされているのであれば、次のようなコマンドでコンパイラを呼び出します。
+ȤС\fB/moreIncludes\fRˤ\fBAnother\&.idl\fR\fBMy\&.idl\fR˥롼ɤƤΤǤСΤ褦ʥޥɤǥѥƤӽФޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-i /includes \-i /moreIncludes My\&.idl
+\fBidlj \-i /includes \-i /moreIncludes My\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-このような形式の\fIinclude\fRは長くなるため、インクルード・ファイルを検索する場所をコンパイラに指示するための別の方法が用意されています。この方法は、環境変数の考え方と似ています。\fICLASSPATH\fR変数に一覧表示されているディレクトリ内にidl\&.configという名前のファイルを作成します。その\fIidl\&.config\fRの中に、次のような形式の行を入れます。
+Τ褦ʷ\fBinclude\fRĹʤ뤿ᡢ롼ɡեѥ˻ؼ뤿̤ˡѰդƤޤˡϡĶѿιͤȻƤޤ\fBCLASSPATH\fRѿ˰ɽƤǥ쥯ȥidl\&.configȤ̾Υեޤ\fBidl\&.config\fRˡΤ褦ʷιԤޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-includes=/includes;/moreIncludes
+\fBincludes=/includes;/moreIncludes\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-コンパイラは、このファイルを検索し、インクルード・リストを読み込みます。この例では、ディレクトリの間の区切り文字はセミコロン(;)になっています。この区切り文字は、プラットフォームによって異なります。Windowsプラットフォームではセミコロンを使用し、UNIXプラットフォームではコロンを使用するなどです。
-.SS "インクルード・ファイルに対するバインディングの発行"
+ѥϡΥե롼ɡꥹȤɤ߹ߤޤǤϡǥ쥯ȥδ֤ζڤʸϥߥ(;)ˤʤäƤޤζڤʸϡץåȥեˤäưۤʤޤWindowsץåȥեǤϥߥѤSolarisLinuxOS XץåȥեǤϥѤޤ
+.SS "롼ɡեФХǥȯ"
.PP
-デフォルトでは、コマンドラインに指定した\fIidl\fRファイルで定義されているインタフェースや構造体などについてのみ、Javaバインディングが生成されます。インクルードされたファイルで定義されている型については生成されません。たとえば、次の2つの\fIidl\fRファイルについて考えてみます。
+ǥեȤǤϡޥɹԤ˻ꤷ\fBidl\fRեƤ륤ե乽¤ΤʤɤˤĤƤΤߡJavaХǥޤ롼ɤ줿եƤ뷿ˤĤƤޤȤС2Ĥ\fBidl\fRեˤĤƹͤƤߤޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-My\&.idl file:
+\fBMy\&.idl file:\fR
+\fB \fR
+\fB#include <MyOther\&.idl>\fR
+\fBinterface My\fR
+\fB{\fR
+\fB};\fR
+\fB \fR
+\fBMyOther\&.idl file:\fR
+\fB \fR
+\fBinterface MyOther\fR
+\fB{\fR
+\fB};\fR
-#include <MyOther\&.idl>
-interface My
-{
-};
-
-MyOther\&.idl file:
-
-interface MyOther
-{
-};
.fi
.if n \{\
.RE
.\}
.PP
-デフォルトのルールに関して警告があります。グローバル・スコープに表示される\fI#include\fR文は、前述のとおりに処理されます。これらの\fI#include\fR文は、インポート文と見なすことができます。囲まれたスコープ内に表示される\fI#include\fR文は、本当の意味での\fI#include\fR文として処理されます。つまり、インクルードされたファイルにあるコードが、元のファイルにそのまま表示されているかのように処理され、それに対してJavaバインディングが発行されます。次はその例です。
+ǥեȤΥ롼˴ؤƷٹ𤬤ޤХ롦פɽ\fB#include\fRʸϡҤΤȤ˽ޤ\fB#include\fRʸϡݡʸȸʤȤǤޤϤޤ줿ɽ\fB#include\fRʸϡΰ̣Ǥ\fB#include\fRʸȤƽޤĤޤꡢ롼ɤ줿եˤ륳ɤΥեˤΤޤɽƤ뤫Τ褦˽졢ФJavaХǥȯԤޤϤǤ
.sp
.if n \{\
.RS 4
.\}
.nf
-My\&.idl file:
-
-#include <MyOther\&.idl>
-interface My
-{
- #include <Embedded\&.idl>
-};
+\fBMy\&.idl file:\fR
+\fB \fR
+\fB#include <MyOther\&.idl>\fR
+\fBinterface My\fR
+\fB{\fR
+\fB #include <Embedded\&.idl>\fR
+\fB};\fR
+\fB \fR
+\fBMyOther\&.idl file:\fR
+\fB \fR
+\fBinterface MyOther\fR
+\fB{\fR
+\fB};\fR
+\fB \fR
+\fBEmbedded\&.idl\fR
+\fB \fR
+\fBenum E {one, two, three};\fR
-MyOther\&.idl file:
-
-interface MyOther
-{
-};
-
-Embedded\&.idl
-
-enum E {one, two, three};
.fi
.if n \{\
.RE
.\}
.PP
-\fI idlj My\&.idl \fRを実行して、Javaファイルの次のリストを生成します。インポート文とみなされる\fI#include\fRに定義されていたため、\fIMyOther\&.java\fRは生成されませんでした。ただし、本当の意味での\fI#include\fRで定義されていたため、\fIE\&.java\fRは生成されました。\fIEmbedded\&.idl\fRファイルが\fIMy\fRインタフェースのスコープ内にインクルードされているため、\fIMy\fRのスコープ内(つまり、\fIMyPackage\fR内)に生成されています。\fI\-emitAll\fRフラグを使用した場合、インクルードされたすべてのファイルにあるすべての型が発行されます。
+\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ե饰Ѥ硢롼ɤ줿٤ƤΥեˤ뤹٤ƤηȯԤޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-\&./MyHolder\&.java
-\&./MyHelper\&.java
-\&./_MyStub\&.java
-\&./MyPackage
-\&./MyPackage/EHolder\&.java
-\&./MyPackage/EHelper\&.java
-\&./MyPackage/E\&.java
-\&./My\&.java
+\fB\&./MyHolder\&.java\fR
+\fB\&./MyHelper\&.java\fR
+\fB\&./_MyStub\&.java\fR
+\fB\&./MyPackage\fR
+\fB\&./MyPackage/EHolder\&.java\fR
+\fB\&./MyPackage/EHelper\&.java\fR
+\fB\&./MyPackage/E\&.java\fR
+\fB\&./My\&.java\fR
+
.fi
.if n \{\
.RE
.\}
-.SS "パッケージの接頭辞の挿入"
+.SS "ѥåƬ"
.PP
-ABCという名前の会社のために作業していて、次のようなIDLファイルを構築したとしましょう。
+ABCȤ̾βҤΤ˺ȤƤơΤ褦IDLեۤȤޤ礦
.sp
.if n \{\
.RS 4
.\}
.nf
-Widgets\&.idl file:
+\fBWidgets\&.idl file:\fR
+\fB \fR
+\fBmodule Widgets\fR
+\fB{\fR
+\fB interface W1 {\&.\&.\&.};\fR
+\fB interface W2 {\&.\&.\&.};\fR
+\fB};\fR
-module Widgets
-{
- interface W1 {\&.\&.\&.};
- interface W2 {\&.\&.\&.};
-};
.fi
.if n \{\
.RE
.\}
.PP
-IDL\-to\-Javaコンパイラを介してこのファイルを実行した場合、W1およびW2に対するJavaバインディングは、\fIWidgets\fRパッケージ内に格納されます。業界の慣例によると、会社のパッケージは、\fIcom\&.<company name>\fRという名前のパッケージ内に置くことになっています。この慣例に従うには、パッケージ名を\fIcom\&.abc\&.Widgets\fRにする必要があります。このパッケージ接頭辞をWidgetsモジュールに付加するには、次のコマンドを実行します。
+IDL\-to\-Javaѥ𤷤ƤΥե¹Ԥ硢W1W2ФJavaХǥϡ\fBWidgets\fRѥå˳ǼޤȳδˤȡҤΥѥåϡ\fBcom\&.<company name>\fRȤ̾Υѥå֤ȤˤʤäƤޤδ˽ˤϡѥå̾\fBcom\&.abc\&.Widgets\fRˤɬפޤΥѥåƬWidgets⥸塼ղäˤϡΥޥɤ¹Ԥޤ
.sp
.if n \{\
.RS 4
.\}
.nf
-idlj \-pkgPrefix Widgets com\&.abc Widgets\&.idl
+\fBidlj \-pkgPrefix Widgets com\&.abc Widgets\&.idl\fR
+
.fi
.if n \{\
.RE
.\}
.PP
-Widgets\&.idlをインクルードしているIDLファイルがある場合は、そのコマンドにも\fI\-pkgPrefix\fRフラグが必要です。このフラグを指定しないと、そのIDLファイルは、\fIcom\&.abc\&.Widgets\fRパッケージではなく、\fIWidgets\fRパッケージを検索することになります。
+Widgets\&.idl롼ɤƤIDLե뤬ϡΥޥɤˤ\fB\-pkgPrefix\fRե饰ɬפǤΥե饰ꤷʤȡIDLեϡ\fBcom\&.abc\&.Widgets\fRѥåǤϤʤ\fBWidgets\fRѥå뤳Ȥˤʤޤ
.PP
-接頭辞が必要なパッケージがいくつもある場合は、前述のidl\&.configファイルで接頭辞を指定するのが簡単です。パッケージ接頭辞の各行は、\fIPkgPrefix\&.<type>=<prefix>\fRの形式である必要があります。前述の例の行では、\fIPkgPrefix\&.Widgets=com\&.abc\fRになります。このオプションは、リポジトリIDには影響しません。
-.SS "コンパイル前のシンボルの定義"
+ƬɬפʥѥåĤ⤢ϡҤidl\&.configեƬꤹΤñǤƥѥåƬԤϡ\fBPkgPrefix\&.<type>=<prefix>\fRηˤɬפޤҤιԤǤϡ\fBPkgPrefix\&.Widgets=com\&.abc\fRˤʤޤΥץϡݥȥIDˤϱƶޤ
+.SS "ѥΥܥ"
.PP
-コンパイル用のシンボルがIDLファイル内で定義されていない場合は、そのシンボルを定義する必要があります。これは、たとえば、バインディング内にデバッグ・コードを組み入れるときに使用します。コマンド\fIidlj \-d MYDEF My\&.idl \fRは、My\&.idl内に行\fI#define MYDEF\fRを配置した場合と同等になります。
-.SS "既存のバインディングの保持"
+ѥѤΥܥ뤬IDLեƤʤϡΥܥɬפޤϡȤСХǥ˥ǥХåɤȤȤ˻Ѥޤޥ\fBidlj \-d MYDEF My\&.idl \fRϡMy\&.idl˹\fB#define MYDEF\fR֤Ʊˤʤޤ
+.SS "¸ΥХǥݻ"
.PP
-Javaバインディング・ファイルがすでに存在する場合は、\fI\-keep\fRフラグを指定すると、コンパイラによる上書きを回避できます。デフォルトでは、すでに存在するかどうかにかかわらず、すべてのファイルが生成されます。これらのファイルをカスタマイズした場合(ただし、それらの内容が正確であるとき以外はカスタマイズは避ける)、\fI\-keep\fRオプションは有用です。コマンド\fIidlj \-keep My\&.idl\fRは、すでに存在しないすべてのクライアント側バインディングを発行します。
-.SS "コンパイルの進捗状況の表示"
+JavaХǥե뤬Ǥ¸ߤϡ\fB\-keep\fRե饰ꤹȡѥˤǤޤǥեȤǤϡǤ¸ߤ뤫ɤˤ餺٤ƤΥե뤬ޤΥեޥ(ƤΤǤȤʳϥޥ)\fB\-keep\fRץͭѤǤޥ\fBidlj \-keep My\&.idl\fRϡǤ¸ߤʤ٤ƤΥ饤¦ХǥȯԤޤ
+.SS "ѥοĽɽ"
.PP
-IDL\-to\-Javaコンパイラは、実行の各段階で状態メッセージを生成します。\fI\-v\fRオプションを使用して、\fIidlj \-v My\&.idl\fRのような冗長モードをアクティブ化します。
+IDL\-to\-Javaѥϡ¹ԤγʳǾ֥åޤ\fB\-v\fRץѤơ\fBidlj \-v My\&.idl\fRΤ褦ʾĹ⡼ɤƥֲޤ
.PP
-デフォルトでは、コンパイラは冗長モードでは実行されません。
-.SS "バージョン情報の表示"
+ǥեȤǤϡѥϾĹ⡼ɤǤϼ¹Ԥޤ
+.SS "Сɽ"
.PP
-IDL\-to\-Javaコンパイラのビルド・バージョンを表示するには、コマンドライン\fIidlj \-version\fRで\fI\-version\fRオプションを指定します。
+IDL\-to\-JavaѥΥӥɡСɽˤϡޥɹ\fBidlj \-version\fR\fB\-version\fRץꤷޤ
.PP
-バージョン情報は、コンパイラによって生成されたバインディング内にも書き込まれています。このオプションをコマンドラインに指定すると、それ以外のオプションを指定しても、すべて無視されます。
-.SH "オプション"
+Сϡѥˤä줿ХǥˤޤƤޤΥץޥɹԤ˻ꤹȡʳΥץꤷƤ⡢٤̵뤵ޤ
+.SH "ץ"
.PP
\-d \fIsymbol\fR
.RS 4
-このオプションは、IDLファイルに次のような行を追加した場合と等価です。
+ΥץϡIDLե˼Τ褦ʹԤɲäǤ
.sp
.if n \{\
.RS 4
.\}
.nf
-#define \fIsymbol\fR
+\fB#define \fR\fB\fIsymbol\fR\fR
+
.fi
.if n \{\
.RE
@@ -444,111 +436,113 @@
.PP
\-demitAll
.RS 4
-\fI#include\fRファイル内で定義されているものも含めて、すべての型を発行します。
+\fB#include\fRեƤΤޤơ٤ƤηȯԤޤ
.RE
.PP
\-fside
.RS 4
-発行するバインディングを定義します。\fIside\fRパラメータには、\fIclient\fR、\fIserver\fR、\fIserverTIE\fR、\fIall\fRまたは\fIallTIE\fRを指定できます。\fI\-fserverTIE\fRまたは\fI\-fallTIE\fRオプションを指定すると、委譲モデル・スケルトンが発行されます。フラグを指定しない場合、\fI\-fclient\fRにデフォルト設定されます。
+ȯԤХǥޤ\fBside\fRѥˤϡ\fBclient\fR\fBserver\fR\fBserverTIE\fR\fBall\fRޤ\fBallTIE\fRǤޤ\fB\-fserverTIE\fRޤ\fB\-fallTIE\fRץꤹȡѾǥ롦ȥȯԤޤե饰ꤷʤ硢\fB\-fclient\fR˥ǥեꤵޤ
.RE
.PP
\-i \fIinclude\-path\fR
.RS 4
-デフォルトでは、インクルード・ファイルは現在のディレクトリから検索されます。このオプションを指定すると、他のディレクトリを追加できます。
+ǥեȤǤϡ롼ɡեϸߤΥǥ쥯ȥ꤫鸡ޤΥץꤹȡ¾Υǥ쥯ȥɲäǤޤ
.RE
.PP
\-i \fIkeep\fR
.RS 4
-生成されるファイルがすでに存在している場合は、そのファイルが上書きされません。デフォルトでは、上書きされます。
+ե뤬Ǥ¸ߤƤϡΥե뤬ޤǥեȤǤϡޤ
.RE
.PP
\-noWarn
.RS 4
-警告メッセージを表示しないようにします。
+ٹåɽʤ褦ˤޤ
.RE
.PP
\-oldImplBase
.RS 4
-1\&.4より前のJDK ORBと互換性のあるスケルトンを生成します。デフォルトでは、POA継承モデルのサーバー側バインディングが生成されます。このオプションを指定すると、\fIImplBase\fR継承モデルのクラスであるサーバー側バインディングが生成されるので、以前のリリースのJavaプログラミング言語との下位互換性が得られます。
+1\&.4JDK ORBȸߴΤ륹ȥޤǥեȤǤϡPOAѾǥΥС¦ХǥޤΥץꤹȡ\fBImplBase\fRѾǥΥ饹Ǥ륵С¦ХǥΤǡΥJavaץߥȤθߴޤ
.RE
.PP
\-pkgPrefix \fItype\fR \fIprefix\fR
.RS 4
-\fItype\fRがファイル・スコープで検出された場合は、その型に対して生成されるすべてのファイルについて、生成されるJavaパッケージ名に\fIprefix\fRという接頭辞が付加されます。typeは、トップレベル・モジュールの単純名か、どのモジュールよりも外側で定義されたIDL型の単純名のどちらかです。
+\fBtype\fRե롦פǸФ줿ϡηФ뤹٤ƤΥեˤĤơJavaѥå̾\fBprefix\fRȤƬղäޤtypeϡȥåץ٥롦⥸塼ñ̾ɤΥ⥸塼⳰¦줿IDLñ̾Τɤ餫Ǥ
.RE
.PP
\-pkgTranslate \fItype\fR \fIpackage\fR
.RS 4
-識別子の中にモジュール名typeが検出されると、生成されるJavaパッケージ内のすべてのファイルについて、識別子の中のその名前がpackageで置き換えられます。最初に\fIpkgPrefix\fRの変更が行われます。typeの値は、トップレベルのモジュールの単純名、またはすべてのモジュールの外部で定義されたIDL型の単純名で、完全なパッケージ名に正確に一致する必要があります。
+̻Ҥ˥⥸塼̾typeФȡJavaѥåΤ٤ƤΥեˤĤơ̻ҤΤ̾package֤ޤǽ\fBpkgPrefix\fRѹԤޤtypeͤϡȥåץ٥Υ⥸塼ñ̾ޤϤ٤ƤΥ⥸塼γ줿IDLñ̾ǡʥѥå̾Τ˰פɬפޤ
.sp
-複数の変換が識別子に一致する場合、次の例に示すように、最も長い一致が選択されます。
+ʣѴ̻Ҥ˰פ硢˼褦ˡǤĹפޤ
.sp
-\fBコマンド\fR:
+\fBޥ\fR:
.sp
.if n \{\
.RS 4
.\}
.nf
-pkgTranslate type pkg \-pkgTranslate type2\&.baz pkg2\&.fizz
+\fBpkgTranslate type pkg \-pkgTranslate type2\&.baz pkg2\&.fizz\fR
+
.fi
.if n \{\
.RE
.\}
-\fB結果の変換\fR:
+\fB̤Ѵ\fR:
.sp
.if n \{\
.RS 4
.\}
.nf
-type => pkg
-type\&.ext => pkg\&.ext
-type\&.baz => pkg2\&.fizz
-type2\&.baz\&.pkg => pkg2\&.fizz\&.pkg
+\fBtype => pkg\fR
+\fBtype\&.ext => pkg\&.ext\fR
+\fBtype\&.baz => pkg2\&.fizz\fR
+\fBtype2\&.baz\&.pkg => pkg2\&.fizz\&.pkg\fR
+
.fi
.if n \{\
.RE
.\}
-パッケージ名\fIorg\fR、\fIorg\fR\&.o\fImg\fR、または\fIorg\&.omg\fRのサブパッケージは、変換できません。これらのパッケージ名を変換しようとすると、互換性のないコードが生成され、\fI\-pkgTranslate\fRの後の最初の引数としてそれらのパッケージを使用すると、エラーとして扱われます。
+ѥå̾\fBorg\fR\fBorg\fR\&.o\fBmg\fRޤ\fBorg\&.omg\fRΥ֥ѥåϡѴǤޤΥѥå̾Ѵ褦ȤȡߴΤʤɤ졢\fB\-pkgTranslate\fRθκǽΰȤƤΥѥåѤȡ顼Ȥưޤ
.RE
.PP
\-skeletonName \fIxxx%yyy\fR
.RS 4
-\fIxxx%yyy\fRが、スケルトンに名前を付けるパターンとして使用されます。デフォルトは次のとおりです。\fIPOA\fRベース・クラスの場合は\fI%POA\fR
-(\fI\-fserver\fRまたは\fI\-fall\fR)、\fIoldImplBase\fRクラスの場合は\fI_%ImplBase\fR
-(\-\fIoldImplBase\fR)および(\fI\-fserver\fRまたは\fI\-fall\fR))。
+\fBxxx%yyy\fRȥ̾դѥȤƻѤޤǥեȤϼΤȤǤ\fBPOA\fR١饹ξ\fB%POA\fR
+(\fB\-fserver\fRޤ\fB\-fall\fR)\fBoldImplBase\fR饹ξ\fB_%ImplBase\fR
+(\-\fBoldImplBase\fR)(\fB\-fserver\fRޤ\fB\-fall\fR))
.RE
.PP
\-td \fIdir\fR
.RS 4
-出力ディレクトリとして、現在のディレクトリではなく、\fIdir\fRが使用されます。
+ϥǥ쥯ȥȤơߤΥǥ쥯ȥǤϤʤ\fIdir\fRѤޤ
.RE
.PP
\-tieName \fIxxx%yyy\fR
.RS 4
-パターンに従って、\fIxxx%yyy\fRを使用します。デフォルトは次のとおりです。\fIPOA\fRベース・クラスの場合は\fI%POA\fR
-(\fI\-fserverTieまたは\-fallTie\fR)、\fIoldImplBase\fR
-tieクラスの場合は\fI_%Tie\fR
-(\-\fIoldImplBase\fR)および(\fI\-fserverTie\fRまたは\fI\-fallTie\fR))。
+ѥ˽äơ\fBxxx%yyy\fRѤޤǥեȤϼΤȤǤ\fBPOA\fR١饹ξ\fB%POA\fR
+(\fB\-fserverTieޤ\-fallTie\fR)\fBoldImplBase\fR
+tie饹ξ\fB_%Tie\fR
+(\-\fBoldImplBase\fR)(\fB\-fserverTie\fRޤ\fB\-fallTie\fR))
.RE
.PP
-\-nowarn、\-verbose
+\-nowarn\-verbose
.RS 4
-リリース情報を表示して終了します。
+ɽƽλޤ
.RE
.PP
\-version
.RS 4
-リリース情報を表示して終了します。
+ɽƽλޤ
.RE
-.SH "制限事項"
+.SH "»"
.PP
-グローバル・スコープ内のエスケープされた識別子は、IDLプリミティブ型の\fIObject\fRまたは\fIValueBase\fRと同じ綴りにしないでください。これは、シンボル表がこれらの識別子でプリロードされているためです。これらの再定義を許可すると、元の定義が上書きされます。これは、おそらく恒久的な制約です。
+Х롦Υפ줿̻ҤϡIDLץߥƥַ\fBObject\fRޤ\fBValueBase\fRƱ֤ˤʤǤϡܥɽμ̻ҤǥץɤƤ뤿ǤκĤȡޤϡ餯ŪǤ
.PP
-\fIfixed\fRというIDL型はサポートされていません。
-.SH "既知の問題"
+\fBfixed\fRȤIDLϥݡȤƤޤ
+.SH "Τ"
.PP
-グローバル識別子についてインポートが生成されません。予期されないローカル\fIimpl\fRオブジェクトを呼び出すと、例外を受け取ります。しかし、その原因は、\fIServerDelegate\fR
-DSIコード内の\fINullPointerException\fRにあるようです。
+Х뼱̻ҤˤĤƥݡȤޤͽʤ\fBimpl\fR֥ȤƤӽФȡ㳰ޤθϡ\fBServerDelegate\fR
+DSI\fBNullPointerException\fRˤ褦Ǥ
.br
'pl 8.5i
'bp