Идеальная отправная точка — это developerWorks, ресурс IBM для разработчиков. Выберите в левой панели «Технология Java» и затем "IBM developer kits", чтобы перейти к ссылкам на инструментарии разработчиков IBM для различных платформ, включая AIX, Linux, OS/2, z/OS и Windows. Если вам нужен только комплект для AIX, нажмите здесь, затем выберите "загрузки" и получите перечень имеющихся выпусков Java. Затем можно выбрать конкретную версию JDK для загрузки установочных (базовых) образов.
Время от времени также появляются исправления программного обеспечения в виде в виде образов для обновления (временные исправления программ, PTF). Образы PTF являются обновлениями базовых образов; они устанавливаются поверх базовых образов и только после них. Как правило, PTF-обновления не являются кумулятивными и не включаются в состав базовых образов. На странице загрузки базовых образов можно выбрать "Как и где получить исправления" и узнать об имеющихся исправлениях и о том, как их получить. Можно также узнать дополнительные сведения по конкретной ошибке, исправляемой в PTF, если выбрать "Список исправлений."
Например, на странице загрузки базовых образов объявлен APAR IY47536. Это обновление августа 2003 года для JDK 1.4 32-bit, повышающее версию до 1.4.1 32-bit. Имея этот номер APAR, можно отправиться на страницу центра распределения исправлений для AIX и поискать по этому номеру APAR для системы AIX.
Обычно PTF обновляет лишь подмножество всех файлов продукта. Например, IY40840 обновляет
- Java14.debug
- Java14.sdk
- Java14.source
Если в системе установлены только Java14.samples или Java14.ext.java3d, то это обновление вообще не требуется. Даже если загрузить это обновление и попытаться установить его с помощью SMIT, установочное ПО AIX не найдет ничего, что нужно устанавливать на эту систему, и это поведение будет правильным.
Если речь идет о базовом образе, загруженном в виде packagename.tar либо packagename.tar.gz (последнее рекомендуется, если есть утилита gunzip), необходимо извлечь packagename из загруженного файла:
tar -xvf packagename.tar(пример: tar -xvf Java14.sdk.tar), илиgunzip -c packagename.tar.gz | tar -xvf -(пример: gunzip -c Java14.sdk.tar.gz | tar -xvf - )
Образы обновлений поставляются в виде готовых к установке файлов .bff, и распаковывать ничего не нужно.
Перед установкой удалите старый файл .toc, если он существует, в каталоге, содержащем распакованные базовые образы и образы обновлений .bff. Затем можно использовать команду smitty для установки из каталога, содержащего образы.
Ниже в таблице 1 приведены все версии Java на AIX, существующие на момент написания этой статьи. Для нескольких выпусков AIX в каждой версии Java есть только один набор образов. Например, Java 1.3.1 поддерживается на AIX 4.3.3, 5.1 и 5.2 с помощью одного и того же набора образов. Поддержка Java 1.3.0 закончилась 31 декабря 2002 года, поэтому ее нет в списке.
Как показывается в таблице 1, для каждой версии Java создаётся свой установочный каталог, поэтому несколько версий Java могут сосуществовать на AIX, если переменные среды, например, PATH, CLASSPATH и другие соответствующие переменные среды указывают на установочный каталог конкретной версии Java. Например, чтобы использовать Java1.2.2, установите
PATH=/usr/java_dev2/jre/sh:/usr/java_dev2/sh:$PATH |
Чтобы использовать версию Java 1.3.1 32-bit, установите
PATH=/usr/java131/jre/bin:/usr/java131/bin:$PATH |
Для каждой версии Java в таблице 1 показан минимальный требуемый уровень AIX. Обязательно проверьте столбец "документация, обязательная для чтения" для дополнительных PTF, которые нужно применить.
Таблица 1
| Версия JDK | Версия AIX | Минимальный требуемый уровень AIX | Наборы файлов | Установочный каталог | Документация, обязательная для чтения | Окончание обслуживания |
| Java 1.4.1 32-bit, загружается как IY47536 | 5.1, 5.2 | 5.1.0.0-04 или 5.2.0.0-01 | Java14.* | /usr/java14 | sdkguide.aix32.html в /usr/java14/docs/ | 30 апреля 2009 г. |
| Java 1.4.1 64-bit, загружается как IY43716 | 5.1, 5.2 | 5.1.0.0-04 или 5.2.0.0-01 | Java14_64.* | /usr/java14_64 | sdkguide.aix64.html в /usr/java14_64/docs/ | 30 апреля 2009 г. |
| Java 1.4 32-bit | 5.1, 5.2 | 5.1.0.0-03 or 5.2.0.0 | Java14.* | /usr/java14 | sdkguide.aix32.html в /usr/java14/ | 30 апреля 2009 г. |
| Java 1.4 64-bit | 5.1, 5.2 | 5.1.0.0-03 или 5.2.0.0 | Java14_64.* | /usr/java14_64 | sdkguide.aix64.html в /usr/java14_64/ | 30 апреля 2009 г. |
| Java 1.3.1 32-bit | 4.3.3, 5.1, 5.2 | 4.3.3.0-10 или 5.1.0.0-02 or5.2.0.0 | Java131.* | /usr/java131 | README в /usr/java131 | 31 декабря 2005 г. |
| Java 1.3.1 64-bit | 5.1, 5.2 | 5.1.0.0-02 или 5.2.0.0 | Java13_64.* | /usr/java13_64 | README в /usr/java13_64 | 31 декабря 2005 г. |
| Java 1.2.2 | 4.3.3, 5.1, 5.2 | 4.3.3.0 | Java_dev2.* | /usr/java_dev2 | README в /usr/java_dev2 | 30 апреля 2009 г. |
| Java 1.1.8 | 4.3.3, 5.1, 5.2 | 4.3.3 | Java.* | /usr/jdk_base | README в /usr/jdk_base | 31 декабря 2003 г. |
Определение установленной версии Java
Наиболее точную информацию возвращает команда java -fullversion или java -version.
Пример вывода команды java full version:
J2RE 1.4.1 IBM AIX build ca141-20030522 |
Дата 20030522 указывает, когда была собрана программа.
Поскольку в AIX могут сосуществовать несколько версий Java,
java -fullverion или java -version выдает информацию, отражающую текущую настройку переменной PATH. Если у вас несколько версий Java, используйте команду, указывающую на отдельные версии Java. Например, используйте /usr/java13_64/jre/bin/java -fullversion для поиска информации об уровне сборки 64-разрядной версии Java 1.3.1.
The JIT (Just-in-time Compiler )
Зачем нужен компилятор «на лету» (JIT)?
Чистые Java-приложения обладают безусловно высокой переносимостью. Исходный текст программы на Java трансформируется компилятором Java в байт-код Java. Этот байт-код не зависит от платформы и исполняется в виртуальной машине Java (JVM), которая его интерпретирует. JVM предоставляется поставщиком ОС для конкретной аппаратной платформы и является тем компонентом, который учитывает специфику платформы.
Интерпретирующая JVM последовательно считывает, транслирует и выполняет байт-код. После трансляции и выполнения то, что сделано, не кэшируется. Если логика приложения использует байт-код повторно, интерпретатор повторяет ту же работу. У этого механизма значительные ограничения в производительности в связи с малыми возможностями для оптимизации байт-кода.
JIT — это один из подходов, встроенных в некоторые JVM для преодоления этой унаследованной проблемы с производительностью интерпретатора Java. С JIT-компилятором работа производится в две фазы. Сначала JIT компилирует байт-код программы или его часть в оптимизированные команды машинного языка, а затем выполняет эти только что созданные команды. Во время фазы компиляции JIT применяет многие методы оптимизации, используемые стандартными компиляторами, в том числе встраивание и исключение избыточного кода. Созданный код еще и кэшируется для последующего повторного использования в течение жизни данного экземпляра JVM.
Смешанный режим интерпретации (MMI)
Цель компилятора JIT состоит в повышении производительности Java-программы во время выполнения. Но для объёмных приложений, таких, например, как Websphere, время запуска увеличилось бы на десятки минут, что совершенно неприемлемо. Введенная для решения этой проблемы технология MMI является мостом между интерпретатором и компилятором JIT, что позволяет использовать наилучшие характеристики обоих.
Технология MMI довольно сложна, но общий принцип относительно прост. Вкратце, MMI работает следующим образом:
- Методы Java интерпретируются для первых N выполнений, где N — заранее заданное пороговое значение.
- Во время этих N выполнений собирается профильная информация о том, как работает программа.
- Когда счетчик достигает N, этот метод работает с помощью JIT-компилятора, и JIT-компилятор использует профильную информацию для максимальной оптимизации.
Таким образом, для методов, используемых лишь изредка, не происходит больших затрат на JIT-трансляцию. Для часто используемых методов при достижении порогового числа делается трансляция с помощью JIT-компилятора, и время выполнения метода оптимизируется. Для недолго работающих приложений с ограниченным повторным использованием кода предпочтение отдается использованию интерпретатора и исключаются относительно высокие затраты на JIT-компиляцию. Для приложений, работающих дольше, с более высоким повторным использованием кода, делается JIT-компиляция и время выполнения минимизируется. Проблема медленного запуска для больших приложений также не имеет большого значения.
JIT-компилятор, разработанный в IBM Tokyo Research Labs, впервые появился в AIX JDK 1.1.8, и с тех пор самая свежая версия этого JIT-компилятора поставляется с каждым последующим выпуском JDK для AIX.
В следующей таблице перечислены версии JIT-компилятора, поставляемые со всеми версиями Java, поддерживаемыми в настоящее время на AIX.
| Версия JDK | Версия JIT | Технология MMI |
| 1.4.1 | 5.0 | Да |
| 1.4.0 | 5.0 | Да |
| 1.3.1 | 4.0 | Да |
| 1.2.2 | 3.5 | Нет |
| 1.1.8 | 3.1 | Нет |
В машине JVM на AIX JIT-компилятор используется в качестве стандартного режима выполнения, но у пользователей есть возможность его отключить. В большинстве случаев отключение используется в основном для отладки, когда есть подозрения на проблемы с JIT-компилятором и программой.
- Для выключения JIT:
- Введите в командной строке следующее:
- Для оболочки Korn shell:
export Java_COMPILER=NONE - Для оболочки Bourne shell:
Java_COMPILER=NONEexport Java_COMPILER - Для C shell:
setenv Java_COMPILER NONE - Используйте параметр -D в команде java для установки java.compiler в NONE, чтобы отменить стандартное поведение, или используйте настройки переменных среды:
java -Djava.compiler=NONE <myapp> - Для включения JIT установите переменную Java_COMPILER в "jitc" или включите JIT-компилятор с помощью командной строки:
java -Djava.compiler=jitc <myapp>
- Чтобы определить, включен ли JIT, введите в командной строке следующее:
java -versionЕсли JIT не используется, выводится сообщение с текстом:
JIT disabledЕсли JIT используется, выводится сообщение с текстом:
JIT enabled: jitc
JNI — это механизм, позволяющий Java-программе взаимодействовать с нативным кодом, например, программами на C и C++. Он широко используется в Java-приложениях по следующим причинам:
- Многие разработчики хотят воспользоваться преимуществами платформы Java, не отказываясь от огромных вложений в прежние программы, написанные на других языках.
- Java обладает очень высокой переносимостью, но не обеспечивает всех возможностей и (иногда) производительности, предоставляемых платформенно-зависимым языками, такими как C или C++. Некоторые разработчики предпочитают частично писать приложения на языке, отличном от Java, чтобы обеспечить необходимую производительность.
- Некоторым приложениям необходим код сторонних разработчиков, которого нет на Java.
- Некоторые приложения используют стороннее промежуточное ПО, которое не является чистым кодом Java.
Использование JNI существенно нарушает переносимость Java-приложений. Очевидно, что платформенно-зависимый код должен быть перенесен на целевую платформу. В итоге приходится сталкиваться со всеми классическими проблемами переноса, касающимися непереносимых API, платформенно-зависимой компиляции и связывания.
В зависимости от размера и сложности вашего платформенно-зависимого кода сборка совместно используемых библиотек или исполняемых файлов для платформенно-зависимых методов Java на AIX может быть непростым делом. Есть некоторые характерные для AIX особенности, о которых следует знать, таких как использование компилятора C или C++ на AIX 4.3, 5.1 и 5.2. Рекомендуем вам обратиться к учебнику из серии IBM Redbook Разработка и перенос приложений C и C++ на AIX, SG245674. Есть, однако, несколько важных замечаний к тому, что изложено в этом учебнике:
- Компоновщик AIX имеет функцию связывания во время исполнения, позволяющую оставлять символы неразрешенными до выполнения. Для всех выпусков AIX, имевшихся на время написания этой статьи, главный исполняемый файл должен компоноваться с использованием специального флага -brtl, чтобы обеспечить связывание во время исполнения. Хотя на AIX совместно используемые библиотеки могут создаваться со связыванием в период исполнения или без него, исполняемый файл команды Java на AIX скомпонован без параметра -brtl, поэтому связывание во время исполнения в нем не включено.
Из-за этого во всех общих библиотеках, используемых с JNI, должны быть разрешены все внешние ссылки. Если совместно используемая библиотека собрана так, что некоторые символы должны быть разрешены компоновщиком периода выполнения, вызов System.loadlibrary завершится неудачей. Правильность сборки совместно используемой библиотеки можно проверить с помощью команды
dumpНе должно быть записей ".." в списке импортируемых символов в выводе dump для платформенно-зависимых библиотек. Дополнительные сведения можно получить в документации, о которой уже говорилось выше. - 1.Чтобы получить доступ к Java-программе из приложения на C/C++, это приложение должно создать экземпляр JVM, а затем запустить файлы .class на этой JVM. Необходимо правильно установить CLASSPATH, чтобы JVM могла найти ваши файлы .class. С выпуска 1.2.2 комплекты Developer Kits for AIX используют расширение AIX, очень полезное для приложений, выполняющих сборку мусора. Это расширение можно включить с помощью параметра (-bM:UR), который сообщает системе, что в системных вызовах, которые делает приложение, нужно сохранять все пользовательские регистры общего назначения. Все главные исполняемые файлы в инструментарии разработчика, включая средства запуска JVM, скомпонованы с параметром -bM:UR. При разработке JNI-программы, которая создает JVM версии 1.2.2 или более поздних выпусков и присоединяется к ней, этот параметр необходим.
Параметр (-bM:UR) предназначен только для прикладных программ с главным исполняемым файлом; он не имеет никакого значения для совместно используемых модулей/библиотек и может привести к ошибкам, если используется для создания общей библиотеки.
- Побочный эффект этого требования состоит в том, что выполняемые JNI-программы, собранные с параметром -bM:UR, в том числе сторонние программные пакеты и пакеты, собранные для предыдущих выпусков Java на AIX, были собраны без этого параметра, и они НЕСОВМЕСТИМЫ с JVM этого выпуска. Совместимость исполняемой программы можно проверить с помощью команды
dump -ov. В выводе на стандартное устройство вывода будет показано, что modtype равен UR. Например, командаdump -ov /usr/java14/jre/bin/javaвыдает следующее:/usr/java14/jre/bin/java: ***Object Module Header*** # Sections Symbol Ptr # Symbols Opt Hdr Len Flags 4 0x0000cdac 941 72 0x1002 Flags=( EXEC DYNLOAD ) Timestamp = "Aug 13 12:27:17 2003" Magic = 0x1df (32-bit XCOFF) ***Optional Header*** Tsize Dsize Bsize Tstart Dstart 0x00009702 0x0000052e 0x00000038 0x10000128 0x2000082a SNloader SNentry SNtext SNtoc SNdata 0x0004 0x0002 0x0001 0x0002 0x0002 TXTalign DATAalign TOC vstamp entry 0x0005 0x0003 0x20000bc4 0x0001 0x20000b50 maxSTACK maxDATA SNbss magic modtype 0x00000000 0x80000000 0x0003 0x010b UR
В этой статье мы изложили начальную, но важную информацию по исполнению Java-приложений на AIX. Вы узнали, где взять инструментарий разработчика, как устанавливать и обновлять Java, как включать и выключать JIT-компилятор и где найти информацию о сборке нативного кода.
Не пропустите вторую часть этой серии статей, где будет обсуждаться модель памяти Java-процессов на AIX. Это поможет вам запускать JVM с размером кучи, подходящим для вашего приложения.
- Оригинал статьи
Running your Java application on AIX, Part 1: Getting started (EN).
- Загрузите комплекты для разработки на Java в AIX, упоминавшиеся в этой статье.
- В Центре распределения исправлений для AIX есть исправления для Java компиляторов.
- Книги из серии Redbooks: Разработка и перенос приложений C и C++ на AIX, SG245674, и другие.
Ли Ченг (Lee Cheng) работает старшим консультантом для поставщиков pSeries и программного обеспечения для AIX. Она предоставляет им поддержку для сертификации программного обеспечения, портирования и локализации приложений. Прежде чем присоединиться к группе RS/6000 ISV Technical Support, она работала разработчиком компиляторов и компонентов управления системой AIX. Ли обладает степенью магистра в области компьютерных наук, полученной в Университете Кентукки (University of Kentucky). Связаться с Ли можно по адресу chenglc@us.ibm.com.