rmic компилятор генерирует тупик и скелетные файлы класса (протокол JRMP) и тупик и файлы класса связи (протокол IIOP) для удаленных объектов. Эти файлы классов сгенерированы от скомпилированных классов языка программирования Java, которые являются классами реализации удаленного объекта. Удаленный класс реализации является классом, который реализует интерфейсный java.rmi.Remote. Имена классов в rmic команде должны быть для классов, которые были скомпилированы успешно с javac командой и должны быть полностью квалифицированным пакетом. Например, работая rmic на имени файла класса HelloImpl как показано здесь:
rmic hello.HelloImpl
создает файл HelloImpl_Stub.class в подкаталоге hello (названный по имени пакета класса).
Скелет для удаленного объекта является объектом серверной стороны протокола JRMP, у которого есть метод, который диспетчеризирует звонки в фактическую реализацию удаленного объекта.
Связь для удаленного объекта является объектом серверной стороны, подобным скелету, но который связывается с клиентом, использующим протокол IIOP.
Тупик является прокси клиентской стороны для удаленного объекта, который ответственен за передачу вызовов метода на удаленных объектах к серверу, где фактическая реализация удаленного объекта находится. Ссылка клиента на удаленный объект, поэтому, является фактически ссылкой на локальный тупик.
По умолчанию rmic генерирует тупиковые классы, которые используют 1.2 тупиковых версии протокола JRMP только, как будто опция -v1.2 была определена. (Отметьте, что опция -vcompat была значением по умолчанию в выпусках до 5.0.) Используют -iiop опция, чтобы генерировать тупик и классы связи для протокола IIOP.
Тупик реализует только удаленные интерфейсы, не любые локальные интерфейсы, которые также реализует удаленный объект. Поскольку тупик JRMP реализует тот же самый набор удаленных интерфейсов как удаленный объект непосредственно, клиент может использовать встроенные операторы языка программирования Java для проверки типа и броска. Для IIOP должен использоваться метод PortableRemoteObject.narrow.
ОПЦИИ
Путь-bootclasspath
Расположение переопределений файлов класса начальной загрузки
- путь пути к классу
Определяет путь rmic использование, чтобы искать классы. Эта опция переопределяет значение по умолчанию или переменную окружения ПУТИ К КЛАССУ, если это устанавливается. Каталоги разделяются двоеточиями. Таким образом общий формат для пути:
.:<your_path>
Например:
.:/usr/local/java/classes
Каталог-d
Определяет корневой целевой каталог для сгенерированной иерархии классов. Можно использовать эту опцию, чтобы определить целевой каталог для тупика, скелета, и файлов связи. Например, команда
% rmic -d /java/classes foo.MyClass
поместил бы тупик и скелетные классы, полученные из MyClass в каталог /java/classes/foo. Если опция -d не определяется, поведение по умолчанию состоит в том, как будто "-d ." был определен: иерархия пакета целевого класса создается в текущем каталоге, и файлы тупика/связи/скелета помещаются в пределах этого. (Отметьте, что в некоторых предыдущих версиях rmic, если -d не был определен, то иерархия пакета не создавалась, и все выходные файлы, были помещены непосредственно в текущем каталоге.)
Путь-extdirs
Расположение переопределений установленных расширений
-g
Генерация включений всей отладочной информации, включая локальные переменные. По умолчанию только информация о номере строки сгенерирована.
Причины rmic, чтобы генерировать IDL OMG для определенных классов и любых классов, на которые ссылаются. IDL обеспечивает просто декларативный, программирующий независимый от языка способ определить API объекта. IDL используется в качестве спецификации для методов и данных, которые могут быть записаны в и вызваны с любого языка, который обеспечивает привязку CORBA. Это включает Java и C++ среди других. См. (OMG) документ для полного описания.
Когда -idl опция используется, другие опции также включают:
- всегда или-alwaysgenerate
Регенерация сил, даже когда существующие тупики/связи/IDL более новы чем входной класс.
- фабрика
Ключевое слово фабрики использования в сгенерированном IDL.
-idlModule fromJavaPackage [.class] toIDLModule
Определяет отображение пакета IDLEntity. Например: -idlModule foo.bar my::real::idlmod.
-idlFile fromJavaPackage [.class] toIDLFile
Определяет отображение файла IDLEntity. Например: -idlFile test.pkg.X TEST16.idl.
Причины rmic генерировать тупик IIOP и классы связи, а не тупик JRMP и скелетные классы. Тупиковый класс является локальным прокси для удаленного объекта и используется клиентами, чтобы отправить звонки в сервер. Каждый удаленный интерфейс требует тупикового класса, который реализует тот удаленный интерфейс. Ссылка клиента на удаленный объект является фактически ссылкой на тупик. Классы связи используются на серверной стороне, чтобы обработать входящие вызовы, и диспетчеризировать звонки в надлежащий класс реализации. Каждый класс реализации требует класса связи.
Вызов rmic с -iiop генерирует тупики и связи, которые соответствуют этому соглашению о присвоении имен:
Когда -iiop опция используется, другие опции также включают:
- всегда или-alwaysgenerate
Регенерация сил, даже когда существующие тупики/связи/IDL более новы чем входной класс.
-nolocalstubs
Не создавайте тупики, оптимизированные для клиентов и серверов того-же-самого-процесса.
-noValueMethods
Должен использоваться с -idl опция. Предотвращает добавление методов valuetype и инициализаторов к испускаемому IDL. Эти методы и инициализаторы являются дополнительными для valuetype s, и сгенерированы, если опция -noValueMethods не определяется при использовании опции -idl.
-poa
Изменяет наследование от org.omg.CORBA_2_3.portable.ObjectImpl до org.omg.PortableServer.Servant. Модуль PortableServer для Переносимого Объектного Адаптера (POA) определяет собственный тип Servant. В языке программирования Java тип Servant отображается на Java класс org.omg.PortableServer.Servant. Это служит базовым классом для всех реализаций слуги POA и обеспечивает много методов, которые могут быть вызваны прикладным программистом, так же как методами, которые вызываются POA непосредственно и могут быть переопределены пользователем, чтобы управлять аспектами поведения слуги. Основанный на IDL OMG к Спецификации Отображения Языка Java, CORBA V 2.3.1 ptc/00-01-08.pdf.
-J
Используемый в соединении с любой опцией java, это передает опцию после -J (никакие пробелы между-J и опцией) на интерпретаторе java.
- сохраняют или-keepgenerated
Сохраняет сгенерированные исходные файлы .java для тупика, скелета, и/или классов связи и пишет им в тот же самый каталог как файлы .class.
-nowarn
Выключает предупреждения. Если использующийся компилятор не распечатывает предупреждений.
-nowrite
Не пишет скомпилированные классы файловой системы.
Генерирует тупик и скелетные классы, совместимые и с 1.1 и с 1.2 тупиковыми версиями протокола JRMP. (Эта опция была значением по умолчанию в выпусках до 5.0.) Сгенерированные тупиковые классы будут использовать 1.1 тупиковых версии протокола когда загружено в JDK 1.1 виртуальных машины и будут использовать 1.2 тупиковых версии протокола когда загружено в 1.2 (или позже) виртуальная машина. Сгенерированные скелетные классы будут поддерживать и 1.1 и 1.2 тупиковых версии протокола. Сгенерированные классы являются относительно большими, чтобы поддерживать оба режима работы.
- многословный
Заставляет компилятор и компоновщика распечатывать сообщения о том, какие классы компилируются и какие файлы класса загружаются.
Генерирует тупик и скелетные классы для 1.1 тупиковых версий протокола JRMP только. Отметьте, что эта опция только полезна для генерирования тупиковых классов, которые являются совместимыми с сериализацией с существованием ранее, статически развернутые тупиковые классы, которые были сгенерированы rmic инструментом от JDK 1.1 и это не может быть обновлено (и динамическая загрузка класса не используется).
(значение по умолчанию) Генерирует тупиковые классы для 1.2 тупиковых версий протокола JRMP только. Никакие скелетные классы не сгенерированы с этой опцией, потому что скелетные классы не используются с 1.2 тупиковыми версиями протокола. Сгенерированные тупиковые классы не будут работать, если они будут загружены в JDK 1.1 виртуальных машины.
ПЕРЕМЕННЫЕ ОКРУЖЕНИЯ
ПУТЬ К КЛАССУ
Используемый, чтобы обеспечить систему путь к определяемым пользователем классам. Каталоги разделяются двоеточиями. Например,
