نام (NAME)

rmic - کلاس‌های stub، skeleton و tie را برای اشیاء دوردستی که از Java Remote Method Protocol (JRMP) یا پروتکل Internet Inter-Orb (IIOP) استفاده می‌کنند تولید می‌کند. همچنین Object Management Group (OMG) Interface Definition Language (IDL) را تولید می‌کند

خلاصه دستور (SYNOPSIS)

rmic [ options ] package-qualified-class-names

options: گزینه‌های خط فرمان (options). بخش گزینه‌ها را ببینید.
package-qualified-class-names: نام‌های کلاس شامل نام بسته‌شان، برای نمونه java.awt.Color.

توضیحات (DESCRIPTION)

یادداشت منسوخ‌سازی: پشتیبانی از تولید ایستان (static) کلاس‌های stub و skeleton مربوط به Java Remote Method Protocol (JRMP) منسوخ شده است. اوراکل توصیه می‌کند در عوض از stubهای به‌صورت پویا تولیدشدهٔ JRMP استفاده کنید که نیاز به استفاده از این ابزار را برای برنامه‌های مبتنی بر JRMP از میان می‌برد. برای اطلاعات بیشتر، مشخصات java.rmi.server.UnicastRemoteObject را در http://docs.oracle.com/javase/8/docs/api/java/rmi/server/UnicastRemoteObject.html ببینید.

کامپایلر rmic پرونده‌های کلاسی stub و skeleton را با استفاده از Java Remote Method Protocol (JRMP) و پرونده‌های کلاسی stub و tie (پروتکل IIOP) را برای اشیاء دوردست تولید می‌کند. این پرونده‌های کلاسی از کلاس‌های کامپایل‌شدهٔ زبان برنامه‌نویسی جاوا که کلاس‌های پیاده‌سازی شیء دوردست هستند تولید می‌شوند. یک کلاس پیاده‌سازی دوردست، کلاسی است که رابط java.rmi.Remote را پیاده‌سازی می‌کند. نام‌های کلاس در دستور rmic باید مربوط به کلاس‌هایی باشند که با موفقیت توسط دستور javac کامپایل شده‌اند و باید نام کامل بسته (fully package qualified) را داشته باشند. برای نمونه، اجرای دستور rmic بر روی پروندهٔ کلاس HelloImpl همان‌گونه که در اینجا نشان داده شده است، پروندهٔ HelloImpl_Stub.class را در زیرشاخهٔ hello (برگرفته از نام بستهٔ کلاس) ایجاد می‌کند:

rmic hello.HelloImpl

یک skeleton برای یک شیء دوردست، یک موجودیت سمت سرور در پروتکل JRMP است که متدی برای فرستادن (dispatch) فراخوانی‌ها به پیاده‌سازی شیء دوردست دارد.

یک tie برای یک شیء دوردست، یک موجودیت سمت سرور مشابه skeleton است، اما ارتباط با کلاینت را از طریق پروتکل IIOP برقرار می‌کند.

یک stub یک پروکسی سمت کلاینت برای یک شیء دوردست است که مسئول انتقال فراخوانی‌های متد بر روی اشیاء دوردست به سروری است که پیاده‌سازی واقعی شیء دوردست در آن قرار دارد. بنابراین، ارجاع کلاینت به یک شیء دوردست، در واقع ارجاعی به یک stub محلی است.

به‌طور پیش‌فرض، دستور rmic کلاس‌های stubای تولید می‌کند که تنها از نسخهٔ 1.2 پروتکل stub در JRMP استفاده می‌کنند، درست همانند حالتی که گزینهٔ -v1.2 مشخص شده باشد. گزینهٔ -vcompat در انتشار‌های پیش از 5.0 حالت پیش‌فرض بود. برای تولید کلاس‌های stub و tie برای پروتکل IIOP، از گزینهٔ -iiop استفاده کنید. بخش گزینه‌ها را ببینید.

یک stub تنها رابط‌های دوردست را پیاده‌سازی می‌کند، نه رابط‌های محلی‌ای را که شیء دوردست نیز آن‌ها را پیاده‌سازی کرده است. از آنجا که یک stub در JRMP همان مجموعه رابط‌های دوردست شیء دوردست را پیاده‌سازی می‌کند، کلاینت می‌تواند از عملگرهای توکار زبان برنامه‌نویسی جاوا برای تبدیل نوع (casting) و بررسی نوع (type checking) استفاده کند. برای IIOP، باید از متد PortableRemoteObject.narrow استفاده شود.

گزینه‌ها (OPTIONS)

-bootclasspath path

مکان پرونده‌های کلاسی bootstrap را بازنویسی می‌کند.

-classpath path

مسیری را که دستور rmic برای جستجوی کلاس‌ها استفاده می‌کند مشخص می‌سازد. این گزینه مقدار پیش‌فرض یا متغیر محیطی CLASSPATH (در صورت تنظیم بودن) را بازنویسی می‌کند. دایرکتوری‌ها با دونقطه (:) از یکدیگر جدا می‌شوند. قالب کلی برای path عبارت است از: .:<your_path>، برای نمونه: .:/usr/local/java/classes.

