В общем и целом принцип работы Java на конкретном устройстве таков: в программное обеспечение телефона разработчик встраивает виртуальную Java-машину, с помощью которой выполняются, а затем выводятся на дисплей загруженные мидлеты. Вроде бы все просто? Отнюдь. На практике картина выглядит далеко не так радужно: если некая виртуальная машина абстрактного устройства с большой долей вероятности может обеспечить выполнение кода, то с выводом информации на дисплей и управлением программой могут возникнуть (и зачастую возникают) проблемы - вновь встает вопрос о совместимости: хорошо, если конкретный мидлет разработала крупная компания, которая в состоянии протестировать его на совместимость с большинством актуальных моделей мобильных телефонов или же выпустить его версии для аппаратов различных брэндов (с различными схемами софтклавиш, разными разрешениями и ориентациями дисплеев), учтя при этом особенности реализации их Java-машин. Однако массу интересных Java-приложений пишут программисты-одиночки, которые разрабатывают их "с прицелом" на свой собственный аппарат или же линейку "соплатформников" одного производителя. И дать гарантию, что такой мидлет будет корректно работать на телефоне другой модели, не может никто.
Более того, основная проблема заключается в так называемых наборах 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.