Платформа J2Me
Шрифт:
— Этап 1 — предварительная проверка вне устройства;
— Этап 2 — проверка на устройстве.
Использование команды preverify, о которой мы только что говорили, представляет собой фазу предварительной проверки вне устройства — стадию 1 в двухэтапном процессе проверки. В реальной среде эта первая фаза обычно осуществляется на сервере, с которого MIDP-приложения загружаются на мобильные устройства. Обычно сервер выполняет это до того, как делает приложение доступным для загрузки.
Причина появления этого нового процесса проверки заключается в том, что обычный верификатор файлов классов J2SE требует больше памяти и возможностей по обработке данных,
Новый верификатор может достигать такой высокой производительности благодаря новому алгоритму, который он использует. Этот новый алгоритм, однако, требует наличия специальных атрибутов в каждом файле классов Java. Верификатор предварительной проверки записывает эти новые атрибуты в каждый файл классов Java. Верификатор затем использует атрибуты, созданные верификатором предварительной проверки. Новые файлы классов приблизительно на 5 процентов больше, чем их немодифицированные версии.
Верификатор предварительной проверки выполняет две задачи:
— Он делает все запросы подпрограммы «линейными», замещая каждый запрос метода, который содерркит байтовые коды jsr, jsr_w, ret и wide ret, семантически эквивалентными кодами, которые не содержат этих команд.
— Он вставляет атрибуты стековой карты в то, что иначе является нормально форматированным файлом классов Java.
Эти новые файлы классов все еще являются действующими файлами классов J2SE. То есть новые атрибуты стековой карты просто игнорируются верификатором J2SE. Добавление атрибутов стековой карты было внедрено вместе с механизмом наращиваемых атрибутов, который поддерживается форматом файлов классов Java, определяемым стандартной виртуальной машиной Java. Это означает, что файлы классов CLDC являются совместимыми снизу вверх с виртуальной машиной J2SE.
Атрибуты, которые верификатор предварительной проверки записывает в файлы классов CLDC, называются атрибутами стековой карты. Атрибуты стековой карты определяются структурой данных StackMap_attribute. Эти атрибуты являются субатрибутами атрибута Code, определяемого и используемого обычной виртуальной машиной J2SE. Имя стековая карта отражает природу атрибута как описания типа локальной переменной или элемента стека операндов. Такое имя выбрано потому, что эти элементы всегда находятся в стеке интерпретатора.
Тип Code_attribute является другим типом, определяемым стандартной виртуальной машиной. Он определяет атрибут Code, используемый стандартной виртуальной машиной J2SE. Для получения полного описания этих структур, пожалуйста, смотрите спецификацию виртуальной машины Java «Java Virtual Machine Specification», которая отмечена в разделе ссылок в конце этой книги. Верификатор предварительной проверки CLDC определяет следующую структуру Stackmap_attribute, которая определяет производный тип стековой карты, как изложено ниже:
StackMap_attribute
{
u2 attribute_name_index; u4 attribute_length; u2.iumber_of_entries;
u4 byte_code_offset;
{
u2 number_of_locals;
cy types_of_locals[number_of_locals];
u2 number_of_stack_iteras;
ty types_of_stack_items[nuraber_of_stack_iterns];
} entries [number_of_entriesj;
}
Для
Следующим этапом после предварительной проверки является упаковка приложения. Упаковка набора MID-летов включает 2 объекта:
— архивный файл Java файлов MID-лета;
— необязательный файл дескриптора приложения.
Хотя вы можете выбирать, упаковывать ли приложения J2SE для распаковки в дальнейшем, спецификация MIDP требует, чтобы вы упаковывали набор MID-летов с помощью утилиты архивации Java (JAR). В действительности спецификация MIDP требует, чтобы все наборы MID-летов переносились на устройства в сжатом файловом формате JAR. Обычно серверы, которые поддерживают перенос наборов MID-летов на устройства, хранят файлы наборов MID-летов в сжатом формате JAR. Либо сервер, либо компонент, который загружает файл на сервер, создает сжатый JAR-файл.
Архив JAR набора MID-летов может содержать несколько типов файлов, как показано в следующем списке:
— файл манифеста (manifest file) — файл, который описывает содержимое JAR-файла;
— файлы классов Java, которые содержат MID-леты из набора MID-летов архива;
— файлы ресурсов приложения, используемые MID-летами из набора MID-летов.
JAR Файл манифеста (manifest file) содержит атрибуты, которые описывают содержимое самого JAR-файла. Его наличие в JAR-файле необязательно.
Другой необязательный описательный файл, называемый файлом дескриптора приложения, содержит информацию о наборе MID-летов. Этот файл иногда называется дескриптором приложения Java (JAD). Каждый набор MID-летов может иметь связанный с ним файл описания.
Файл дескриптора приложения используется по двум причинам. Программное обеспечение управления приложениями устройства (AMS) использует информацию из этого файла для первоначальной проверки того, что все MID-леты в файле JAR соответствуют требованиям устройства, перед тем как оно загрузит полный файл JAR. AMS также использует эту информацию для управления MID-летом. AMS устройства отвечает за установку и удаление наборов MID-летов. Оно также обеспечивает MID-леты средой исполнения, требуемой спецификацией MIDP. Наконец, AMS управляет выполнением MID-летов, а именно запуском, приостановкой и закрытием всех MID-летов.
Наконец, сами MID-леты могут извлекать из конфигурации JAD-файла специфические атрибуты, которые представляют собой параметры MID-лета. Файл ресурсов приложения является основным механизмом для распаковки конфигураций MIDP-прило-жений.
ЕСЛИ вы хотите добавить файл Manifest к вашему заархивированному набору MID-летов, вам необходимо создать его прежде, чем вы создадите сам JAR-архив. Вы можете создать этот файл в любом текстовом редакторе. Потом создайте JAR-файл с помощью стандартной утилиты JAR J2SE. Утилита JAR включается в утилиты инструментария Wireless Toolkit.