Как справиться с наиболее распространенными классами, отсутствующими в J2ME

J2ME жесток, и вам просто придется смириться с тем, чтобы обходиться без некоторых тонкостей других платформ. Привыкайте к Hashtable и Vector, а также напишите свои собственные оболочки поверх них. Кроме того, не делайте ошибки, предполагая, что J2ME является стандартным, поскольку JVM каждого производителя может делать вещи совершенно разными способами. Поначалу я бы не стал сильно беспокоиться о производительности, так как просто получить корректность на J2ME - достаточно сложно. Можно написать приложение, работающее на J2ME, J2SE и Android, как я это сделал, но это требует большой работы. Одно из моих предложений - написать ядро ​​логики приложения и строго придерживаться java.lang, java.util и java.io. Везде, где вы собираетесь делать что-то, что может взаимодействовать с платформой, например файловая система или сеть, вы можете создать интерфейс, с которым взаимодействует ваш основной код приложения, и у вас есть разные реализации для разных сред. Например, у вас может быть интерфейс, который обертывает HTTP-файлы и использует javax.microedition.io.HttpConnection с J2ME и java.net.HttpURLConnection на Android. Это больно, но если вы хотите, чтобы приложение работало во всех трех средах, это поможет вам. Удачи.

Прошло некоторое время с тех пор, как я задавал этот вопрос, и я с тех пор нашел хорошее, рабочее решение проблемы, но с тех пор я забыл вам сказать.

Мое основное внимание уделялось Java Collections Framework, который является частью пакета java.util.

Я наконец взял исходный код Suns Java 6.0 и скопировал все классы, принадлежащие фреймворку Collections, в свой собственный проект. Это был проект Java 6.0, но я использовал jar-файлы из J2ME в качестве пути к классам. Большинство из этих классов, которые я скопировал, зависят от других классов J2SE, поэтому зависимости нарушены. В любом случае, было довольно легко избавиться от этих зависимостей, исключив все, что связано с сериализацией (что для меня не является приоритетом) и некоторые незначительные корректировки.

Я скомпилировал все это с помощью компилятора Java 6, и ретротранслятор использовался для переноса полученного байт-кода обратно в Java 1.2.

Следующая проблема - это имя пакета, потому что вы не можете доставить классы из java.util с помощью приложения J2ME и загрузить их - загрузчик классов начальной загрузки не будет смотреть в файл jar приложения, другим загрузчикам не разрешено загружать что-либо с этим имя пакета, а в J2ME вы не можете определять собственные загрузчики классов. Ретротранслятор не только конвертирует байт-код, но также помогает изменять ссылки на имена в существующем байт-коде. Мне пришлось переместить и переименовать все классы в моем проекте, например. java.util.TreeMap стал my.company.backport.java.util.TreeMap_.

Затем я смог написать реальное приложение J2ME во втором проекте Java 6.0, который ссылался на обычный java.util.TreeMap, используя общий синтаксис для создания типобезопасных коллекций, скомпилировать это приложение в байтовый код Java 6.0 и запустить его через ретротранслятор для создания Java 1.2. код, который теперь ссылается на my.company.backport.java.util.TreeMap_. Обратите внимание, что TreeMap - это просто пример, он фактически работает для всей структуры коллекций и даже для сторонних J2SE Jar, которые ссылаются на эту структуру.

Полученное приложение может быть упаковано в файлы jar и jad и отлично работает как на эмуляторах J2ME, так и на реальных устройствах (проверено на Sony Ericsson W880i).

Весь процесс кажется довольно сложным, но поскольку я использовал Ant для автоматизации сборки, а ретранслятор мне все равно понадобился, на настройку бэкпорта фреймворка коллекции были только одноразовые накладные расходы.

Как указано выше, я сделал это почти год назад и писал это в основном с головы до ног, поэтому я надеюсь, что в нем нет ошибок. Если вас интересуют подробности, оставьте мне комментарий. У меня есть несколько страниц документации по этому процессу на немецком языке, которые я могу предоставить, если будет необходимость.

Мы столкнулись именно с этой ситуацией при разработке zxing. Если J2ME находится в вашем списке целей, это, безусловно, ваш ограничивающий фактор. Мы нацелены на MIDP 2.0 / CLDC 1.1. Если у вас есть подобное требование, вам нужно придерживаться Java 1.2. Возможности языка Java 1.4 определенно отсутствуют (например, assert), и в целом вы не найдете ничего после 1.2 в J2ME.

Мы не использовали внешние библиотеки, но вы могли легко упаковать их в развернутый файл .jar. Это сделало бы получившийся .jar больше, и это могло быть проблемой. (Затем вы можете попробовать оптимизаторы / программы сжатия, такие как ProGuard, чтобы смягчить это.)

В итоге я переопределил что-то вроде Collections.sort () и Comparator, поскольку они нам были нужны, а их нет в J2ME. Так что да, вы можете подумать о том, чтобы сделать это в некоторых случаях, но только там, где это необходимо.

Мы использовали Vector, Hashtable и массивы, так как в J2ME другого выбора, на самом деле, нет. Я бы просто использовал их, если у вас нет причин не делать этого, и я думаю, это будет производительность. Теоретически производители JVM уже оптимизируют свою реализацию, но это не значит, что вы не можете сделать что-то лучше ... Думаю, я был бы удивлен, если это того стоит в подавляющем большинстве случаев. Просто убедитесь, что вам действительно нужно это сделать, прежде чем прилагать усилия.

Чтобы ответить на часть вашего вопроса, другой библиотекой коллекций может быть Javolution, которая может быть создана для j2me.