The biggest problem is there are many JSR specifications, but only few open source implementations. Many others do not exist or are closed source (the Mobile 3D Graphics API JSR 184 comes to mind which is often used in high end games). For those for which we do have an implementation, there is usually only an implementation for Windows or Linux on x86 systems. The biggest amount of work is making this work on other mobile platforms. Based on my experience with WinCE/Windows Mobile, Android and now Maemo, I can say that the most difficult part is bridging the JSR APIs with the underlying platform libraries (for the N900/N9 this would be a.o. Qt4, liblocation, etc.) and making sure that:

1) it works reliably for not just one midlet but for all midlets (in the sense that midlets may have different ways to achieve certain things and you have to support them all) as I don't have access to the Java ME Technology Compatibility Kit to test for compliance.

2) you have a framework in place that allows you to bridge new JSR apis more easily with the platform APIs. This decreases the amount of work later on if you add support for new APIs, but requires more effort at the start the get the proper foundations and abstractions right. It also helps with portability to new platforms or new platform editions.

Now, for this you need to be somewhat familiar with JavaME specs and how to compile and integrate new (platform specific) stuff in phoneME so that all features are available from Java source code (i.e. the midlet code), while ensuring there is no (significant) performance bottleneck. I have learned this the hard way through trial and error during the several years I was doing the WinMo and Android ports. Mapping Java ME text rendering methods on those that Qt4 provides is a notable example. You need to figure out how to write text on a 16-bit RGB array while avoiding copying back and forth large RGB buffers between JavaME and Qt4 because it slows down the overall rendering process.

The best way for the community to help me out is to help with the testing. I now have a N900 which at least helps me to test for performance bottlenecks (thanks again donators). However, I only use a few (freely available) midlets. So if the community can help with testing other midlets as well, that would be nice. The biggest problem is usually that we do not have the source code of commercial midlets to figure out why they don't work. Sometimes they make use of an API that is currently not yet supported, sometimes it is a bug in my port.

I am also much interested in feedback from N9 owners, because there seems to be some subtle differences with this platform compared to the N900. Various libraries (e.g. those for GPS that I need for JSR 179/Location API) are either not available or do not work on the emulators. So I only have the N900 to test on and hope that they will also work on the N9.

Another way to help me integrate new features is to provide pointers to small working examples in C or C++. For example, to support JSR 179, I need to know how to access the GPS. I spent some time looking for simple minimalistic applications with source code that I can easily compile showing how get to the data. Such example applications make it a bit easier to figure out how to integrate this code in the JavaME vm. So just pointers to the API documentations of Qt4 don't really help (I can google myself :-)). Also, I like to avoid dependencies as much as possible (so e.g. no pointers to GPS daemons written in Python). Too many components in the middle cause too much overhead and latency, and makes it very difficult to pinpoint the location of a bug when a midlet does not work the way it is supposed to. At this point I already have such examples for GPS and simple (file based) audio playback. So hopefully support for these features will soon be integrated in next release. Stay tuned!

Damn, this post is longer than I intended it to be :-)

Cheers,
Davy