-d directory

دایرکتوری مقصد ریشه را برای سلسله‌مراتب کلاس‌های تولیدشده مشخص می‌کند. می‌توانید از این گزینه برای تعیین دایرکتوری مقصد برای پرونده‌های stub، skeleton و tie استفاده کنید. برای نمونه، دستور زیر کلاس‌های stub و skeleton مشتق‌شده از MyClass را در دایرکتوری /java/classes/exampleclass قرار می‌دهد.

rmic -d /java/classes exampleclass.MyClass

اگر گزینهٔ -d مشخص نشده باشد، رفتار پیش‌فرض به‌گونه‌ای است که گویی -d . مشخص شده باشد. سلسله‌مراتب بستهٔ کلاس هدف در دایرکتوری جاری ایجاد می‌شود و پرونده‌های stub/tie/skeleton در درون آن قرار می‌گیرند. در برخی از انتشار‌های پیشین دستور rmic، اگر گزینهٔ -d مشخص نمی‌شد، سلسله‌مراتب بسته ایجاد نمی‌شد و همهٔ پرونده‌های خروجی مستقیماً در دایرکتوری جاری قرار می‌گرفتند.

-extdirs path

مکان افزونه‌های نصب‌شده را بازنویسی می‌کند.

-g

تولید همهٔ اطلاعات اشکال‌زدایی، از جمله متغیرهای محلی را فعال می‌سازد. به‌طور پیش‌فرض، تنها اطلاعات شماره خط تولید می‌شود.

-idl

باعث می‌شود دستور rmic برای کلاس‌های مشخص‌شده و هر کلاس مورد ارجاع، OMG IDL تولید کند. زبان IDL روشی کاملاً توصیفی و مستقل از زبان برنامه‌نویسی برای تعیین یک API برای شیء فراهم می‌آورد. از IDL به عنوان مشخصاتی برای متدها و داده‌هایی استفاده می‌شود که می‌توانند در هر زبانی که اتصالات CORBA را ارائه می‌دهد نوشته و فراخوانی شوند. این شامل جاوا، ++C و زبان‌های دیگر می‌شود. سند Java IDL: IDL to Java Language Mapping را در http://docs.oracle.com/javase/8/docs/technotes/guides/idl/mapping/jidlMapping.html ببینید.

هنگامی که گزینهٔ -idl استفاده می‌شود، گزینه‌های دیگر نیز شامل موارد زیر هستند:

•: گزینه‌های -always یا -alwaysgenerate تولید مجدد را اجبار می‌کنند، حتی اگر stubها/tieها/IDL موجود از کلاس ورودی جدیدتر باشند.
•: گزینهٔ -factory از کلیدواژهٔ factory در IDL تولیدشده استفاده می‌کند.
•: گزینهٔ -idlModule from JavaPackage[.class]toIDLModule نگاشت بستهٔ IDLEntity را مشخص می‌کند، برای نمونه: -idlModulemy.module my::real::idlmod.
•: گزینهٔ -idlFilefromJavaPackage[.class] toIDLFile نگاشت پروندهٔ IDLEntity را مشخص می‌کند، برای نمونه: -idlFile test.pkg.X TEST16.idl.

-iiop

باعث می‌شود دستور rmic به جای کلاس‌های stub و skeleton در JRMP، کلاس‌های stub و tie پروتکل IIOP را تولید کند. کلاس stub یک پروکسی محلی برای یک شیء دوردست است و توسط کلاینت‌ها برای فرستادن فراخوانی‌ها به سرور استفاده می‌شود. هر رابط دوردست نیازمند یک کلاس stub است که آن رابط دوردست را پیاده‌سازی کند. ارجاع کلاینت به یک شیء دوردست، ارجاعی به یک stub است. کلاس‌های tie در سمت سرور برای پردازش فراخوانی‌های دریافتی و هدایت آن‌ها به کلاس پیاده‌سازی مناسب استفاده می‌شوند. هر کلاس پیاده‌سازی نیازمند یک کلاس tie است.

اگر دستور rmic را همراه با -iiop فراخوانی کنید، stubها و tieهایی منطبق با این قرارداد نام‌گذاری تولید می‌کند:

_<implementationName>_stub.class

_<interfaceName>_tie.class

