Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

idlj - Компилятор IDL к Java

idlj генерирует привязку Java от данного файла IDL.

Резюме

idlj [ options ] idl-file

где idl-файл является именем файла, содержащего Язык определения интерфейсов (IDL) определения. Опции могут появиться в любом порядке, но должны предшествовать idl-файлу.

Описание

Компилятор IDL к Java генерирует привязку Java для данного файла IDL. Для того, чтобы связать детали, см. IDL OMG к Спецификации Отображения Языка Языка Java. Некоторые предыдущие выпуски компилятора IDL к Java назвали idltojava.

Испускание Привязки Клиента и сервера

Генерировать привязку Java для файла IDL по имени My.idl:

idlj My.idl

Это генерирует клиентскую привязку и эквивалентно:

idlj -fclient My.idl

Клиентская привязка не включает серверный скелет. Если Вы хотите генерировать серверную привязку для интерфейсов:

idlj -fserver My.idl

Серверная привязка включает клиентскую привязку плюс скелет, вся из которой POA (то есть, Модель Наследования) классы. Если Вы хотите генерировать и клиент и серверную привязку, используйте одну из следующих (эквивалентных) команд:

idlj -fclient -fserver My.idl
idlj -fall My.idl

Есть две возможных серверных модели: Модель Наследования и Модель Делегации Связи.

Серверная модель значения по умолчанию является Переносимой Моделью Наследования Слуги. Учитывая интерфейс My, определенный в My.idl, файл сгенерирован MyPOA.java. Следует обеспечить реализацию для My, и это должно наследоваться от MyPOA.

MyPOA.java является основанным на потоке скелетом, который расширяет org.omg.PortableServer.Servant и реализует интерфейс InvokeHandler, и интерфейс операций, связанный с IDL, соединяют интерфейсом со скелетными реализациями.

Модуль PortableServer для Переносимого Объектного Адаптера (POA) определяет собственный тип Servant. В языке программирования Java тип Servant отображается на Java org.omg.PortableServer.Servant class. Это служит основным class для всех реализаций слуги POA и обеспечивает много методов, которые могут быть вызваны прикладным программистом, так же как методами, которые вызываются POA непосредственно и могут быть переопределены пользователем, чтобы управлять аспектами поведения слуги.

Другая опция для Модели Наследования должна использовать флаг -oldImplBase, чтобы генерировать серверную привязку, которая является совместимой с версиями языка программирования Java до J2SE 1.4. Отметьте, что использование флага -oldImplBase нестандартно: эти API осуждаются. Вы использовали бы этот флаг ТОЛЬКО для совместимости с существующими серверами, записанными в J2SE 1.3. В этом случае Вы должны были бы изменить существующий MAKE-ФАЙЛ, чтобы добавить флаг -oldImplBase к компилятору idlj, иначе POA-на-основе серверные отображения будут сгенерированы. Генерировать серверную привязку, которая является назад совместимой:

idlj -fclient -fserver -oldImplBase My.idl
idlj -fall -oldImplBase My.idl

Учитывая интерфейс My, определенный в My.idl, файл сгенерирован _MyImplBase.java. Следует обеспечить реализацию для My, и это должно наследоваться от _MyImplBase.

Другую серверную модель вызывают Моделью Связи. Это - модель делегации. Поскольку не возможно генерировать связи и скелеты одновременно, они должны быть сгенерированы отдельно. Следующие команды генерируют привязку для Модели Связи:

idlj -fall My.idl
idlj -fallTIE My.idl

Для интерфейса My вторая команда генерирует MyPOATie.java. Конструктор к MyPOATie берет delegate. В этом примере, используя значение по умолчанию модель POA, конструктор также нуждается в poa. Следует обеспечить реализацию для delegate, но это не должно наследоваться ни от какого другого class, только интерфейс MyOperations. Но использовать это с ШАРОМ, следует обернуть свою реализацию в пределах MyPOATie. Например:

    ORB orb = ORB.init(args, System.getProperties());

    // Get reference to rootpoa & activate the POAManager
    POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
    rootpoa.the_POAManager().activate();

    // create servant and register it with the ORB
    MyServant myDelegate = new MyServant();
    myDelegate.setORB(orb); 

    // create a tie, with servant being the delegate.
    MyPOATie tie = new MyPOATie(myDelegate, rootpoa);

    // obtain the objectRef for the tie
    My ref = tie._this(orb);

Вы могли бы хотеть использовать модель Связи вместо типичной модели Наследования, если Ваша реализация должна наследоваться от некоторой другой реализации. Java позволяет любое число наследования интерфейса, но есть только один слот для наследования class. Если Вы используете модель наследования, тот слот израсходован. При использовании Модели Связи тот слот освобождается для Вашего собственного использования. Недостаток - то, что это представляет уровень абстракции: один дополнительный вызов метода происходит, вызывая метод.

Генерировать сторону сервера, привязка модели Связи, которая является совместимой с версиями IDL на язык Java, отображающийся в версиях до J2SE 1.4.

