rmic компилятор генерирует тупик и скелет файлы class (протокол JRMP) и тупик и связь файлы class (протокол IIOP) для удаленных объектов. Эти файлы классов сгенерированы от скомпилированных классов языка программирования Java, которые являются классами реализации удаленного объекта. Удаленным class реализации является class, который реализует интерфейс java.rmi.Remote. Имена class в rmic команде должны быть для классов, которые были скомпилированы успешно с javac командой и должны быть полностью квалифицированным пакетом. Например, работая rmic на имени файла class HelloImpl как показано здесь:
rmic hello.HelloImpl
создает файл HelloImpl_Stub.class в подкаталоге hello (названный по имени пакета class).
Скелет для удаленного объекта является серверным объектом протокола JRMP, у которого есть метод, который диспетчеризирует звонки в фактическую реализацию удаленного объекта.
Связь для удаленного объекта является серверным объектом, подобным скелету, но который связывается с клиентом, использующим протокол IIOP.
Тупик является клиентским прокси для удаленного объекта, который ответственен за передачу вызовов метода на удаленных объектах к серверу, где фактическая реализация удаленного объекта находится. Ссылка клиента на удаленный объект, поэтому, является фактически ссылкой на локальный тупик.
По умолчанию rmic генерирует тупиковые классы, которые используют 1.2 тупиковых версии протокола JRMP только, как будто опция -v1.2 была определена. (Отметьте, что опция -vcompat была значением по умолчанию в выпусках до 5.0.) Используют -iiop опция, чтобы генерировать тупик и классы связи для протокола IIOP.
Тупик реализует только удаленные интерфейсы, не любые локальные интерфейсы, которые также реализует удаленный объект. Поскольку тупик JRMP реализует тот же самый набор удаленных интерфейсов как удаленный объект непосредственно, клиент может использовать встроенные операторы языка программирования Java для проверки типа и броска. Для IIOP должен использоваться метод PortableRemoteObject.narrow.
ОПЦИИ
Путь-bootclasspath
Расположение переопределений начальной загрузки файлы class
- путь пути к классу
Определяет путь rmic использование, чтобы искать классы. Эта опция переопределяет значение по умолчанию или переменную окружения ПУТИ К КЛАССУ, если это устанавливается. Каталоги разделяются двоеточиями. Таким образом общий формат для пути:
.:<your_path>
Например:
.:/usr/local/java/classes
Каталог-d
Определяет корневой целевой каталог для сгенерированной иерархии class. Можно использовать эту опцию, чтобы определить целевой каталог для тупика, скелета, и файлов связи. Например, команда
% rmic -d /java/classes foo.MyClass
поместил бы тупик и скелетные классы, полученные из MyClass в каталог /java/classes/foo. Если опция -d не определяется, поведение значения по умолчанию состоит в том, как будто "-d ." был определен: иерархия пакета целевого class создается в текущем каталоге, и файлы тупика/связи/скелета помещаются в пределах этого. (Отметьте, что в некоторых предыдущих версиях rmic, если -d не был определен, то иерархия пакета не создавалась, и все выходные файлы, были помещены непосредственно в текущем каталоге.)
Путь-extdirs
Расположение переопределений установленных расширений
-g
Включает генерации всей отладочной информации, включая локальные переменные. По умолчанию только информация о номере строки сгенерирована.
Причины rmic, чтобы генерировать IDL OMG для определенных классов и любых классов, на которые ссылаются. IDL обеспечивает просто декларативный, программирующий независимый от языка способ определить API объекта. IDL используется в качестве спецификации для методов и данных, которые могут быть записаны в и вызваны с любого языка, который обеспечивает привязку CORBA. Это включает Java и C++ среди других. См. (OMG) документ для полного описания.
Когда -idl опция используется, другие опции также включают:
- всегда или-alwaysgenerate
Регенерация сил, даже когда существующие тупики/связи/IDL более новы чем ввод class.
- фабрика
Ключевое слово фабрики использования в сгенерированном 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 и скелетные классы. Тупиковый class является локальным прокси для удаленного объекта и используется клиентами, чтобы отправить звонки в сервер. Каждый удаленный интерфейс требует тупикового class, который реализует тот удаленный интерфейс. Ссылка клиента на удаленный объект является фактически ссылкой на тупик. Классы связи используются на стороне сервера, чтобы обработать входящие вызовы, и диспетчеризировать звонки в надлежащую реализацию class. Каждая реализация class требует связи class.
Вызов rmic с -iiop генерирует тупики и связи, которые соответствуют этому соглашению о присвоении имен:
Когда -iiop опция используется, другие опции также включают:
- всегда или-alwaysgenerate
Регенерация сил, даже когда существующие тупики/связи/IDL более новы чем ввод class.
-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 class. Это служит основным class для всех реализаций слуги 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 тупиковых версии протокола. Сгенерированные классы являются относительно большими, чтобы поддерживать оба режима работы.
- многословный
Заставляет компилятор и компоновщика распечатывать сообщения о том, какие классы компилируются и какие файлы class загружаются.
Генерирует тупик и скелетные классы для 1.1 тупиковых версий протокола JRMP только. Отметьте, что эта опция только полезна для генерирования тупиковых классов, которые являются совместимыми с сериализацией с существованием ранее, статически развернутые тупиковые классы, которые были сгенерированы rmic инструментом от JDK 1.1 и это не может быть обновлено (и динамическая загрузка class не используется).
(значение по умолчанию) Генерирует тупиковые классы для 1.2 тупиковых версий протокола JRMP только. Никакие скелетные классы не сгенерированы с этой опцией, потому что скелетные классы не используются с 1.2 тупиковыми версиями протокола. Сгенерированные тупиковые классы не будут работать, если они будут загружены в JDK 1.1 виртуальных машины.
ПЕРЕМЕННЫЕ ОКРУЖЕНИЯ
ПУТЬ К КЛАССУ
Используемый, чтобы обеспечить систему путь к определяемым пользователем классам. Каталоги разделяются двоеточиями. Например,
