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

Question

Я пытаюсь закодировать приложение, которое работает на разных платформах Java, таких как J2SE, J2ME, Android и т. Д. Я уже знаю, что мне придется переписывать большую часть пользовательского интерфейса для каждой платформы, но хочу повторно использовать ядро логика.

Хранение этого основного портативного устройства связано с тремя известными мне недостатками:

1. Сохранение старого синтаксиса Java 1.4 , без использования каких-либо приятных языковых функций Java 5.0
2. только с использованием внешних библиотек , которые, как известно, работают на этих платформах (то есть: не используйте JNI и не имеют зависимостей от других библиотек, нарушающих эти правила)
3. только с использованием классов , которые присутствуют на всех этих платформах

Я знаю способы преодоления (1) : код в стиле 5.0 и автоматическое преобразование его в 1.4 ( ретро-ткач - еще не пробовал, но, похоже, все в порядке).

Я думаю (2) - это проблема, которую я просто должен принять.

Теперь я хотел бы знать, какой лучший обходной путь для (3) , особенно коллекционные классы, по которым я скучаю больше всего. Я могу думать о тех:

• Большинство программистов, которых я знаю, просто не используют Set, Map, List и т. Д. И возвращаются к Vector и обычным массивам. Я думаю, что это делает код некрасивым в первую очередь. Но я также знаю, что правильный выбор между TreeSet/Hashset или LinkedList/ArrayList имеет решающее значение для производительности, и всегда использование Vector и массивы не могут быть правильными.
• Я мог бы написать свои собственные реализации этих классов. Кажется, это изобретает колесо, и я думаю, что не смог бы сделать это так же хорошо, как другие.
• Поскольку Java является открытым исходным кодом, я мог бы взять исходный код платформы J2SE Collections и включить в свое приложение при сборке для J2ME. Хотя я не знаю, хорошая ли это идея. Возможно, есть веские причины не делать этого.
• Возможно, уже есть библиотеки, которые восстанавливают наиболее важные функции каркаса коллекций, но оптимизированы для младших систем, возможно, из-за нереализованной функциональности, которая используется нечасто. Вы знаете кого-нибудь?

Спасибо за ваши ответы и мнения!

Редактировать: Я наконец нашел (сложное, но приятное) решение, и я подумал, что, предоставив свой собственный ответ и приняв его, решение станет видимым сверху. Но наоборот, мой ответ все еще в самом низу.

Answer 1

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. Это неприятно, но если вы хотите, чтобы приложение работало во всех этих трех средах, оно может помочь вам. Удачи.

Answer 2

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

Мое основное внимание было уделено 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 вы не можете определить собственные загрузчики классов. Retrotranslator не только преобразует байт-код, но также помогает изменять ссылки на имена в существующем байт-коде. Мне пришлось переместить и переименовать все классы в моем проекте, например, 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 для автоматизации сборки, и мне все равно требовался ретранслятор, потребовались только одноразовые накладные расходы для настройки обратного порта инфраструктуры сбора.

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

Answer 3

Мы столкнулись именно с такой ситуацией при разработке 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 уже оптимизируют свою реализацию, но это не значит, что вы не можете сделать лучшую реализацию ... Думаю, я был бы удивлен, стоит ли она того в подавляющем большинстве случаев. Просто убедитесь, что вам действительно нужно это сделать, прежде чем прилагать усилия.

Answer 4

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