نام (NAME)

rmic - تولید کلاس‌های stub، skeleton و tie برای اشیاء دوردست با استفاده از JRMP یا IIOP، و همچنین تولید OMG IDL

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

rmic [ options ] package-qualified-class-names

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

توضیحات (DESCRIPTION)

یادداشت منسوخ‌سازی: پشتیبانی از تولید ایستا برای 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 که کلاس‌های پیاده‌سازی شیء راه دور هستند، تولید می‌شوند. یک کلاس پیاده‌سازی راه دور، کلاسی است که رابط java.rmi.Remote را پیاده‌سازی می‌کند. نام‌های کلاس در دستور rmic باید متعلق به کلاس‌هایی باشند که با موفقیت توسط دستور javac کامپایل شده‌اند و باید نام کامل بسته (fully package qualified) داشته باشند. برای نمونه، اجرای دستور rmic بر روی نام فایل کلاس HelloImpl همان‌گونه که در اینجا نشان داده شده است، فایل HelloImpl_Stub.class را در زیردایرکتوری hello (که بر اساس بسته کلاس نام‌گذاری شده) ایجاد می‌کند:

rmic hello.HelloImpl

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

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

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

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

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

گزینه‌ها (OPTIONS)

-bootclasspath path

مکان فایل‌های کلاس bootstrap را بازنویسی (override) می‌کند.

-classpath path

مسیری را که دستور rmic برای یافتن کلاس‌ها استفاده می‌کند مشخص می‌سازد. این گزینه در صورت تنظیم، مقدار پیش‌فرض یا متغیر محیطی CLASSPATH را بازنویسی می‌کند. دایرکتوری‌ها با دو‌نقطه (:) از یکدیگر جدا می‌شوند. قالب کلی مسیر به این صورت است: .:<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

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

-g

تولید تمام اطلاعات اشکال‌زدایی (debugging)، از جمله متغیرهای محلی را فعال می‌کند. به‌صورت پیش‌فرض، فقط اطلاعات شماره خط تولید می‌شود.

-idl

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

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

•: گزینه‌های -always یا -alwaysgenerate تولید مجدد را اجباری می‌کنند، حتی اگر stubs/ties/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 تولید مجدد را اجباری می‌کنند، حتی اگر stubs/ties/IDL موجود از کلاس ورودی جدیدتر باشند.
•: گزینه -nolocalstubs به این معنی است که stubهای بهینه‌شده برای کلاینت‌ها و سرورهایی که در یک فرآیند مشابه هستند ساخته نشود.
•: گزینه -noValueMethods باید همراه با گزینه -idl استفاده شود. گزینه -noValueMethods از اضافه شدن متدها و مقداردهنده‌های اولیه valuetype به IDL خروجی جلوگیری می‌کند. این متدها و مقداردهنده‌های اولیه برای valuetypes اختیاری هستند و تولید می‌شوند مگر اینکه گزینه -noValueMethods به همراه گزینه -idl تعیین شده باشد.
•: گزینه -poa وراثت را از org.omg.CORBA_2_3.portable.ObjectImpl به org.omg.PortableServer.Servant تغییر می‌دهد. ماژول PortableServer برای Portable Object Adapter (POA) نوع محلی Servant را تعریف می‌کند. در زبان برنامه‌نویسی Java، نوع Servant به کلاس Java org.omg.PortableServer.Servant نگاشت می‌شود. این کلاس به عنوان کلاس پایه برای تمامی پیاده‌سازی‌های servant در POA عمل می‌کند و تعدادی متد را فراهم می‌آورد که می‌توانند توسط برنامه‌نویس فراخوانی شوند، و همچنین متدهایی که توسط POA فراخوانی شده و می‌توانند توسط کاربر برای کنترل جنبه‌هایی از رفتار servant بازنویسی (override) شوند. بر اساس مشخصات OMG IDL to Java Language Mapping Specification, CORBA V 2.3.1 ptc/00-01-08.pdf.

-J: در صورت استفاده با هر دستور Java، گزینه -J آرگومان بعد از -J را (بدون فاصله بین -J و آرگومان) به مفسر Java ارسال می‌کند.
-keep or -keepgenerated: فایل‌های منبع .java تولیدشده برای کلاس‌های stub، skeleton و tie را نگه می‌دارد و آن‌ها را در همان دایرکتوری فایل‌های .class می‌نویسد.
-nowarn: هشدارها را غیرفعال می‌کند. وقتی از گزینه -nowarn استفاده می‌شود، کامپایلر هیچ هشداری چاپ نمی‌کند.
-nowrite: کلاس‌های کامپایل‌شده را روی سیستم‌فایل نمی‌نویسد.
-vcompat (deprecated): کلاس‌های stub و skeleton سازگار با هر دو نسخه 1.1 و 1.2 پروتکل JRMP stub را تولید می‌کند. این گزینه در انتشار‌های پیش از 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 پروتکل JRMP stub تولید می‌کند. گزینه -v1.1 تنها برای تولید کلاس‌های stub کاربرد دارد که از نظر سریال‌سازی با کلاس‌های stub از پیش موجود و مستقرشده به صورت ایستا که توسط دستور rmic از JDK 1.1 تولید شده‌اند و امکان ارتقای آن‌ها وجود ندارد (و بارگذاری پویای کلاس استفاده نمی‌شود)، سازگار باشند. نکته: این گزینه منسوخ شده است. بخش توضیحات را ببینید.
-v1.2 (deprecated): (پیش‌فرض) کلاس‌های stub را تنها برای نسخه 1.2 پروتکل JRMP stub تولید می‌کند. هیچ کلاس 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