«Локализация, адаптация к запуску и портирование мидлетов для платформы j2me»
Прежде всего, определимся с терминами. Программисты и пользователи мобильных телефонов сталкиваются с тремя разными задачами-проблемами:

-Локализация
-Адаптация к запуску
-Портирование
Попробую коротко описать различие между этими задачами.

Локализация
Как правило, все программы и игры, с которыми приходится иметь дело, написаны на неродном для пользователя России языке Локализация как раз и занимается этим вопросом - перевод интерфейса и файла помощи. Вариантов, с которыми может столкнуться локализатор множество:

1.Тексты жестко зашиты в классы - программу нужно декомпилировать, тексты перевести, скомпилировать заново (тяжелый случай)
2.Программа запрашивает у телефона локаль и в зависимости от ответа читает нужный файл с текстами - создается нужный файл с текстами и просто добавляется в jar (самый простой и правильный случай)
3.Программа хранит все тексты в ресурсном файле.
Ресурсный файл читается как файл UTF8 - просто заменяем тексты на русские.
Ресурсный файл читается как битовый массив - надо пробовать записать русский текст как UTF8 или как Java Unicode, в самом плохом случае придется декомпилировать и вносить изменения в классы для того, чтобы чтение осощуствлялось как UTF8.
Необходимый инструментарий: голова (мозг), hex редактор (например WinHex или Hiew), перекодировщик (native2ascii.exe из jsdk 40Мб или моя утилита для переводчиков (http://iceman.ru/down/ascii2utf.rar 400Кб), архиватор (WinRar или WinZip) - jar является обычным zip архивом.

Примеры: игра Mafia Wars - запрашивает локаль, все тексты, кроме анонса о разработчике, хранятся в 2 файлах en и en.hlp Для локализации требуется создать два файла ru и ru.hlp. Открываем файл en в ascii2utf как "read bin file", указываем пропустить 1 байт. После перевода записываем файл ru.dat "save bin file" (потом переименуйте его в ru, без расширения), отступив 1 байт от начала. Если посмотреть оригинальный файл, то увидим , что в 1 байте стоит $52 - это 82 в десятичной системе, это же число показывает программа: Nodes:$0052. Из этого мы делаем вывод, что первый байт хранит общее число строк. При помощи WinHex записываем в первый байт созданного ru файла $52.

Примечания: локализация не такое уж и простое дело - вероятней всего придется догадываться и разбираться со структурой текстовых файлов - у каждого программиста свои предпочтения, как читать и хранить тексты в игре. Просто учтите, что строки - первые 2 байта размер строки, потом тело строки, завершает строку $00. В заголовке файла могут быть адреса начала строк или просто служебная информация - моя утилита поможет пересчитать адреса начала и длины, после преобразования в UTF.

Адаптация к запуску
В основе j2me лежит несколько стандартов: CLDC (1.0 или 1.1) и MIDP (1.0 или 2.0). Стандарты эти обратно совместимы, т.е. если устройство поддерживает MIDP 2.0, оно будет корректно (должно, но не обязано ) работать с MIDP 1.0. Производители мобильных устройств выпустили расширения для стандартов MIDP-1, в которых содержатся специфические для данного устройства возможности или оптимизированные способы работы с графикой. Например, это могут быть классы для работы со звуком, виброй, подсветкой, динамическим светом или файловой системой. Надо заметить, что с поддержкой стандарта MIDP-2 производители, например Siemens, пометили такие специфические классы как "нерекомендуемые", так что это должно положительно сказаться на совместимости.

Адаптация к запуску, по сути, ряд операций, которые позволяют запустить платформо-зависимый мидлет на другом устройстве. Характерная ошибка, которая возникает при попытке запуска платформо-зависимого мидлета: "Midlet initialization failed: java.lang.NoClassDefFoundError: com/samsung/util/AudioClip". В данном случае, как видно из сообщения об ошибке, мы имеем дело с мидлетом, который был написан для платформы Samsung. Что можно предпринять в таком случае? Можно воспользоваться тем, что Виртуальная Ява машина при поиске классов использует относительный путь, принимая за точку отсчета сам мидлет - ведь API так же находится в jar архиве! Т.е. проще говоря мы попробуем добавить недостающие классы в подопытный мидлет. Мидлет, естественно, продолжит вызывать специфические классы, но они будут изолироваться. После такой процедуры, как правило, программы запускаются и работают на другой платформе, но с определенными ограничениями или глюками: управление может оказаться частично не доступным (управляющие коды джойстика и софт-клавиш различаются), не будет звука, вибры, подсветки (если они реализованы через специфические апи), ошибки отрисовки графики из-за разницы в реализации графических функций. И самое важное: если размеры экранов не совпадают, то таким образом вы НИКАК не добьетесь перемасштабирования (это должны были сделать авторы мидлета)! Т.е. этот способ подходит для случая когда:

- надо посмотреть что это за мидлет
- экран вашего устройства совпадает или очень близок по размерам к экрану исходной платформы + вы готовы примириться с возможными проблемами в управлении (охота пуще неволи!)
Инструментарий: голова (мозг), архиватор (WinRar или WinZip) - jar является обычным zip архивом, наборы классов для специфической платформы: Nokia, Samsung, Siemens…

Порядок работы: распаковываем подопытный мидлет (jar) во временную папку с сохранением структуры архива, копируем содержимое архива нужного набора классов в эту же папку (появляется папка com, в которой лежат специфические классы), упаковываем СОДЕРЖИМОЕ временной папки в zip архив и переименовываем его в jar. Далее требуется изменить в jad размер полученного jar файла или сгенерировать новый jad, воспользовавшись любым генератором (например jadgen ).

Примечание: таким способом НЕВОЗМОЖНО что-либо изменить в игре (ни управление, ни размер экрана)! Всем этим занимаются при портировании. Мидлет может не запуститься, может зависать и т.п. гарантировать его правильную работу не возможно - зато адаптацию к запуску может произвести человек абсолютно не разбирающийся в программировании (не уверен, что это достоинство этого метода).

Портирование
Собственно это самый трудоемкий и интеллектуально сложный процесс из всех, что здесь описываются. Под портированием мы будем понимать видоизменение мидлета таким образом, чтобы он функционировал на устройстве используя либо общие классы, либо специфические классы данного устройства. Это может потребовать преобразования звуков и графики в другой формат, перерисовку спрайтов или игровых экранов под новое разрешение экрана, видоизменение внутренних алгоритмов мидлета и т.п. Это требует знания языка программирования j2me и по трудоемкости может сравняться с написанием игры заново!

Необходимый инструментарий: декомпилятор java классов (open source DJ Java Decompiler 3.7 или коммерческий NMI Java Code Viewer); JSDK + WTK 2 (Borland JBuilder или Sun Mobile Studio или Eclipce); эмуляторы нужных устройств (содержат так же специфические апи этих устройств); архиватор (WinRar или WinZip).

Порядок работы (в общих чертах):

1 этап. Распаковываем мидлет в рабочую папку; преобразуем декомпилятором все файлы *.class в файлы *.java; создаем новый проект в среде разработки используя полученные файлы *.java (например в JBuilder).
2 этап. Т.к. все программы проходят обработку обфурскатором (это программа, которая затрудняет декомпиляцию делая текст трудно читаемым, убирает комментарии, изменяет имена функций и переменных и т.п.), то требуется устранить множество конфликтов имен, убрать "левые" вызовы, которые вставит декомпилятор и т.п. Главная задача на данном этапе - заставить мидлет скопилироваться и запуститься в эмуляторе. Когда это произойдет - знайте, что половина пути пройдена!
3 этап. Изучаем алгоритмы работы. Управление находится в обработчике событий keyPressed - это отправной пункт для портирования управления. Графика будет так или иначе связана с классом типа Canvas.
4 этап. Изменяем графику, звуки (если требуется). Создаем новый мидлет. Ура, мы сделали это!
Как вы понимаете, я не написал ничего конкретного "как именно" изменить управление, увеличить/уменьшить экран и т.п. Каждая программа индивидуальна, и как она конкретно написана зависит только от ее создателя. Портирование очень трудоемкий процесс, который требует опыта программирования доли удачи и исследовательской жилки.

Мобильное 3D и адаптация к запуску
Значится чтобы развеять еще один миф - "чего-то насыпать, размешать и будет суп", порассуждаем на тему мобильного 3D.

Зададим себе вопрос - что происходит, когда мы "добавляем в мидлет классы с других телефонов"? Что, неужели появляется поддержка mmf, mp3, подсветки, вибры? Ответ отрицательный. Возникают ли глюки с корректным отображением графики? Ответ положительный.

Так что же мы тогда делаем и почему это работает? Все очень просто: Виртуальная Ява Машина (далее ВМ) есть промежуточное звено между мидлетом и ОС самого телефона. Мидлет работает в своеобразной песочнице, где его изолируют от всех возможностей телефона предоставляя только гарантированный набор, который регламентирован в MIDP и CLDC. Учтем, что этот набор жестко описан и мидлет, написанный только по этим стандартам будет одинаково работать на разных платформах, правда UI (пользовательский интерфейс) может отличаться.

С целью облегчения жизни программистам, увеличения производительности (ведь всегда есть некие особенности реализации ВМ) производители выпустили расширения для стандартов. Например, доступ к файловой системе - по стандартам MIDP 1 и CLDC 1.0 это не возможно.

Итак, допустим, в игре мы используем звуки в mmf. Для этого мы загружаем специальный Нокиевский объект sound, который входит в Нокиевское расширение MIDP 1.0

Запустим такой мидлет на Сименс: при запросе инициализации sound, ВМ начнет искать класс, который отвечает за это и, естественно, не найдет его. ВМ сгенерирует исключительную ситуацию и выдаст сообщение об ошибке. Добавим этот класс в мидлет, теперь ВМ находит объект, инициализирует его, но, фактически, работает с пустышкой, потому что на уровне самой ВМ поддержка этого формата у нас не реализована. Т.е. нами была создана своеобразная "заглушка", с которой большинство мидлетов могут нормально функционировать.

Какие варианты возможны?

Расширения просто дополняют стандартные классы, вводя новую функциональность - тогда добавив их в мидлет мы полностью восстановим работу (например расширение для канвы, чтобы воспринимать коды от разных джойстиков)
Расширения дают доступ к специфическим возможностям телефона - объекты изолируются на уровне ВМ, т.к. в ней нет для них обработчиков (или ВМ "падает", так например если включить вызов вибры, то стандартный эмулятор из WTK2 падает)
Все это справедливо и для технологии 3D. Функциональность 3D движка описывается, естественно, не в файлах class - они не более чем "обертка", описание интерфейсов создания, инициализации и уничтожения (как например paint() у объекта canvas - это событие связано с экраном и ответственность за него лежит на ВМ). Добавив оберток, мы "конфетку" не получим Единственный путь - писать "враппер", который будет реализовывать функциональность движка средствами другого движка (помните OpenGL через DirectX?? вот тут полная аналогия).

Только для j2me такой враппер НИКОМУ не нужен! Представьте, к примеру, что в CLDC 1.0 нет даже чисел с плавающей запятой: реализация 3D движка силами j2me + другой 3D движок = страшный неповоротливый геморрой.

Источник : http://iceman345.narod.ru/j2me0.htm