Java обживает мир встроенных систем

Теперь «блудный сын» полон решимости вернуться в родные владения в качестве языка программирования для встроенных систем.

Устройствам, для которых необходимо «общение» друг с другом или наличие соединения с Internet, могут пригодиться соответствующие возможности языка

Разработка программного обеспечения для встроенных систем сопряжена с рядом специфических сложностей. Приходится иметь дело с физическими устройствами, наборами нестандартных приемов и очень жесткими ограничениями на скорость отклика, оперативную память, размер программы и время обработки. Можно воспользоваться такими достоинствами разработки на Java, как объектно-ориентированная структура, встроенная поддержка Internet и популярность среди разработчиков.

В частности, для удовлетворения строгим требованиям, предъявляемым встраиваемыми устройствами к объему оперативной памяти, выбрано специальное подмножество Java API — Java 2 Micro Edition (J2ME). В клиентскую часть включаются только самые необходимые функции. J2ME использует «профили», относящие различные устройства к одной из двух категорий: с памятью от 128 до 512 Кбайт и с памятью свыше 512 Кбайт. Возможность доступа к различным пользовательским интерфейсам и другим программным функциям определяется по профилю устройства.

Парадоксально, но некоторые возможности Java, открывшие языку путь в Internet и в мир настольных компьютеров, превращаются в источник проблем, когда дело касается встроенных систем. Механизм защиты, включенный в состав виртуальной Java-машины, так называемая «песочница» (sandbox), и отсутствие указателей затрудняют применение Java для непосредственного управления оборудованием. Автоматическая чистка памяти («сборка мусора») упрощает программирование, но делает невозможным детерминизм, ожидаемый от систем, которые предназначены для работы в масштабе реального времени. Кроме того, Java обладает невысокой скоростью и требует значительного количества оперативной памяти. К счастью, большинство из этих проблем преодолимы, уже имеются жизнеспособные решения. Итак, на вопрос «Подходит ли Java для программирования встроенных устройств?» можно ответить: «Иногда».

В каком случае выбор Java оправдан?

Java не вполне может подойти для использования в модуле обработки прерываний, управляющем космическим кораблем, который направляется на Марс. Если необходимо разработать компактное, эффективное, надежное приложение с детерминированным по времени поведением для решения критически важных задач, например для управления реактивными двигателями, связи с датчиками и получения данных о пространственном положении космического корабля, лучше воспользоваться Cи или Ассемблером.

Для других приложений, например для программы учета отгрузки товара на карманном компьютере, Java подходит идеально. Устройствам, для которых необходимо «общение» друг с другом или наличие соединения с Internet, могут пригодиться соответствующие возможности языка. Приложения, работающие с серверными Java-приложениями, опираются на уже существующую архитектуру и программы для этой среды.

Фактор времени

Одной из причин популярности Java явилось отсутствие привязки к определенной платформе. Программа на Java может выполняться на компьютерах Macintosh, на ПК, на машинах под управлением операционной системы Solaris или даже на мэйнфрейме, так как принадлежит к категории интерпретаторов. От платформы зависит только виртуальная Java-машина, интерпретирующая команды языка для каждой ОС. Эта процедура занимает не так уж и много времени; заслугой тому компиляторы типа just-in-time (JIT). Однако кто из абонентов мобильных телефонов намерен ждать по нескольку секунд, пока Java распределит память и загрузит необходимые классы? Компиляторы типа ahead-of-time (AOT) интерпретируют коды Java заранее, преобразуя их в оптимизированный, привязанный к платформе двоичный код.

Компания Cygnus Solutions предлагает AOT-компилятор, ускоряющий выполнение команд примерно в восемь раз. NewMonics разработала компилятор QuickPERC, который, по данным самой фирмы, увеличивает скорость выполнения приложений не менее чем в 20 раз по сравнению с обычным режимом интерпретатора.

Надо сказать, что при использовании технологии ahead-of-time разработчики теряют возможность поддержки единой версии компилируемого кода на центральном сервере с последующей его передачей на разные клиентские платформы. Но это не будет большой потерей в среде, традиционно использующей более статичную базу оттранслированных кодов, которая характерна для встраиваемых систем.

Размер имеет значение