idlj -oldImplBase -fall My.idl
idlj -oldImplBase -fallTIE My.idl

Для интерфейса My это генерирует My_Tie.java. Конструктор к My_Tie берет impl. Следует обеспечить реализацию для impl, но это не должно наследоваться ни от какого другого class, только интерфейс HelloOperations. Но использовать это с ШАРОМ, следует обернуть свою реализацию в пределах My_Tie. Например:

    ORB orb = ORB.init(args, System.getProperties());

    // create servant and register it with the ORB
    MyServant myDelegate = new MyServant();
    myDelegate.setORB(orb); 

    // create a tie, with servant being the delegate.
    MyPOATie tie = new MyPOATie(myDelegate);

    // obtain the objectRef for the tie
    My ref = tie._this(orb);

Определение Альтернативных Расположений для Испускаемых Файлов

Если Вы хотите направить испускаемые файлы к каталогу кроме текущего каталога, вызовите компилятор как:

idlj -td /altdir My.idl

Для интерфейса My привязка будет испускаться к /altdir/My.java, и т.д., вместо ./My.java.

Определение Альтернативных Расположений для Включает Файлы

Если My.idl, включенный другой idl файл, MyOther.idl, компилятор предполагает, что MyOther.idl находится в локальном каталоге. Если бы это находится в /includes, например, то Вы вызвали бы компилятор со следующей командой:

idlj -i /includes My.idl

Если My.idl также включенный Another.idl, который находился в /moreIncludes, например, то Вы вызовете компилятор со следующей командой:

idlj -i /includes -i /moreIncludes My.idl

Начиная с этой формы включают, может стать раздраженно длинным, другое средство указания к компилятору, где искать включенные файлы, обеспечивается. Этот метод подобен идее переменной окружения. Создайте файл под названием idl.config в каталоге, который перечисляется в Вашем ПУТИ К КЛАССУ. В idl.config, предоставьте строке следующую форму:

includes=/includes;/moreIncludes

Компилятор найдет этот файл, и чтение во включает список. Отметьте, что в этом примере символ разделителя между этими двумя каталогами является точкой с запятой (;). Этот символ разделителя является зависимой платформой. На платформе Windows используйте точку с запятой, на платформе Unix, используйте двоеточие и т.д. Для получения дополнительной информации по includes см. Установку Пути к классу.

Испускание Привязки для Включает Файлы

По умолчанию только тем интерфейсам, structs, и т.д., которые определяются в idl файле на командной строке, генерировали привязку Java для них. Типы, определенные во включенных файлах, не сгенерированы. Например, примите следующие два idl файла:


My.idl

#include <MyOther.idl>
interface My
{
};

MyOther.idl

interface MyOther
{
};

Следующая команда только генерирует привязку java для My:

idlj My.idl

Чтобы генерировать все типы в My.idl и все типы в файлах, которые My.idl включает (в этот пример, MyOther.idl), используют следующую команду:

idlj -emitAll My.idl

Есть протест к правилу значения по умолчанию. операторы #include, которые появляются в глобальной области видимости, обрабатываются как описано. Эти операторы #include могут считаться операторами импорта. операторы #include, которые появляются в пределах некоторого контекста включения, обрабатываются как истинные операторы #include, означая, что код в пределах включенного файла обрабатывается, как будто это появилось в исходном файле и, поэтому, привязка Java испускается для этого. Вот пример:


My.idl

#include <MyOther.idl>
interface My
{
  #include <Embedded.idl>
};

MyOther.idl

interface MyOther
{
};

Embedded.idl

enum E {one, two, three};

Выполнение следующей команды:

idlj My.idl

генерирует следующий список файлов Java:

./MyHolder.java
./MyHelper.java
./_MyStub.java
./MyPackage
./MyPackage/EHolder.java
./MyPackage/EHelper.java
./MyPackage/E.java
./My.java

Заметьте, что MyOther.java не был сгенерирован, потому что он определяется в подобном импорту #include. Но E.java был сгенерирован, потому что он был определен в истинном #include. Также заметьте, что, так как Embedded.idl был включен в рамках интерфейса My, это появляется в рамках My (то есть, в MyPackage).

Если флаг-emitAll использовался в предыдущем примере, то все вводит все включенные файлы, был бы испущен.

Вставка Префиксов Пакета

Предположите, что Вы работаете на компанию, названную ABC, которая создала следующий файл IDL:


Widgets.idl

module Widgets
{
  interface W1 {...};
  interface W2 {...};
};

Петляние через компилятор IDL к Java поместит привязку Java для W1 и W2 в пределах пакета Widgets. Но есть отраслевое соглашение, которое утверждает, что пакеты компании должны находиться в пределах пакета под названием com.<company name>. Пакет Widgets не достаточно хорош. Чтобы следовать за соглашением, это должен быть com.abc.Widgets. Чтобы поместить этот префикс пакета на модуль Widgets, выполните следующее:

