'\" t .\" Copyright (c) 2001, 2013, 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 .\" under the terms of the GNU General Public License version 2 only, as .\" published by the Free Software Foundation. .\" .\" 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 .\" version 2 for more details (a copy is included in the LICENSE file that .\" accompanied this code). .\" .\" You should have received a copy of the GNU General Public License version .\" 2 along with this work; if not, write to the Free Software Foundation, .\" Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. .\" .\" Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA .\" or visit www.oracle.com if you need additional information or have any .\" questions. .\" .\" Arch: generic .\" Software: JDK 8 .\" Date: 21 November 2013 .\" SectDesc: Java IDL and RMI-IIOP Tools .\" Title: idlj.1 .\" .if n .pl 99999 .TH idlj 1 "21 November 2013" "JDK 8" "Java IDL and RMI-IIOP Tools" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "نام (NAME)" idlj \- اتصالات جاوا را برای یک فایل مشخص از زبان تعریف واسط (IDL) تولید می‌کند\&. .SH "خلاصه دستور (SYNOPSIS)" .sp .nf \fBidlj\fR [ \fIoptions\fR ] \fIidlfile\fR .fi .sp .TP \fIoptions\fR گزینه‌های خط فرمان\&. بخش گزینه‌ها را ببینید\&. گزینه‌ها می‌توانند به هر ترتیبی ظاهر شوند، اما باید قبل از \f3idlfile\fR قرار گیرند\&. .TP \fIidlfile\fR نام فایلی که حاوی تعاریف زبان تعریف واسط (IDL) است\&. .SH "توضیحات (DESCRIPTION)" کامپایلر IDL-to-Java اتصالات جاوا را برای یک فایل مشخص IDL تولید می‌کند\&. برای جزئیات اتصالات، بخش Java IDL: IDL to Java Language Mapping را در http://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping\&.html ببینید\&. .PP برخی از نگارش‌های پیشین کامپایلر IDL-to-Java با نام \f3idltojava\fR شناخته می‌شدند\&. .SS ایجاد\ اتصالات\ کلاینت\ و\ سرور\ (EMIT\ CLIENT\ AND\ SERVER\ BINDINGS) دستور \f3idlj\fR زیر برای یک فایل IDL با نام \f3My\&.idl\fR اتصالات سمت کلاینت را تولید می‌کند\&. .sp .nf \f3idlj My\&.idl\fP .fi .nf \f3\fR .fi .sp سینتکس پیشین معادل دستور زیر است: .sp .nf \f3idlj \-fclient My\&.idl\fP .fi .nf \f3\fR .fi .sp مثال بعدی اتصالات سمت سرور را تولید می‌کند و شامل اتصالات سمت کلاینت به همراه اسکلت (skeleton) است که همگی مبتنی بر POA (مدل وراثت یا Inheritance Model) هستند\&. .sp .nf \f3idlg \-fserver My\&.idl\fP .fi .nf \f3\fR .fi .sp اگر می‌خواهید هر دو نوع اتصالات سمت کلاینت و سرور را تولید کنید، از یکی از دستورهای (معادل) زیر استفاده کنید: .sp .nf \f3idlj \-fclient \-fserver My\&.idl\fP .fi .nf \f3idlj \-fall My\&.idl\fP .fi .nf \f3\fR .fi .sp دو مدل ممکن در سمت سرور وجود دارد: مدل وراثت Servant قابل حمل (Portable Servant Inheritance Model) و مدل Tie\&. بخش Tie Delegation Model را ببینید\&. .PP \f3Portable Servant Inheritance Model\fR\&. مدل پیش‌فرض سمت سرور، مدل Portable Servant Inheritance است\&. با فرض یک واسط \f3My\fR که در \f3My\&.idl\fR تعریف شده است، فایل \f3MyPOA\&.java\fR تولید می‌شود\&. شما باید پیاده‌سازی واسط \f3My\fR را ارائه دهید، و واسط \f3My\fR باید از کلاس \f3MyPOA\fR ارث‌بری کند\&. فایل \f3MyPOA\&.java\fR یک اسکلت مبتنی بر جریان است که کلاس \f3org\&.omg\&.PortableServer\&.Servant\fR در نشانی http://docs\&.oracle\&.com/javase/8/docs/api/org/omg/PortableServer/Servant\&.html را گسترش می‌دهد\&. واسط \f3My\fR واسط \f3callHandler\fR و واسط عملیات مرتبط با واسط IDL را که اسکلت پیاده‌سازی می‌کند، پیاده‌سازی می‌نماید\&. پودمان \f3PortableServer\fR برای آداپتور شیء قابل حمل (POA) نوع بومی \f3Servant\fR را تعریف می‌کند\&. به بخش Portable Object Adapter (POA) در نشانی http://docs\&.oracle\&.com/javase/8/docs/technotes/guides/idl/POA\&.html مراجعه کنید\&. در زبان برنامه‌نویسی جاوا، نوع \f3Servant\fR به کلاس جاوای \f3org\&.omg\&.PortableServer\&.Servant\fR نگاشت می‌شود\&. این کلاس به عنوان کلاس پایه برای تمام پیاده‌سازی‌های servant در POA عمل کرده و تعدادی متد ارائه می‌دهد که می‌توانند توسط برنامه‌نویس فراخوانی شوند، و متدهایی که توسط POA فراخوانی شده و می‌توانند توسط کاربر برای کنترل جنبه‌های رفتاری servant بازنویسی (override) شوند\&. گزینه دیگر برای مدل وراثت، استفاده از پرچم \f3-oldImplBase\fR برای ایجاد اتصالات سمت سرور است که با نگارش‌های پیش از Java SE 1\&.4 سازگار باشند\&. پرچم \f3-oldImplBase\fR غیر استاندارد است و این APIها منسوخ (deprecated) شده‌اند\&. از این پرچم تنها باید برای سازگاری با سرورهای موجود نوشته‌شده با Java SE 1\&.3 استفاده کنید\&. در این حالت، باید یک makefile موجود را ویرایش کنید تا پرچم \f3-oldImplBase\fR به کامپایلر \f3idlj\fR اضافه شود\&. در غیر این صورت نگاشت‌های سمت سرور مبتنی بر POA تولید می‌شوند\&. برای تولید اتصالات سمت سروری که سازگاری با نگارش‌های پیشین را حفظ کنند، به صورت زیر عمل کنید: .sp .nf \f3idlj \-fclient \-fserver \-oldImplBase My\&.idl\fP .fi .nf \f3idlj \-fall \-oldImplBase My\&.idl\fP .fi .nf \f3\fR .fi .sp با داشتن واسط \f3My\fR تعریف‌شده در \f3My\&.idl\fR، فایل \f3_MyImplBase\&.java\fR تولید می‌شود\&. شما باید پیاده‌سازی واسط \f3My\fR را ارائه دهید، و واسط \f3My\fR باید از کلاس \f3_MyImplBase\fR ارث‌بری نماید\&. .PP \f3Tie Delegation Model\fR\&. مدل دیگر سمت سرور مدل Tie نامیده می‌شود\&. این یک مدل تفویض (delegation model) است\&. از آنجا که امکان تولید هم‌زمان tieها و اسکلت‌ها وجود ندارد، آن‌ها باید به طور جداگانه تولید شوند\&. دستورهای زیر اتصالات مربوط به مدل Tie را تولید می‌کنند: .sp .nf \f3idlj \-fall My\&.idl\fP .fi .nf \f3idlj \-fallTIE My\&.idl\fP .fi .nf \f3\fR .fi .sp برای واسط \f3My\fR، دستور دوم فایل \f3MyPOATie\&.java\fR را تولید می‌کند\&. سازنده کلاس \f3MyPOATie\fR یک delegate دریافت می‌کند\&. در این مثال، با استفاده از مدل پیش‌فرض POA، سازنده همچنین به یک POA نیاز دارد\&. شما باید پیاده‌سازی delegate را ارائه دهید، اما نیازی نیست که از کلاس دیگری ارث‌بری کند، فقط باید از واسط \f3MyOperations\fR ارث‌بری داشته باشد\&. برای استفاده از آن با ORB، باید پیاده‌سازی خود را در کلاس \f3MyPOATie\fR کپسوله‌سازی کنید، برای مثال: .sp .nf \f3ORB orb = ORB\&.init(args, System\&.getProperties());\fP .fi .nf \f3\fR .fi .nf \f3// Get reference to rootpoa & activate the POAManager\fP .fi .nf \f3POA rootpoa = (POA)orb\&.resolve_initial_references("RootPOA");\fP .fi .nf \f3rootpoa\&.the_POAManager()\&.activate();\fP .fi .nf \f3\fR .fi .nf \f3// create servant and register it with the ORB\fP .fi .nf \f3MyServant myDelegate = new MyServant();\fP .fi .nf \f3myDelegate\&.setORB(orb); \fP .fi .nf \f3\fR .fi .nf \f3// create a tie, with servant being the delegate\&.\fP .fi .nf \f3MyPOATie tie = new MyPOATie(myDelegate, rootpoa);\fP .fi .nf \f3\fR .fi .nf \f3// obtain the objectRef for the tie\fP .fi .nf \f3My ref = tie\&._this(orb);\fP .fi .nf \f3\fR .fi .sp ممکن است زمانی که پیاده‌سازی شما باید از پیاده‌سازی دیگری ارث‌بری کند، ترجیح دهید به جای مدل وراثت معمول از مدل Tie استفاده کنید\&. جاوا اجازه هر تعداد وراثت از واسط را می‌دهد، اما تنها یک جایگاه برای وراثت کلاس وجود دارد\&. اگر از مدل وراثت استفاده کنید، این جایگاه اشغال می‌شود\&. با مدل Tie، آن جایگاه برای استفاده خودتان آزاد می‌ماند\&. عیب آن این است که سطحی از غیرمستقیم‌سازی را ایجاد می‌کند: در هنگام فراخوانی هر متد، یک فراخوانی متد اضافه رخ می‌دهد\&. .PP برای تولید سمت سرور، اتصالات مدل Tie که با نگارش‌های نگاشت زبان IDL به جاوا در نسخه‌های پیش از Java SE 1\&.4 سازگار باشند\&. .sp .nf \f3idlj \-oldImplBase \-fall My\&.idl\fP .fi .nf \f3idlj \-oldImplBase \-fallTIE My\&.idl\fP .fi .nf \f3\fR .fi .sp برای واسط \f3My\fR، این دستور فایل \f3My_Tie\&.java\fR را تولید می‌کند\&. سازنده کلاس \f3My_Tie\fR یک شیء \f3impl\fR دریافت می‌کند\&. شما باید پیاده‌سازی را برای \f3impl\fR ارائه دهید، اما نیازی نیست که از کلاس دیگری ارث‌بری کند، فقط باید واسط \f3HelloOperations\fR را پیاده‌سازی نماید\&. اما برای استفاده از آن با ORB، باید پیاده‌سازی خود را درون \f3My_Tie\fR قرار دهید، برای مثال: .sp .nf \f3ORB orb = ORB\&.init(args, System\&.getProperties());\fP .fi .nf \f3\fR .fi .nf \f3// create servant and register it with the ORB\fP .fi .nf \f3MyServant myDelegate = new MyServant();\fP .fi .nf \f3myDelegate\&.setORB(orb); \fP .fi .nf \f3\fR .fi .nf \f3// create a tie, with servant being the delegate\&.\fP .fi .nf \f3MyPOATie tie = new MyPOATie(myDelegate);\fP .fi .nf \f3\fR .fi .nf \f3// obtain the objectRef for the tie\fP .fi .nf \f3My ref = tie\&._this(orb);\fP .fi .nf \f3\fR .fi .sp.SS "تعیین مکان‌های جایگزین برای فایل‌های تولیدشده" اگر می‌خواهید فایل‌های تولیدشده به دایرکتوری دیگری غیر از دایرکتوری فعلی هدایت شوند، کامپایلر را به این روش فراخوانی کنید: \f3idlj \-td /altdir My\&.idl\fR\&. .PP برای رابط \f3My\fR، اتصالات به جای \f3\&./My\&.java\fR، در \f3/altdir/My\&.java\fR و غیره ایجاد می‌شوند\&. .SS "تعیین مکان‌های جایگزین برای فایل‌های INCLUDE" اگر فایل \f3My\&.idl\fR فایل \f3idl\fR دیگری به نام \f3MyOther\&.idl\fR را شامل شود (include کند)، کامپایلر فرض می‌کند که فایل \f3MyOther\&.idl\fR در دایرکتوری محلی قرار دارد\&. اگر به عنوان مثال در \f3/includes\fR قرار دارد، کامپایلر را با دستور زیر فراخوانی کنید: .sp .nf \f3idlj \-i /includes My\&.idl\fP .fi .nf \f3\fR .fi .sp اگر به عنوان مثال \f3My\&.idl\fR فایل \f3Another\&.idl\fR را نیز شامل شود که در \f3/moreIncludes\fR قرار دارد، کامپایلر را با دستور زیر فراخوانی کنید: .sp .nf \f3idlj \-i /includes \-i /moreIncludes My\&.idl\fP .fi .nf \f3\fR .fi .sp از آنجا که این شکل از \f3include\fR می‌تواند بسیار طولانی شود، روش دیگری برای مشخص کردن محل جستجوی فایل‌های ضمیمه‌شده به کامپایلر در نظر گرفته شده است\&. این روش مشابه ایده یک متغیر محیطی است\&. فایلی به نام idl\&.config در دایرکتوری که در متغیر \f3CLASSPATH\fR شما فهرست شده است ایجاد کنید\&. درون \f3idl\&.config\fR، خطی به این صورت قرار دهید: .sp .nf \f3includes=/includes;/moreIncludes\fP .fi .nf \f3\fR .fi .sp کامپایلر این فایل را پیدا کرده و فهرست includes را می‌خواند\&. توجه داشته باشید که در این مثال نویسه جداکننده بین دو دایرکتوری یک نقطه ویرگول (;) است\&. این نویسه جداکننده وابسته به پلتفرم است\&. در پلتفرم Windows از نقطه ویرگول، در پلتفرم Unix از دونقطه (:) و به همین ترتیب استفاده کنید\&. .SS "تولید اتصالات برای فایل‌های INCLUDE" به طور پیش‌فرض، اتصالات Java تنها برای رابط‌ها، ساختارها و مواردی تولید می‌شوند که در فایل \f3idl\fR موجود در خط فرمان تعریف شده باشند\&. انواع تعریف‌شده در فایل‌های includeشده تولید نمی‌شوند\&. به عنوان مثال، دو فایل \f3idl\fR زیر را در نظر بگیرید: .sp .nf \f3My\&.idl file:\fP .fi .nf \f3\fR .fi .nf \f3#include \fP .fi .nf \f3interface My\fP .fi .nf \f3{\fP .fi .nf \f3};\fP .fi .nf \f3\fR .fi .nf \f3MyOther\&.idl file:\fP .fi .nf \f3\fR .fi .nf \f3interface MyOther\fP .fi .nf \f3{\fP .fi .nf \f3};\fP .fi .nf \f3\fR .fi .sp یک تبصره برای این قاعده پیش‌فرض وجود دارد\&. هر دستور \f3#include\fR که در حوزه سراسری (global scope) ظاهر شود طبق آنچه توضیح داده شد رفتار می‌کند\&. این دستورات \f3#include\fR را می‌توان مشابه دستورات import در نظر گرفت\&. دستورات \f3#include\fR که درون یک حوزه بسته (enclosed scope) ظاهر می‌شوند به عنوان دستورات \f3#include\fR واقعی تلقی می‌شوند؛ بدین معنی که با کدهای داخل فایل ضمیمه‌شده به گونه‌ای برخورد می‌شود که گویی در فایل اصلی آمده‌اند و بنابراین اتصالات Java برای آن تولید می‌شوند\&. در اینجا یک مثال آورده شده است: .sp .nf \f3My\&.idl file:\fP .fi .nf \f3\fR .fi .nf \f3#include \fP .fi .nf \f3interface My\fP .fi .nf \f3{\fP .fi .nf \f3 #include \fP .fi .nf \f3};\fP .fi .nf \f3\fR .fi .nf \f3MyOther\&.idl file:\fP .fi .nf \f3\fR .fi .nf \f3interface MyOther\fP .fi .nf \f3{\fP .fi .nf \f3};\fP .fi .nf \f3\fR .fi .nf \f3Embedded\&.idl\fP .fi .nf \f3\fR .fi .nf \f3enum E {one, two, three};\fP .fi .nf \f3\fR .fi .sp دستور \f3idlj My\&.idl\fR را اجرا کنید تا فهرست زیر از فایل‌های Java تولید شود\&. دقت کنید که \f3MyOther\&.java\fR تولید نشده است، زیرا در یک \f3#include\fR شبه-import تعریف شده بود\&. اما \f3E\&.java\fR تولید شده است، زیرا در یک \f3#include\fR واقعی تعریف شده بود\&. توجه داشته باشید از آنجا که فایل \f3Embedded\&.idl\fR درون حوزه رابط \f3My\fR ضمیمه شده است، درون حوزه \f3My\fR (در \f3MyPackage\fR) ظاهر می‌شود\&. اگر از پرچم \f3\-emitAll\fR استفاده شده بود، تمامی انواع در تمامی فایل‌های ضمیمه‌شده تولید می‌شدند\&. .sp .nf \f3\&./MyHolder\&.java\fP .fi .nf \f3\&./MyHelper\&.java\fP .fi .nf \f3\&./_MyStub\&.java\fP .fi .nf \f3\&./MyPackage\fP .fi .nf \f3\&./MyPackage/EHolder\&.java\fP .fi .nf \f3\&./MyPackage/EHelper\&.java\fP .fi .nf \f3\&./MyPackage/E\&.java\fP .fi .nf \f3\&./My\&.java\fP .fi .nf \f3\fR .fi .sp.SS "درج پیشوندهای بسته (INSERT PACKAGE PREFIXES)" فرض کنید برای شرکتی به نام ABC کار می‌کنید که فایل IDL زیر را ساخته است: .sp .nf \f3Widgets\&.idl file:\fP .fi .nf \f3\fR .fi .nf \f3module Widgets\fP .fi .nf \f3{\fP .fi .nf \f3 interface W1 {\&.\&.\&.};\fP .fi .nf \f3 interface W2 {\&.\&.\&.};\fP .fi .nf \f3};\fP .fi .nf \f3\fR .fi .sp اگر این فایل را از طریق کامپایلر IDL\-to\-Java اجرا کنید، اتصالات (bindings) جاوا برای W1 و W2 درون بستهٔ \f3Widgets\fR قرار می‌گیرند\&. یک قرارداد صنعتی وجود دارد که بیان می‌کند بسته‌های یک شرکت باید درون بسته‌ای به نام \f3com\&.\fR قرار داشته باشند\&. برای پیروی از این قرارداد، نام بسته باید \f3com\&.abc\&.Widgets\fR باشد\&. برای قرار دادن این پیشوندِ بسته روی ماژول Widgets، دستور زیر را اجرا کنید: .sp .nf \f3idlj \-pkgPrefix Widgets com\&.abc Widgets\&.idl\fP .fi .nf \f3\fR .fi .sp اگر فایل IDL دیگری دارید که Widgets\&.idl را شامل می‌شود، پرچم \f3\-pkgPrefix\fR باید در آن دستور نیز آورده شود\&. در غیر این صورت، فایل IDL شما به جای بستهٔ \f3com\&.abc\&.Widgets\fR به دنبال بستهٔ \f3Widgets\fR خواهد گشت\&. .PP اگر چندین بسته از این دست دارید که به پیشوند نیاز دارند، قرار دادن آن‌ها در فایل idl\&.config که پیش‌تر شرح داده شد ممکن است آسان‌تر باشد\&. هر خط پیشوند بسته باید به فرم \f3PkgPrefix\&.=\fR باشد\&. خط مربوط به مثال قبل به صورت \f3PkgPrefix\&.Widgets=com\&.abc\fR خواهد بود\&. این گزینه بر شناسهٔ مخزن (Repository ID) تأثیری نمی‌گذارد\&. .SS "تعریف نمادها پیش از کامپایل (DEFINE SYMBOLS BEFORE COMPILATION)" ممکن است نیاز داشته باشید برای فرایند کامپایل نمادی را تعریف کنید که درون فایل IDL تعریف نشده است، مثلاً برای گنجاندن کدهای اشکال‌زدایی در اتصالات\&. دستور \f3idlj \-d MYDEF My\&.idl\fR معادل قرار دادن خط \f3#define MYDEF\fR درون My\&.idl است\&. .SS "حفظ اتصالات از پیش موجود (PRESERVE PREEXISTING BINDINGS)" اگر فایل‌های اتصال جاوا از قبل موجود باشند، پرچم \f3\-keep\fR مانع از بازنویسی آن‌ها توسط کامپایلر می‌شود\&. حالت پیش‌فرض این است که تمام فایل‌ها بدون در نظر گرفتن وجود قبلی آن‌ها تولید می‌شوند\&. اگر آن فایل‌ها را سفارشی‌سازی کرده‌اید (کاری که نباید انجام دهید مگر اینکه کاملاً بر محتوای آن‌ها مسلط باشید)، گزینهٔ \f3\-keep\fR بسیار کاربردی است\&. دستور \f3idlj \-keep My\&.idl\fR تمامی اتصالات سمت کلاینت را که از قبل موجود نیستند تولید می‌کند\&. .SS "مشاهده پیشرفت کامپایل (VIEW COMPILATION PROGRESS)" کامپایلر IDL\-to\-Java هنگام پیشروی در مراحل اجرای خود، پیام‌های وضعیت تولید می‌کند\&. از گزینهٔ \f3\-v\fR برای فعال کردن حالت پرگو (verbose) استفاده کنید: \f3idlj \-v My\&.idl\fR\&. .PP کامپایلر به‌طور پیش‌فرض در حالت پرگو کار نمی‌کند\&. .SS "نمایش اطلاعات نگارش (DISPLAY VERSION INFORMATION)" برای نمایش نگارش ساخت کامپایلر IDL\-to\-Java، گزینهٔ \f3\-version\fR را در خط فرمان مشخص کنید: \f3idlj \-version\fR\&. .PP اطلاعات نگارش همچنین درون اتصالات تولیدشده توسط کامپایلر نیز قرار می‌گیرد\&. هر گزینهٔ اضافی دیگری که در خط فرمان ظاهر شود نادیده گرفته خواهد شد\&. .SH "گزینه‌ها (OPTIONS)" .TP -d \fIsymbol\fR .br این گزینه معادل خط زیر در یک فایل IDL است: .sp .nf \f3#define \fIsymbol\fR\fP .fi .nf \f3\fR .fi .sp .TP -demitAll .br تولید تمام انواع، شامل مواردی که در فایل‌های \f3#include\fR یافت می‌شوند\&. .TP -fside .br مشخص می‌کند چه اتصالاتی تولید شوند\&. پارامتر \f3side\fR می‌تواند \f3client\fR، \f3server\fR، \f3serverTIE\fR، \f3all\fR یا \f3allTIE\fR باشد\&. گزینه‌های \f3\-fserverTIE\fR و \f3\-fallTIE\fR باعث می‌شوند اسکلت‌های مدل تفویضی (delegate model skeletons) تولید شوند\&. در صورتی که این پرچم تعیین نشود، مقدار پیش‌فرض \f3\-fclient\fR است\&. .TP -i \fIinclude-path\fR .br به‌طور پیش‌فرض، دایرکتوری جاری برای فایل‌های ضمیمه‌شده (included) جستجو می‌شود\&. این گزینه دایرکتوری دیگری را اضافه می‌کند\&. .TP -i \fIkeep\fR .br اگر فایلی که قرار است تولید شود از قبل وجود داشته باشد، آن را بازنویسی نمی‌کند\&. به‌طور پیش‌فرض بازنویسی می‌شود\&. .TP -noWarn .br جلوگیری از نمایش پیام‌های هشدار\&. .TP -oldImplBase .br اسکلت‌های سازگار با ORBهای JDK پیش از نگارش 1\&.4 را تولید می‌کند\&. به‌طور پیش‌فرض، اتصالات سمت سرور مدل وراثت POA تولید می‌شوند\&. این گزینه با تولید اتصالات سمت سروری که کلاس‌های مدل وراثت \f3ImplBase\fR هستند، سازگاری رو به عقب با نگارش‌های پیشین زبان برنامه‌نویسی جاوا را فراهم می‌کند\&. .TP -pkgPrefix \fItype\fR\fIprefix\fR .br هر جا که \f3type\fR در محدودهٔ فایل (file scope) دیده شود، نام بستهٔ جاوای تولیدشده را برای تمام فایل‌های تولیدشده برای آن نوع، با \f3prefix\fR پیشوندگذاری می‌کند\&. نوع (type) نام سادهٔ یک ماژول سطح بالا یا یک نوع IDL تعریف‌شده در خارج از هر ماژولی است\&. .TP -pkgTranslate \fItype\fR\fIpackage\fR .br هرگاه نام ماژول type در یک شناسه دیده شود، آن را در شناسه برای تمامی فایل‌های موجود در بستهٔ جاوای تولیدشده با package جایگزین می‌کند\&. توجه داشته باشید که تغییرات \f3pkgPrefix\fR ابتدا اعمال می‌شوند\&. مقدار type نام سادهٔ یک ماژول سطح بالا یا یک نوع IDL تعریف‌شده در خارج از هر ماژول است و باید دقیقاً با نام کامل بسته مطابقت داشته باشد\&. اگر بیش از یک ترجمه با یک شناسه مطابقت داشته باشد، همان‌طور که در مثال زیر نشان داده شده است، طولانی‌ترین تطابق انتخاب می‌شود: \fICommand\fR: .sp .nf \f3pkgTranslate type pkg \-pkgTranslate type2\&.baz pkg2\&.fizz\fP .fi .nf \f3\fR .fi .sp \fIResulting Translation\fR: .sp .nf \f3type => pkg\fP .fi .nf \f3type\&.ext => pkg\&.ext\fP .fi .nf \f3type\&.baz => pkg2\&.fizz\fP .fi .nf \f3type2\&.baz\&.pkg => pkg2\&.fizz\&.pkg\fP .fi .nf \f3\fR .fi .sp نام بسته‌های روبه‌رو شامل \f3org\fR، \f3org\fR\&.o\f3mg\fR یا هر زیربسته‌ای از \f3org\&.omg\fR را نمی‌توان ترجمه (جایگزین) کرد\&. هر تلاشی برای ترجمهٔ این بسته‌ها به کدی غیرقابل کامپایل منجر می‌شود و استفاده از این بسته‌ها به عنوان آرگومان نخست پس از \f3\-pkgTranslate\fR خطا تلقی می‌گردد\&. .TP -skeletonName \fIxxx%yyy\fR .br استفاده از \f3xxx%yyy\fR به عنوان الگو برای نام‌گذاری اسکلت\&. مقادیر پیش‌فرض عبارتند از: \f3%POA\fR برای کلاس پایهٔ \f3POA\fR (با \f3\-fserver\fR یا \f3\-fall\fR)، و \f3_%ImplBase\fR برای کلاس \f3oldImplBase\fR (با \f3\-oldImplBase\fR و (\f3\-fserver\fR یا \f3\-fall\fR))\&. .TP -td \fIdir\fR .br استفاده از \fIdir\fR برای دایرکتوری خروجی به جای دایرکتوری جاری\&. .TP -tieName \fIxxx%yyy\fR .br استفاده از \f3xxx%yyy\fR مطابق با الگو\&. مقادیر پیش‌فرض عبارتند از: \f3%POA\fR برای کلاس پایهٔ \f3POA\fR (با \f3\-fserverTie یا \-fallTie\fR)، و \f3_%Tie\fR برای کلاس tie مربوط به \f3oldImplBase\fR (با \f3\-oldImplBase\fR و (\f3\-fserverTie\fR یا \f3\-fallTie\fR))\&. .TP -nowarn, -verbose .br اطلاعات انتشار را نمایش داده و خارج می‌شود\&. .TP -version .br اطلاعات انتشار را نمایش داده و خارج می‌شود\&..SH "محدودیت‌ها (RESTRICTIONS)" شناسه‌های گریز داده‌شده در دامنهٔ سراسری نمی‌توانند املایی یکسان با انواع اولیهٔ IDL، \f3Object\fR یا \f3ValueBase\fR داشته باشند\&. این بدان دلیل است که جدول نمادها از پیش با این شناسه‌ها بارگذاری شده است\&. مجاز بودن بازتعریف آن‌ها، تعاریف اصلی‌شان را رونویسی خواهد کرد\&. احتمالاً این یک محدودیت همیشگی است\&. .PP نوع IDL با عنوان \f3fixed\fR پشتیبانی نمی‌شود\&. .SH "مشکلات شناخته‌شده (KNOWN PROBLEMS)" هیچ importی برای شناسه‌های سراسری تولید نمی‌شود\&. اگر یک شیء محلی صادرنشدهٔ \f3impl\fR را فراخوانی کنید، یک استثنا دریافت خواهید کرد، اما به نظر می‌رسد این امر ناشی از یک \f3NullPointerException\fR در کد DSI مربوط به \f3ServerDelegate\fR باشد\&. .RE .br 'pl 8.5i 'bp