В то время как для сервера наличие нескольких гигабайтов оперативной памяти уже не считается чем-то необычным, в специализированном устройстве ее может быть менее 512 Кбайт. Поэтому на встраиваемой системе не получится загрузить ядро Java c библиотекой классов, требующей мегабайты еще до написания какого-либо кода. Удаление всех неиспользуемых кодов, методов и классов в сочетании с компиляторами AOT несколько улучшает положение. Кроме того, многие поставщики уже написали для некоторых платформ собственные классы ядра Java, более компактные и эффективные, отвечающие опубликованному стандарту Java API. Естественно, объектно-ориентированные языки требуют больше памяти, чем язык Ассемблера или Cи. Это обстоятельство давно перестало быть критичным фактором для настольных ПК, но остается важным для встроенных систем.

Курс на интегрированные среды

Более 80% ошибок в программах на Cи считаются следствием проблем с указателями, в то время как Java помогает их избежать. Модель безопасности Java предотвращает использование указателей для прямого обращения к системной памяти и физическому оборудованию. Но такие указатели бывают очень кстати, когда необходимо быстро и напрямую обращаться к памяти.

Встраиваемые системы с программным обеспечением на Java должны использовать вызовы программ Cи — для выполнения аппаратно-зависимых функций. Однако это означает работу с кодами на нескольких языках, что в свою очередь приводит к необходимости дополнительного обучения разработчиков либо к привлечению дополнительных программистов. Кроме того, возникает вопрос, каким образом связать все эти коды в один модуль и отладить его при возникновении проблем?

Мощная, насыщенная возможностями, многоязычная интегрированная среда разработки, поддерживающая код, предназначенный для нескольких платформ, — шаг в правильном направлении. Подобные предложения уже существуют: Metrowerks CodeWarrior, позволяющая программировать на нескольких языках в единой интегрированной среде, а также IBM VisualAge for J2ME.

Время освободиться от мусора

Один из доводов в пользу отказа от Java во встроенных системах — неспособность языка гарантировать требуемый детерминизм. Это означает, что язык не в состоянии обрабатывать определенный участок кода за предсказуемый и повторяемый промежуток времени. В Java существует процедура «сборки мусора», автоматически освобождающая неиспользуемую память, и программист не может ее контролировать. При выполнении этой процедуры работа всего приложения практически останавливается. Пытаясь устранить проблему, разработчики представили альтернативные методы и алгоритмы очистки памяти. Такие решения, как Real Time Executive компании NewMonic и FastJ компании Windriver, могут обеспечивать абсолютный временной детерминизм. Подход Sun Microsystems несколько иной, но тоже призван гарантировать детерминизм реального времени. Различные методы программирования, например повторное использование объектов, также смягчают негативное влияние «сборки мусора».

Возможность повторного использования

Хотя компиляторы AOT лишают разработчиков возможности выполнения единого откомпилированного кода Java на любой платформе, компактность исходного кода Java по-прежнему является огромным плюсом.

Деньги и смысл

Иногда решение использовать Java приводит к необходимости просчитать отношение затрат и преимуществ. Известно, что модули памяти и быстрые процессоры недороги и продолжают дешеветь. Если имеет смысл потратить несколько сотен или даже тысяч долларов на дополнительную память для сервера, подобная логика может не сработать в случае сотового телефона. Если вы можете сэкономить 1 долл., устанавливая меньшее количество памяти на 20 млн. сотовых телефонов, общая экономия составит 20 млн. долл.

Роль Java в конкретном проекте

«Если вы рассчитываете использовать Java при разработке встроенной системы, то технология не имеет значения по сравнению с организационно-культурными факторами, — заявил Грег Викхем, автор книги Embedded Systems? Compiled Java Experiences («Опыт компиляции Java во встроенных системах»). — Если все ваши программисты используют Java для Web-дизайна и привыкли жертвовать машинными ресурсами ради личных удобств, вы не можете в одночасье превратить их в программистов встраиваемых систем. Советуем поступить по-другому: не начинайте сразу с создания приложений целиком на Java. Через некоторое время программисты на Java привыкнут общаться с профессионалами в области встроенных систем, и обмен опытом между ними приведет к нужному результату».

Чем дальше отойти от стандартной среды, в которой команды J2ME выполняются на виртуальной Java-машине, тем сложнее управление приложением. На практике рекомендуется по мере возможности максимально придерживаться стандарта J2ME. К иным решениям целесообразно прибегать только при особых затруднениях.

И не нужно удивляться, если некоторые решения для встроенных систем, такие как AOT-компиляторы и полуавтоматическая очистка памяти, окажутся востребованы на настольных компьютерах и серверах, делая язык Java даже более привлекательным.

Java для встроенных систем