idlj -pkgPrefix Widgets com.abc Widgets.idl

Если у Вас есть файл IDL, который включает Widgets.idl, флаг-pkgPrefix должен появиться в той команде также. Если это не сделает, то Ваш файл IDL будет искать пакет Widgets, а не пакет com.abc.Widgets.

Если у Вас есть много этих пакетов, которые требуют префиксов, могло бы быть легче разместить их в файл idl.config, описанный выше. Каждая строка префикса пакета должна иметь форму:

PkgPrefix.<type>=<prefix>
Таким образом, строка для вышеупомянутого примера была бы:
PkgPrefix.Widgets=com.abc

Использование этой опции не влияет на ID Репозитария.

Определение Символов Перед Компиляцией

Вы, возможно, должны определить символ для компиляции, которая не определяется в пределах файла IDL, возможно чтобы включать код отладки в привязку. Команда

idlj -d MYDEF My.idl

эквивалент помещения строки #define MYDEF в My.idl.

Сохранение Существующей ранее Привязки

Если Java, обязательные файлы уже существуют, - сохранит флаг, то будет препятствовать компилятору перезаписывать их. Значение по умолчанию должно генерировать все файлы, не рассматривая, существуют ли они уже. Если Вы настроили те файлы (который недопустимо сделать, если Вы не очень довольны их содержанием), то - сохраняют опцию, очень полезно. Команда

idlj -keep My.idl

испускает всю клиентскую привязку, которая уже не существует.

Просмотр Продвижения Компиляции

Компилятор IDL к Java генерирует сообщения о состоянии, в то время как он прогрессирует через свои фазы выполнения. Используйте опцию -v, чтобы активировать этот "многословный" режим:

idlj -v My.idl

По умолчанию компилятор не работает в многословном режиме.

Отображение Информации о версии

Чтобы вывести на экран создавать версию компилятора IDL к Java, определите - опция версии на командной строке:

idlj -version

Информация о версии также появляется в пределах привязки, сгенерированной компилятором. Игнорируются любые дополнительные опции, появляющиеся на командной строке.

Опции

Символ-d
Это эквивалентно следующей строке в файле IDL:
#define symbol
-emitAll
Испустите все типы, включая найденных в #include файлы.
-fside
Определяет что привязку испустить. сторона является одним из client, server, serverTIE, all, или allTIE. Опции -fserverTIE И -fallTIE заставляют скелеты модели делегата испускаться. Принимает -fclient, если флаг не определяется.
Включать-путь-i
По умолчанию текущий каталог сканируется для включенных файлов. Эта опция добавляет другой каталог.
- сохраняют
Если файл, который будет сгенерирован уже, существует, не перезаписывайте его. По умолчанию это перезаписывается.
-noWarn
Подавляет предупреждающие сообщения.
-oldImplBase
Генерирует скелеты, совместимые с пред1.4 ШАРАМИ JDK. По умолчанию серверная привязка Модели Наследования POA сгенерирована. Эта опция предоставляет прежней совместимости более старые версии языка программирования Java, генерируя серверную привязку, которая является классами Модели Наследования ImplBase.
-pkgPrefix вводят префикс
Везде, где с типом встречаются в контексте файла, снабдите префиксом сгенерированное имя пакета Java префикс для всех файлов, сгенерированных для того типа. Тип является простым именем или высокоуровневого модуля, или типа IDL, определенного за пределами любого модуля.
-pkgTranslate вводят пакет
Всякий раз, когда с типом имени модуля встречаются в идентификаторе, замените его в идентификаторе с пакетом для всех файлов в сгенерированном пакете Java. Обратите внимание на тот pkgPrefix, изменения делаются первыми. тип является простым именем или высокоуровневого модуля, или типа IDL, определенного за пределами любого модуля, и должен соответствовать полное имя пакета точно.

Если больше чем одно преобразование соответствует идентификатор, самое долгое соответствие выбирается. Например, если параметры включают:
  -pkgTranslate foo bar -pkgTranslate foo.baz buzz.fizz
Следующие преобразования произошли бы:
foo          => bar
foo.boo      => bar.boo
foo.baz      => buzz.fizz
foo.baz.bar  => buzz.fizz.bar
Следующие имена пакета не могут быть преобразованы: Любая попытка преобразовать эти пакеты приведет к некомпилируемому коду, и использованию этих пакетов как первый параметр после того, как -pkgTranslate будет обработан как ошибка.
-skeletonName xxx%yyy
Используйте xxx%yyy в качестве образца для того, чтобы назвать скелет. Значения по умолчанию:
dir-td
Используйте dir для выходного каталога вместо текущего каталога.
-tieName xxx%yyy
Назовите связь согласно образцу. Значения по умолчанию:
-nowarn, - многословный
Многословный режим.
- версия
Выведите на экран информацию о версии и оконечный.

См. раздел Описания для большей информации об опции.

Ограничения:

Известные проблемы:


Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами