Журнал `Компьютерра` №724

Более того, основная проблема заключается в так называемых наборах API (Appli cation Programming Interface - программный интерфейс приложения), отвечающих за доступ к каким-либо программным или аппаратным функциям устройства непосредственно из Java-приложения, исполняемого виртуальной Java-машиной. Приведем пример из жизни: есть такой мидлет - BT Info, предназначающийся для Blue-Jack’инга. На Sony Ericsson W880i он получает доступ к Bluetooth-модулю, отыскивает устройства и обменивается с ними информацией, а вот MOTOROKR Z6 при попытке запуска мидлета выводит на дисплей сообщение об отсутствии поддержки JSR-82.

Что это значит? Виртуальная Java-машина, которой оснащена Z6, не имеет доступа к Bluetooth API устройства, то есть соответствующие Java-приложения функционировать не будут. Аббревиатура JSR расшифровывается как Java Specification Request - фактически это модули/конфигурации/профили/спецификации, реализуемые на основе дополнительных библиотек (классов) и призванные улучшить функциональность платформы в целом. Одни из них являются специфическими, другие применяются почти повсеместно и уже стали ее "костяком", благо отсутствие некоторых интересных API было обнаружено производителями устройств и ОПСОСами (желающими использовать новую платформу для внедрения своих дополнительных услуг) еще в первые годы существования Java 2ME. Полный же список модулей, которые реально поддерживаются представленными на рынке аппаратами, можно отыскать на www.jcp.org/en/jsr/all.

"Почему мобильные телефоны не оснащаются одинаковым набором API? Ведь так было бы проще и разработчикам ПО, и пользователям…" - примерно такой вопрос был недавно задан на одном из интернет-форумов, посвященных мобильным технологиям. Попробуем ответить. Дело в том, что сама архитектура Java 2ME не может обеспечить полной стандартизации.

Допустим, есть набор основных библиотек, конфигураций и профилей, поддержка которых присутствует в Java-машинах устройств в обязательном порядке, а есть и дополнительные (а порой и "экзотические") элементы, добавляемые разработчиками "по желанию" или по необходимости. А поскольку аппаратные/программные характеристики устройств отличаются, разработчики встраивают ровно те возможности, которые, по их мнению, будут востребованы пользователями и в то же время поддерживаются на уровне железа. Зачем, например, бюджетному телефону поддержка JSR-184 (Mobile 3D Graphics API), если его процессор все равно не справится с обработкой трехмерной графики? Посему такая возможность в Java-машину и не закладывается. Свою роль здесь играет и маркетинг: почему бы дополнительно не разделить устройства на классы по их Java-функциональности? Возьмем те же игры: если пользователя устроят простенькие 2D-игрушки, пусть покупает аппарат за сот ню долларов, а если ему хочется насладиться 3D-графикой - пусть поднакопит денег и возьмет аппарат подороже.

Впрочем, все относительно, и многое зависит еще и от амбиций производителя. Скажем, LG не считает нужным добавлять поддержку 3D-графики даже в свои топовые продукты, а бюджетные телефоны Sony Ericsson ценят в том числе и за хорошую производительность в 3D-Java.

В основе платформы Java 2ME лежат две основные конфигурации: CDC (Connected De vice Configuration, JSR-36 для версии 1.0 и JSR-218 для версии 1.1) и CLDC (Connected Limited Device Configuration, JSR-30 для версии 1.0 и JSR-139 для версии 1.1).

Разница между CDC 1.0 и 1.1, а также между CLDC 1.0 и 1.1 заключается в возросшем количестве возможностей и, следовательно, в новых требованиях к аппаратной составляющей устройств; причем новые версии не переписаны с нуля, а представляют собой эволюцию (обновление) старых версий. Конфигурация CDC предназначена по большому счету для наиболее сложных мобильных устройств, вроде смартфонов, автомобильных навигационных систем и даже игровых приставок, а CLDC применяется в простых мобильниках. Очевидно, что эти конфигурации как раз и относятся к "костяку" платформы и поддерживаются большинством современных продуктов соответственно их классу и способу применения. Разница между CDC и CLDC заключаются в наличии или отсутствии некоторых библиотек, свойствах языка Java, возможностях виртуальных машин, а также аппаратных требованиях к устройствам. Но для непосредственного написания приложений, предназначенных для работы в устройстве, конфигураций мало, - вот мы и подобрались к вершине "Java-айсберга", которая называется MIDP (Mobile Information Device Profile, JSR-37 - версия 1.0, JRS-118 - 2.0).