|
Вот и дошли мы до логичного завершения нашего учебного курса. Вы наверняка успели потренироваться в написании сценариев объектов IDL. И, конечно, обратили внимание на разнобой, царящий в инструментарии для трансляции. Поэтому неслучайно предыдущее занятие мы завершили репликой «Знай свой компилятор IDL», а заключительное посвятили рассмотрению наиболее популярных и доступных компиляторов: - idltojava из пакета Java 2 корпорации Sun Microsystems;
- idl2java из пакета Visibroker компании Inpise;
- idl из пакета OrbixWeb фирмы IONA Technologies.
Однако есть и другая причина, почему именно эти три программы попали в поле нашего зрения. Дело в том, что пробные версии OrbixWeb и Visibroker могут быть получены через Web-узлы http://www.iona.com и http://www.inprise.com, а Java 2 с набором утилит, включающих idltojava, так и вовсе распространяется бесплатно. Как гласит поговорка, сходная ситуация рождает сходные мысли. То же самое можно сказать и про компиляторы IDL. Раз уж они выполняют одну и ту же задачу, то у них имеются и общие опции. Так, практически все компиляторы обладают ключиками, которые в явной форме говорят, где искать включаемые файлы, указанные в IDL-файле директивой препроцессора #include. То же можно сказать и об опциях задания каталога вывода, куда записываются результаты компиляции. Отдельно несколько слов об tie-архитектуре. Несмотря на название, внушающее опасение, здесь ничего сложного нет. Как известно, в современном объектно-ориентированном программировании есть всего два способа создания новых объектов: наследование и агрегация. В первом случае новый объект наследует все свойства и методы родительского объекта, добавляя к этому «джентльменскому набору» свои собственные методы и свойства. По сути, новый объект считает родительские составляющие своей собственностью. Что же касается агрегации, то здесь дело обстоит чуть сложнее. Создаваемый новый объект хранит ссылку на другой объект, чьи функции он собирается позаимствовать. Если к новому объекту обращаются за сервисом, имеющимся в объекте-предке, то создаваемый объект через хранимую ссылку передает запрос к старому объекту, который и делает основную работу. Подобный подход принят в объектных моделях Microsoft COM и DCOM. В CORBA же он называется tie. Не огорчайтесь, если вы не поняли, для чего служит та или иная опция, или вас озадачил непонятный термин. В учебном курсе, посвященном CORBA, вы найдете ответы на многие вопросы.
А теперь собственно о компиляторах.Java 2Самый простой компилятор IDL удалось найти в наборе Sun JDK 1.2, иначе называемом Java 2. Из трех приведенных в этой статье компиляторов компилятор idltojava оказался самым рудиментарным и... неаккуратным, хотя и наиболее быстрым. Его главная особенность — отсутствие препроцессора. Взамен idltojava по переменным среды пытается обнаружить препроцессор от компилятора языков Cи/Cи++. Сложность состоит в том, что искомый препроцессор должен выводить результаты своей работы в стандартный поток вывода, т. е. на экран, откуда они будут перехвачены и переданы на трансляцию в исходные тексты на языке Java. Лучше всего, как это ни странно, с этими обязанностями справляется препроцессор из компилятора Microsoft Visual C++. Экая гремучая смесь! Вторая особенность, точнее, недоделка, в том, что исходники, полученные в результате трансляции, выполнены в переносимом стиле, рекомендуемом комитетом OMG, т. е. не содержат метода bind() для получения ссылки на объект. На первый взгляд, это нормально, поскольку метод bind() не описан в спецификации CORBA, а следовательно, и не нужен. Но общепринятая практика создания CORBA-приложений показывает, что довольно часто удобно пользоваться именно методом bind(), вместо того чтобы колдовать с сервисом имен (Naming Service). Судя по всему, разработчики из Sun Microsystems решили, что сервера имен из Java 2 вполне хватит. А зря. Вот конкурирующие фирмы в своих изделиях предусмотрели генерацию bind(), одновременно оставив программисту возможность отключать данную возможность через опции командной строки.
Итак, вот формат запуска компилятора idltojava:
idltojava [ <опции> | <флаги> ] <имя файла>.idl
Опций у него немного (табл. 1), зато флагов побольше (табл. 2). Флаги могут быть включенными или выключенными. Если упомянуть имя флажка, то он будет включен:
-f<флаг>
Если же после префикса -f вставить no-, флаг выключается:
-fno-<флаг>
По умолчанию включены следующие флаги:
-fclient
-fcpp
-fportable
-fserver
-fwrite-files
и выключены:
-fcaseless
-flist-flags
-flist-options
-fmap-included-files
-ftie
-fverbose
-fversion Следует также отметить, что создатели idltojava не очень-то внимательно читали спецификацию CORBA, поэтому случается, что компилятор производит ошибочную генерацию исходных текстов. Таблица 1. Опции компилятора idltojava из пакета Java 2| -j <каталог> | Определяет каталог, куда компилятор IDL должен поместить сгенерированные Java-файлы. Между опцией и именем каталога обязательно должен быть символ пробела! | | -I <каталог> | Говорит компилятору, где искать включаемые файлы, отмеченные директивой препроцессора #include в IDL-файле | | -D <имя> | Определяет макроопределение с именем, заданным параметром <имя> | | -U <имя> | Отменяет макроопределение с именем, заданным параметром <имя>. Является противоположностью опции -D |
Таблица 2. Флаги компилятора idltojava из пакета Java 2| -fcaseless | Говорит компилятору не обращать внимание на регистр идентификаторов при сравнении | | -fclient | Указывает на необходимость генерации клиентской части | | -fcpp | Запускает препроцессор Cu/Cu++. Препроцессор ищется компилятором по значению переменной среды CPP, в которой должен быть прописан полный путь к запускаемому файлу препроцессора. Вторая важная переменная среды — CPPARGS, задающая аргументы препроцессора | | -flist-flags | Вызывает показ текущего состояния всех флагов | | -flist-options | Распечатывает на экране список опций командной строки | | -fmap-included-files | Производит трансляцию всех файлов, включенных директивой #include | | -fportable | Генерирует переносимые скелеты и заглушки в соответствии с рекомендациями комитета OMG | | -fserver | Указывает на необходимость генерации серверной части | | -ftie | Указывает на то, что генерация Java-файлов должна производиться для tie-архитектуры. Если флаг -fserver выключен, то -ftie игнорируется | | -fverbose | Отображает детали процесса компиляции | | -fversion | Печатает версию компилятора idltojava print its version | | -fwrite-files | Дает команду записывать полученные в результате компиляции файлы на диск |
VisibrokerInprise Visibroker (в данном случае мы говорим о версии 3.4) — очень серьезный продукт. Он напоминает хорошо отлаженный станок для получения кода. И, как всякий прецизионный инструмент, несколько медлителен в работе. Если не указать никаких опций, то от обилия полученных исходных текстов зарябит в глазах! Тут вам и стандартные файлы, и классы, необходимые для получения приложений на основе tie-архитектуры, и даже пример того, как можно создать серверный объект на основе сгенерированных интерфейсов и классов. Имя этого класса начинается с префикса _example_. Общий вид командной строки для запуска компилятора из Visibroker следующий: idl2java [<опции>] <имя файла>.idl OrbixWebСамый серьезный конкурент Inprise Visibroker — OrbixWeb от IONA. Этот пакет также сделан очень и очень тщательно, и компилятор IDL в его составе весьма хорош. Чтобы использовать его, наберите командную строку по следующей схеме:
idl [ <опции> ] <имя файла>.idl
Опции помогут настроить среду компиляции под ваши нужды (табл. 4).
Если взглянуть на значение ключей командной строки, то становится очевидно, насколько близко друг к другу следуют мысли разработчиков из Inpise и IONA. Набор ключей компиляции, несмотря на разные буквы, столь одинаков! Поэтому опытному разработчику не составит труда использовать оба компилятора. Корпорация Inprise даже пошла на беспрецедентный шаг — включила в среду пакета JBuilder 3 возможность вызывать компилятор IONA OrbixWeb вместо своего собственного! Таблица 3. Опции компилятора idl2java из пакета Visibroker| -package <имя> | Говорит компилятору поместить сгенерированные Java-файлы в пакет с именем, взятым из параметра <имя> | | -root_dir <каталог> | Изменяет каталог, в который записываются сгенерированные файлы. Вместо каталога по умолчанию будет использован тот, который указан в параметре <каталог> | | -idl2package idl pkg | Задает правила трансляции имен IDL в пакеты Java. Например, следующая строка -idl2package ::CORBA org.omg.CORBA говорит, что любое имя IDL, находящееся внутри области видимости ::CORBA, будет транслироваться и помещаться в пакет org.omg.CORBA в соответствии с правилами трансляции спецификации CORBA | | -version | Отображает версию Visibroker for Java | | -portable | Включает генерацию переносимых заглушек, использующих DII. Без этой опции idl2java генерирует специфические для VisiBroker исходные тексты | | -strict | Генерирует исходные тексты для кода, который может быть запущен в любой системе с ORB, совместимой со спецификацией CORBA. По своей сути опция -strict эквивалентна включенным опциям -portable, -no_toString, -no_bind при одновременно выключенных -serializable, -smart_stub и -obj_wrappers | | -smart_stub | В Helper-классе создает дополнительные методы, используемые для установки и использования «хитрых» заглушек | | -incl_files_code | Генерирует исходные тексты Java для включаемых файлов | | -all_serializable | При установленной опции все структуры, исключения, энумераторы и дискриминируемые объединения реализуют интерфейс java.io.Serializable | | -serializable | Тип данных, получаемый в результате трансляции идентификатора из параметра , должен реализовать интерфейс java.io.Serializable | -map_keyword <ключевое слово> <соответствие> | Добавляет слово из параметра <ключевое слово> в список ключевых слов и ассоциирует его с Java-идентификатором из параметра <соответствие>. С этого момента любой идентификатор, конфликтующий с тем, который задан в параметре <ключевое слово>, будет транслирован в Java в идентификатор, заданный параметром <ключевое слово> | | -no_stub | Отключает генерацию исходных текстов для заглушек | | -no_skel | Отключает генерацию исходных текстов для скелетов | | -deprecated_skel | Включает генерацию скелетов с устаревшими именами. В ранних версиях Visibroker имена скелетов соответствовали схеме _sk_<имя интерфейса>, тогда как по новой схеме имена соответствуют схеме _<имя интерфейса>ImplBase. Данная опция нужна для совместимости с системами, построенными раньше | | -no_comments | Отключает автоматическую генерацию комментариев к получаемым исходным текстам | | -no_examples | По умолчанию Visibroker генерирует пример реализации объекта. Данная опция подавляет создание такого рода примера | | -no_tie | Указывает на то, что для tie-архитектуры генерация Java-файлов производиться не должна | | -no_toString | Отключает генерацию метода toString() | | -no_bind | Указывает компилятору не создавать метода bind() |
17.10.1999г.
|