Название поддиректории — Содержание директории
Bin — Файлы приложения: файл. jar, файл. jad, MANIFEST.MF
classes — Откомпилированные и предварительно проверенные файлы. class
Res — Файлы ресурсов приложения, такие, как файлы изображений. png в формате PNG
Src — Файлы исходного приложения
tmpclasses — Откомпилированные, непроверенные файлы. class
Я не буду объяснять здесь проектировку самого приложения, поскольку эта тема лежит за пределами темы этой главы. Цель на данный момент заключается не в том, чтобы описать, как проектировать приложения Java или даже приложения MIDP. В последующих главах, однако, будет говориться об организации MIDP-приложений.
Следующим этапом в цикле разработки после создания вашей программы является компиляция исходной программы. Прежде чем вы приступите к компиляции, убедитесь, что список командных путей среды вашей оболочки включает маршрут к директории, в которой содержатся утилиты J2ME на вашем компьютере.
Общая форма строки компиляции представляет из себя следующее:
S javac — d <tmpclasses dir> — bootclasspath <midpapi.zip location> \
<location of Jva sourcce fie(s)>
Указание — d сообщает компилятору директорию, в которую нужно записывать непроверенные откомпилированные классы. Указание — bootclasspath указывает местоположение файла midpapi.zip, который поставляется вместе с инструментарием J2ME Wireless Toolkit, разработанным «Java Software», и содержит все классы MIDP, которые вам необходимы для написания приложений на J2ME. Среды разработки коммерческих производителей также включают этот файл. Указание — bootclasspath также сообщает компилятору о превосходстве над любой спецификацией CLASSPATH, которую вы, возможно, установили в среде своей оболочки. Заметьте, что это должен быть относительный маршрут доступа к файлу (relative pathname,) — относительный к корневой директории проекта. Наконец, вы указываете имена путей исходных файлов Java, которые вы компилируете.
Чтобы откомпилировать набор MID-летов HelloWorld из директории apps/HelloWorld/, используйте следующую команду:
$ javac — d tmpclasses \
— bootclasspach../../lib/midpapi.zip src/HelloWorld.Java
$
Указание — d сообщает компилятору записать непроверенные компилированные классы в директорию tmpclasses, которая является поддиректорией каталога HelloWorld/. Указание — bootclasspath определяет путевое имя относительно данного каталога. Наконец, последний параметр указывает относительное путевое имя исходного файла HelloWorld.Java.
Вы узнали, что библиотеки MIDP и CLDC определяют полную платформу для создания приложений на MIDP. Следовательно, вам не придется включать путь для любой J2SE установки в CLASSPATH вашей среды при компилировании ваших приложений. В действительности вы не можете включить его. Если вы это сделаете, вы получите ошибку компиляции, поскольку компилятор найдет конфликтующие определения в библиотеках J2SE и J2ME.
После завершения компиляции ваших файлов директория tmpclasses будет содержать непроверенные файлы. class:
$ Is — I tmpclasses/
total 0
— rw-r-r- 1 vartan None 922 HelloWorld.class
$
Следующим этапом после компиляции является предварительная проверка файлов. class, которые вы только что откомпилировали. Чтобы провести ее, запустите следующую команду:
$ preverify — classpath"../../lib/midpapi.zip;tmpclasses" — d classes \
tmpclasses
S
Если вы используете J2ME Wireless Toolkit, вы должны отделить элементы пути классов точками с запятой, или заключить их в кавычки, если вы используете оболочку Unix, чтобы избежать того, что оболочка начнет интерпретировать точки с запятой. Элементы путей классов представляют собой директории, из которых должны загружаться классы. Разделитель элемента пути класса — точка с запятой в данном случае — зависит от платформы.
Параметр — d указывает директорию, в которую должны быть записаны предварительно проверенные выходные классы, генерируемые с помощью этой команды. Наконец, имя замыкающей директории, tmpclasses, показывает местонахождение, из которого можно получить непроверенные файлы классов, которые были созданы на предыдущем этапе компиляции.
Запуск вышеуказанной команды preverify создает предварительно проверенные файлы. class в директории классов в соответствии с вашими указаниями:
S Is — I classes/
total 0
— rw-r-r- 1 vartan None 922 HelloWorld.class
$
Команда preverify является инструментом предварительной проверки файлов классов, который используется в процессе проверки файлов классов. Проверка файлов классов в CLDC, как и в J2SE, является процессом проверки истинности файлов классов Java и отклоняет неправильные файлы. Однако в отличие от процесса проверки в J2SE проверка файлов классов в CLDC включает два этапа:
— Этап 1 — предварительная проверка вне устройства;
— Этап 2 — проверка на устройстве.
Использование команды preverify, о которой мы только что говорили, представляет собой фазу предварительной проверки вне устройства — стадию 1 в двухэтапном процессе проверки. В реальной среде эта первая фаза обычно осуществляется на сервере, с которого MIDP-приложения загружаются на мобильные устройства. Обычно сервер выполняет это до того, как делает приложение доступным для загрузки.
Причина появления этого нового процесса проверки заключается в том, что обычный верификатор файлов классов J2SE требует больше памяти и возможностей по обработке данных, чем стандартные мобильные устройства могут реально предоставлять. Он использует около 50 Кб места под двоичный код и от 30 до 100 Кб динамической памяти при работе. Новый верификатор CLDC требует намного меньше RAM и является при этом намного более эффективным. Для стандартных файлов классов верификатор CLDC использует только около 10 Кб кодового пространства и требует только 100 байт динамической памяти при работе.
Новый верификатор может достигать такой высокой производительности благодаря новому алгоритму, который он использует. Этот новый алгоритм, однако, требует наличия специальных атрибутов в каждом файле классов Java. Верификатор предварительной проверки записывает эти новые атрибуты в каждый файл классов Java. Верификатор затем использует атрибуты, созданные верификатором предварительной проверки. Новые файлы классов приблизительно на 5 процентов больше, чем их немодифицированные версии.
Верификатор предварительной проверки выполняет две задачи:
— Он делает все запросы подпрограммы «линейными», замещая каждый запрос метода, который содерркит байтовые коды jsr, jsr_w, ret и wide ret, семантически эквивалентными кодами, которые не содержат этих команд.
— Он вставляет атрибуты стековой карты в то, что иначе является нормально форматированным файлом классов Java.
Эти новые файлы классов все еще являются действующими файлами классов J2SE. То есть новые атрибуты стековой карты просто игнорируются верификатором J2SE. Добавление атрибутов стековой карты было внедрено вместе с механизмом наращиваемых атрибутов, который поддерживается форматом файлов классов Java, определяемым стандартной виртуальной машиной Java. Это означает, что файлы классов CLDC являются совместимыми снизу вверх с виртуальной машиной J2SE.