How to deal with the most common classes missing on J2ME

Question

I'm trying to code an application which runs un different java platforms like J2SE, J2ME, Android, etc. I already know that I'll have to rewrite most of the UI for each platform, but want to reuse the core logic.

Keeping this core portable involves three drawbacks that I know of:

1. Keeping to the old Java 1.4 syntax, not using any of the nice language features of Java 5.0
2. only using external libraries that are known to work on those platforms (that is: don't use JNI and don't have dependencies to other libs which violate this rules)
3. only using the classes which are present on all those platforms

I know of ways to overcome (1): code in 5.0 style and automatically convert it to 1.4 (retroweaver - haven't tried it yet, but seems ok).

I think (2) is a problem that I just have to accept.

Now I'd like to know what's the best workarround for (3), especially collection classes, which I miss the most. I can think of those:

• Most programmers I know just don't use Set, Map, List, etc. and fallback to Vector and plain Arrays. I think this makes code ugly in the first place. But I also know that the right choice between TreeSet/Hashset or LinkedList/ArrayList is crucial for performance, and always using Vector and Arrays can't be right.
• I could code my own implementations of that classes. This seems to be reinventing the wheel, and I think I could not do it as good as others have done.
• Since Java is open source, I could grab the sourcecode of the J2SE Collections framework and include into my application when building for J2ME. I don't know if this is a good idea, though. Pherhaps there are good reasons not to do this.
• Maybe there already are libraries out there, which rebuild the most important features of the collections framework, but are optimized for low end systems, pherhaps by not implementing functionality that is used infrequently. Do you know any?

Thanks for your answers and opinions!

Edit: I finally found a (complex, but nice) solution, and I thought by providing my own answer and accepting it, the solution would become visible at the top. But to the contrary, my answer is still at the very bottom.

Stealage

Answer 1

It's been a while since I asked this question, and I while since I found a nice, working solution for the problem, but I had since forgotton to tell you.

My main focus was the Java Collections Framework, which is part of the java.util package.

I've finally taken the source code of Suns Java 6.0 and copied all the classes that belong to the Collections framework into a project of my own. This was a Java 6.0 project, but I used the jars from J2ME as classpath. Most of those classes that I copied depend on other J2SE classes, so there are broken dependencies. Anyway, it was quite easy to cut those depensencies by leaving out everything that deals with serialization (which is not a priority for me) and some minor adjustments.

I compiled the whole thing with a Java 6 compiler, and retrotranslator was used to port the resulting bytecode back to Java 1.2.

Next problem is the package name, because you can't deliver classes from java.util with a J2ME application and load them - the bootstrap class loader won't look into the applications jar file, the other bootloaders aren't allowed to load something with that package name, and on J2ME you can't define custom classloaders. Retrotranslator not only converts bytecode, it also helps to change name references in existing bytecode. I had to move and rename all classes in my project, e.g. java.util.TreeMap became my.company.backport.java.util.TreeMap_.

I was than able to write actual J2ME application in a second Java 6.0 project which referenced the usual java.util.TreeMap, using the generic syntax to create type-safe collections, compile that app to Java 6.0 byte code, and run it through retrotranslator to create Java 1.2 code that now references my.company.backport.java.util.TreeMap_. Note that TreeMap is just an example, it actually works for the whole collections framework and even for 3rd party J2SE Jars that reference that framework.

The resulting app can be packaged as a jar and jad file, and runs fine on both J2ME emulators and actual devices (tested on a Sony Ericsson W880i).

The whole process seems rather complex, but since I used Ant for build automation, and I needed retranslator anyway, there only was a one-time overhead to setup the collection framework backport.

As stated above, I've done this nearly a year ago, and writing this mostly from the top of my head, so I hope there are no errors in it. If you are interested in more details, leave me a comment. I've got a few pages of German documentation about that process, which I could provide if there is any demand.

Stealage

Would you be willing to provide your backport of the collections framework? Retrotranslator is great, but I had to write my own backports just to get autoboxing working. – Eaglet

Any chance you could share this backport? – Quoits

Answer 2

J2ME is brutal, and you're just going to have to resign yourself to doing without some of the niceties of other platforms. Get used to Hashtable and Vector, and writing your own wrappers on top of those. Also, don't make the mistake of assuming that J2ME is standard either, as each manufacturer's JVM can do things in profoundly different ways. I wouldn't worry much about performance initially, as just getting correctness on J2ME is enough of a challenge. It is possible to write an app that runs across J2ME, J2SE and Android, as I've done it, but it takes a lot of work. One suggestion that I'd have is that you write the core of your application logic and keep it strictly to java.lang, java.util and java.io. Anywhere where you're going to be doing something that might interact with the platform, such as the file system or network, you can create an interface that your core application code interacts with, that you have different implementations for the different environments. For example, you can have an interface that wraps up HTTP stuff, and uses javax.microedition.io.HttpConnection with J2ME and java.net.HttpURLConnection on Android. It's a pain, but if you want to maintain an app running on all three of those environments, it can get you there. Good luck.

Northnortheast

Answer 3

We faced exactly this situation in developing zxing. If J2ME is in your list of targets, this is your limiting factor by far. We targeted MIDP 2.0 / CLDC 1.1. If you have a similar requirement, you need to stick to Java 1.2. Java 1.4 language features are definitely not present (like assert) and in general you won't find anything after 1.2 in J2ME.

We did not use external libraries, but, you could package them into your deployed .jar file with little trouble. It would make the resulting .jar bigger, and that could be an issue. (Then you can try optimizers/shrinkers like ProGuard to mitigate that.)

I did end up reimplementing something like Collections.sort() and Comparator since we needed them and they are not in J2ME. So yeah you might consider doing this in cases, though only where necessary.

We used Vector and Hashtable and arrays since there is no other choice, really, in J2ME. I would just use them unless you have a reason not to, and that would be performance I guess. In theory JVM makers are already optimizing their implementation but that doesn't mean you couldn't make a better one... I guess I would be surprised if it is worth it in the vast majority of cases. Just make sure you really need to do this before putting in the effort.

Leprosarium

Correction about Java ME: CLDC uses 1.3 version code, CDC uses 1.4. I can't remember right now what changes were between 1.2 and 1.3 but CLDC uses 1.3. – Middleton

There weren't language changes from 1.2 to 1.3, just API and JVM changes. Of course CLDC has a totally different API subset and JVMs. So I guess either is about right but I imagine your statement is right-er given the dates involved. – Leprosarium

Wow, didn't think such an old comment could get answered. My remark is actually supported by the CLDC specification, which states that "CLDC supports a number of classes that have been derived from Java Standard Edition, version 1.3.1". I agree though that the language didn't change between the 1.2 and 1.3 versions of Java (the second JLS applies to both), and since CLDC is a very limited subset, there's no terrible difference. – Middleton

Answer 4

To answer part of your question another collections library would be Javolution which can be built for j2me.

Christine

Hi, thanks, that looks interesting. Do you know if I have to use the whole Javolution stuff (which is certainly nice, but might come along with other problems/drawbacks) of if I could use the collection from Javolution on their own? – Stealage

I'm not sure, I've never used it like that so I couldn't tell you. – Christine

I've also wondered about this, but from my experience in trying to isolate just a few collections classes, there appear to be a lot of interdependencies within the library itself. – Umiak