The hunt for the J2ME-friendly IoC container is on!

Question

I'm in the beginning phases of a Blackberry/J2ME project -- and along with other limitations that come with this wonderful platform, the lack of support for reflection and 1.3 language level mean that the vast majority of existing IoC containers are unusable. (Google has Guice for Android with no AOP, but even that requires support for annotations).

So the space of IoC containers on J2ME is pretty limited. The one framework that has caught my attention is called Signal Framework, and it looks pretty promising. It tries to stay conceptually close to Spring Framework's IoC, implementing a small subset of its functionality, and does so without relying on bytecode-modification or causing runtime xml parsing. Instead, it processes configuration XMLs at build-time to generate java code which implements this IoC functionality.

Generally speaking, code generation at build time seems like a very wise approach for mobile applications -- and if my app has to do less XML parsing on user's device, that's great too!

So, what have your experiences been with implementing IoC on J2ME/CLDC, and how were you able to extinguish that bitter taste in your mouth?

Answer 1

We used Spring ME at TomTom. It worked out pretty well.

Answer 2

In J2ME you need to reduce the number of classes you use as much as possible to reduce the size of jar files. This leads to many design compromises not least of which is flexibility.

It is not easy to adjust to J2ME development when you have to throw must of what you hae learnt (and come to value highly) about OO out the window. The truth is if you want apps that can run on a large range of phones you need to be very sensitive to the constraints of the devices.

As such I do not think an IoC framework will match many people's needs for J2ME development.