Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
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. Это служит базовым классом для всех реализаций слуги 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, но это не должно наследоваться ни от какого другого класса, только интерфейсный 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 позволяет любое число интерфейсного наследования, но есть только один слот для наследования классов. Если Вы используете модель наследования, тот слот израсходован. При использовании Модели Связи тот слот освобождается для Вашего собственного использования. Недостаток - то, что это представляет уровень абстракции: один дополнительный вызов метода происходит, вызывая метод.
Генерировать серверную сторону, привязка модели Связи, которая является совместимой с версиями IDL на язык Java, отображающийся в версиях до J2SE 1.4.
idlj -oldImplBase -fall My.idl idlj -oldImplBase -fallTIE My.idl
Для интерфейсного My это генерирует My_Tie.java. Конструктор к My_Tie берет impl. Следует обеспечить реализацию для impl, но это не должно наследоваться ни от какого другого класса, только интерфейсный 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
Информация о версии также появляется в пределах привязки, сгенерированной компилятором. Игнорируются любые дополнительные опции, появляющиеся на командной строке.
#define symbol
#include файлы. -pkgTranslate foo bar -pkgTranslate foo.baz buzz.fizzСледующие преобразования произошли бы:
foo => bar foo.boo => bar.boo foo.baz => buzz.fizz foo.baz.bar => buzz.fizz.barСледующие имена пакета не могут быть преобразованы:
См. раздел Описания для большей информации об опции.