•: هنگامی که از گزینهٔ -iiop استفاده می‌کنید، گزینه‌های دیگر نیز شامل موارد زیر هستند:
•: گزینه‌های -always یا -alwaysgenerate تولید مجدد را اجبار می‌کنند، حتی اگر stubها/tieها/IDL موجود از کلاس ورودی جدیدتر باشند.
•: گزینهٔ -nolocalstubs به این معنی است که stubهای بهینه‌شده برای کلاینت‌ها و سرورهای درون یک پردازش یکسان ایجاد نشوند.
•: گزینهٔ -noValueMethods باید همراه با گزینهٔ -idl استفاده شود. گزینهٔ -noValueMethods از افزودن متدها و مقداردهنده‌های اولیهٔ valuetype به IDL تولیدشده جلوگیری می‌کند. این متدها و مقداردهنده‌های اولیه برای valuetypeها اختیاری هستند و تولید می‌شوند، مگر اینکه گزینهٔ -noValueMethods همراه با گزینهٔ -idl مشخص شود.
•: گزینهٔ -poa وراثت را از org.omg.CORBA_2_3.portable.ObjectImpl به org.omg.PortableServer.Servant تغییر می‌دهد. ماژول PortableServer برای Portable Object Adapter (POA) نوع محلی Servant را تعریف می‌کند. در زبان برنامه‌نویسی جاوا، نوع Servant به کلاس Java org.omg.PortableServer.Servant نگاشت می‌شود. این کلاس به عنوان کلاس پایه برای تمام پیاده‌سازی‌های servant در POA عمل می‌کند و تعدادی متد ارائه می‌دهد که می‌توانند توسط برنامه‌نویس برنامه فراخوانی شوند، و متدهایی که توسط POA فراخوانی می‌شوند و کاربر می‌تواند آن‌ها را برای کنترل جنبه‌های رفتار servant بازنویسی کند. بر اساس مشخصات OMG IDL to Java Language Mapping Specification، سند CORBA V 2.3.1 ptc/00-01-08.pdf..RE
-J: همراه با هر دستور جاوا، گزینهٔ -J آرگومان بعد از -J را (بدون فاصله بین -J و آرگومان) به مفسر جاوا ارسال می‌کند.
-keep or -keepgenerated: پرونده‌های منبع .java تولیدشده را برای کلاس‌های stub، skeleton و tie نگه می‌دارد و آن‌ها را در همان دایرکتوری پرونده‌های .class می‌نویسد.
-nowarn: هشدارها را خاموش می‌کند. هنگامی که از گزینهٔ -nowarn استفاده می‌شود، کامپایلر هیچ هشداری چاپ نمی‌کند.
-nowrite: کلاس‌های کامپایل‌شده را بر روی سیستم فایل نمی‌نویسد.
-vcompat (deprecated): کلاس‌های stub و skeletonای تولید می‌کند که با هر دو نسخهٔ 1.1 و 1.2 پروتکل stub در JRMP سازگار باشند. این گزینه در انتشار‌های پیش از 5.0 حالت پیش‌فرض بود. کلاس‌های stub تولیدشده هنگام بارگذاری در ماشین مجازی JDK 1.1 از نسخهٔ 1.1 پروتکل stub استفاده می‌کنند و هنگام بارگذاری در ماشین مجازی 1.2 (یا بالاتر) از نسخهٔ 1.2 پروتکل stub استفاده می‌کنند. کلاس‌های skeleton تولیدشده از هر دو نسخهٔ 1.1 و 1.2 پروتکل stub پشتیبانی می‌کنند. کلاس‌های تولیدشده برای پشتیبانی از هر دو حالت عملکردی نسبتاً بزرگ هستند. نکته: این گزینه منسوخ شده است. بخش توضیحات را ببینید.
-verbose: باعث می‌شود کامپایلر و پیونددهنده پیام‌هایی دربارهٔ اینکه چه کلاس‌هایی در حال کامپایل هستند و چه پرونده‌های کلاسی در حال بارگذاری هستند چاپ کنند.
-v1.1 (deprecated): کلاس‌های stub و skeleton را تنها برای نسخهٔ 1.1 پروتکل stub در JRMP تولید می‌کند. گزینهٔ -v1.1 تنها برای تولید کلاس‌های stubای مفید است که از نظر سری‌سازی با کلاس‌های stub از پیش موجود و مستقر به صورت ایستا (که توسط دستور rmic از JDK 1.1 تولید شده‌اند و امکان ارتقای آن‌ها وجود ندارد و از بارگذاری پویای کلاس نیز استفاده نمی‌شود) سازگار باشند. نکته: این گزینه منسوخ شده است. بخش توضیحات را ببینید.
-v1.2 (deprecated): (پیش‌فرض) کلاس‌های stub را تنها برای نسخهٔ 1.2 پروتکل stub در JRMP تولید می‌کند. هیچ کلاس skeletonای تولید نمی‌شود زیرا کلاس‌های skeleton در نسخهٔ 1.2 پروتکل stub استفاده نمی‌شوند. کلاس‌های stub تولیدشده هنگامی که در یک ماشین مجازی JDK 1.1 بارگذاری شوند کار نمی‌کنند. نکته: این گزینه منسوخ شده است. بخش توضیحات را ببینید.

محیط (ENVIRONMENT)

CLASSPATH: برای مشخص کردن مسیری به سیستم جهت یافتن کلاس‌های تعریف‌شده توسط کاربر به کار می‌رود. دایرکتوری‌ها با دونقطه از هم جدا می‌شوند، برای نمونه: .:/usr/local/java/classes.

همچنین ببینید (SEE ALSO)

•: javac(1)
•: java(1)
•: تنظیم مسیر کلاس (Setting the Class Path)