Sock it J2ME, baby!

After several years of dev management, and a stint in a fairly esoteric high-level technical architecture position, I've somehow managed to be reborn as a J2ME developer. Given that I once wrote applications for one of the first smart phones, using nothing but 8086 assembly, the irony that I'm now writing (and whining) about using Java on this platform is not lost on me.

That said, let the whining commence.

• There are some fairly stupid things in the J2ME spec. For example - there's no good way to specify how much storage space your app requires, unless you have fixed storage requirements. Basically, you have to specify in advance, in a static application descriptor how much space you want. If you specify more than what the phone can supply, it won't let you install. If you specify less than what the phone can supply, you can install, but it won't let you use any more than what you originally requested. It's as if nobody ever thought that perhaps an application might like to be able to use a dynamic amount of storage, based on either total storage availability, or on user usage.
• Phones have arbitrary limits on the size of the application they'll let you install. There's not really any reasoning behind these limits as far as I can tell - they just have them. So, for example, you might have a phone with 6MB of storage, and > 1MB of heap space, but they still limit your application (JAR) size to 128K.
• The security model is dictated by the manufacturers/carriers, and is seldom controlled by the end user. This means that if your application wants to use the internet on (say) a Motorola V400, it'll prompt the user for his OK every single time - the user doesn't get an option to say "OK, don't ask me again" unless your app is signed. Which brings us to:
• There's no practical way to sign your application, so it can access privileged APIs on multiple devices. You could (for example) go to the major cell manufacturers, run the gauntlet of their obscure developers program, and get them to sign your app, but you would then find that a number of cell carriers specifically don't accept the manufacturer's signing key, but instead require you to sign your application with their specific carrier key. And they generally have no interest in dealing with you, as an individual or small scale developer, so you have no way of getting your application signed. And god help you if you are writing an application that is anything but a game, because they aren't interested.
• The manufacturers are all very excited to have you use their special APIs on their devices (for example, JSR 75, which gives you access to the phone's address book). Of course, you can't actually call these APIs unless you have your app signed. And even if you can find someone to sign your app, you can't get your app signed until it goes through a testing/certification process. But you can't put your app through the (fairly pricey) certification process until you've tested it yourself, and you can't test it because you don't have access to the privileged APIs! "Oh, but you can test it on the emulator", they say, speaking slowly and clearly as if you are a simpleton. Which brings us to:
• Every device has their own, screwy bugs. For example, the Nokia 6230 won't let you write more than 32K to any single record store, even though the record store APIs report that there's plenty of space available. And, the device throws exceptions if you try to do anything with more than one record store open at once. Some Motorola phones have issues with not being able to overwrite data - you can add records and delete them, but you can't overwrite them. Other devices have threading issues that affect how you can read/write data from network connections. Some devices handle timezone math correctly in the Calendar object, others don't. Blah blah blah, ad nauseum. Heck, even the Sun reference implementation has bugs in their record store implementation that show up if you try to access record stores from multiple threads. And don't even get me started on the pain involved in getting HTTP connections working on different cell networks, through different (buggy) proxies. The point being that if you are a J2ME developer, expect to spend at least half your time doing testing/debugging on the specific phones that you want to run on, and while an emulator is a valuable development tool, it's no substitute for hands-on device testing.

Whew. Sorry, I do ramble on, but I had about 3 months of pent-up frustration to let out. I actually have learned some fairly interesting and useful tidbits about writing J2ME apps, which I'll dole out eventually in some future post.