Now blogging at diego's weblog. See you over there!

diego's excellent symbian adventure, part two


in which diego discovers that J2ME is a lot less, and a lot more, than previously thought

[Part one, notes].

I concluded in part one that native development in Symbian is a difficult proposition at the moment if your main concern is, like mine, minimizing development time by targeting as many devices as possible with a single code base. Creating 80-85% portable "native" Symbian apps is possible, but complex, and difficult for new developers. Because of this, for many applications, J2ME will be the way to go.

micro-Java, not micro-J2SE

J2ME is truly a "micro" version of Java, rather than a reduced J2SE (Here's a good take on the topic from Russ). When J2ME was first launched there was another "contender" called Personal Java (based on JDK 1.1.8) which we'll ignore since it's currently being phased out by Sun. To get some context, let's look again at the varieties of Java:

  • J2ME: a Java-based platform for small/memory limited devices.
  • J2SE: the Standard Java platform for desktop/mobile computing and above.
  • J2EE: Enterprise-oriented additions to J2SE, mostly in the forms of new libraries and APIs that plug into enterprise runtime environments.

J2ME targets areas that, unlike the (slightly) more uniform target of J2SE/J2EE, require support of widly different devices and capabilities, in terms of I/O, processing power, memory, and everything in between. As a consequence, J2ME is actually a set of specifications. Each specification targets a configuration, which then can be further defined by using it with different profiles.

And herein begins the acronym-fest. There are, currently, two main types of configurations. The CLDC and the CDC (not a bad name, in our virus-ridden times). The CLDC ("Connected Limited Device Configuration") is a low-end configuration target: cellphones, low-end PDAs, etc. CDC (Connected Device Configuration) on the other hand targets everything between the high-end of CLDC and the low end of devices that begin to support J2SE. (CDC + the Foundation Profile, the Personal Basis Profile and the Personal Profile define the equivalent of Personal Java but with more flexibility, which is why Personal Java has been discontinued, btw).

Now, both the CLDC and CDC reference VMs differ from the J2SE VM, and from each other. I'll be most interested in the CLDC VM (The KVM, or Kylobyte Virtual Machine), since it's the one used in most Symbian phones. The KVM is limited compared to a J2SE VM, not just in features (e.g., no advanced JIT techniques) but also in capabilities (e.g., floating point arithmetic is not required by the CLDC spec).

Talking about VMs is all well and good, but in the end what makes Java a platform is its libraries as much as it is its VM. So what about libraries in J2ME? Well, that's where the profiles come in.


Profiles add packages and classes to configurations, and each configuration has one or more associated profiles. And for CLDC, the most popular profile is one called the Mobile Information Device Profile or MIDP.

The MIDP adds basic networking, UI elements and minimal storage capabilities to the CLDC, and it is normally used for wireless devices (phones, PDAs, etc). Recently Sun announced the release of a new an improved MIDP, MIDP 2.0. But most Symbian phones implement CLDC with MIDP 1.0, and only one so far (the Nokia 6600) supports MIDP 2.0 (that I know of). SonyEricsson's P800 supports Personal Java, but that's a dead end since it has been discontinued.

In general, profiles try to use subsets of classes from J2SE. Whenever a class from J2SE is used, only methods already existing in the J2SE version can appear in the J2ME version (i.e., no new methods can be added). That's why the classes/packages some of what we already know from J2SE (say, java.lang.*), or are completely different (the storage classes in MIDP 1.0).

MIDP allows various optional packages such as the Mobile Media API and Wireless Messaging API which are included on some phones such as the Nokia 3650 and newer APIs such as the Bluetooth API on the 6600, as well as APIs in development such as 3D Graphics API for future models.

enough with the theory

After a while it's quite clear that the best way to do multi-device deployment with J2ME is to use MIDP 1.0. Using this profile, you can create Midlets, similar to Applets. Like applets, midlets are limited in their access to the local device, something that is even more visible because of the limitations of the MIDP 1.0 API (PDF, 171 KB).

Now for getting together a J2ME development environment for Symbian requires. To start with, I'll need Sun's J2ME WTK (Wireless Toolkit) either version 1.0.4 (for MIDP 1.0) or version 2.0 (for targeting MIDP 2.0). So I get WTK 1.0.4. Plus, let's say that I'd like to test with a Nokia simulator. I need to get the Nokia Developer's Suite for J2ME, plus an emulator such as the Series 60 Emulator/SDK (which for this phone includes cool things like the Bluetooth Java APIs--but careful! Since other MIDP 1.0 phones might not support that API yet).

The final element in all of this is the IDE integration. The steps necessary to go from cource to binary, and then to deploy it into the phone emulator (or into the phone) are Definitely Not Fun. So getting an IDE that will do them automatically is essential to keeping my sanity. The first option I looked at was CodeWarrior, but CW came integrated with WTK 1.0.3 (instead of 1.0.4) and didn't allow upgrading it. JBuilder 9 for Mobile Dev didn't have a trial download. Eclipse... well. Eclipse was an option :). But I thought that maybe IDEA, which I use for other Java development, had some Plug-In... and sure enough, there it was. Excellent. A bit of fiddling, and finally I was able to see my simple Hello World! application running in one of the default "phone covers".

Note: a big Thanks to Russ, who guided me in my search for tools and toolkits. Without his help, it would all have taken a lot longer than it did.

Now, this is all a lot more complicated than it needs to be, and Sun isn't necessarily helping matters. Hopefully the situation will improve in the near future, to make it easier for new developers to approach J2ME on Symbian platforms (and others, too).

native v. java

What is probably one of the most ridiculous limitations of MIDP 1.0 is its inability to access the device's store (e.g., contacts, calendar entries, notes, etc). This hugely limits the kinds of useful applications that can be written in Java (which in many cases will want to interact with phone data and services). And there's still no standard to access the bluetooth functionality (although it's coming, too).

At a minimum, creating a prototype with J2ME should be easy enough (once the development environment is set up) so that then certain Symbian devices can be specifically targeted with native development. J2ME apps can be targeted to devices beyond symbian, such as Palm. However, they have some serious limitations. If an application needs to access low-level functions or device data, native development is a must. Otherwise, J2ME might be a good alternative to simplify portability.

Posted by diego on August 24 2003 at 9:12 AM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37