Man, are handheld devices stupid. Who needs them? They're slow, have less memory than an amnesiac, run out of juice too quickly, and pack negligible power.
That's what I used to think. Then the folks at JavaOne 1999 offered an extremely discounted price on the Palm V, announcing that it would become the reference implementation for the Micro Edition of Java. I began to see the light. The Palm was more than a fancy chrome gizmo to whip out at parties and business meetings. It was a paradigm of elegant software design, with every task only one thought away. The key to falling in love with handheld computers isn't to look at today's clunky or dinky models, but to interpolate a bit. In the near future, handheld devices will be as powerful as any desktop. And constantly connected to the Internet at broadband speeds, to boot.
But I soon found that programming for handheld devices is a pain. The screen is miniscule 160 by 160 on the Palm, and much less on cell phones. The memory is limited the Palm only gives you 2 to 8 meg, depending on the model. You have little dynamic memory to play around with most cell phones only give you 32K, the Palm has a 96K heap limit. There's limited network connectivity, with teeny, tiny bandwidths. And the processor itself is often hundreds of times slower than your average desktop.
Programming in a language like Java only adds a layer onto this hard-to-digest cake. Sun's Kilobyte Virtual Machine (KVM) gets its name because it takes up a few kilobytes of space. But even those few bytes are wasteful. The KVM also usurps a fair bit of memory. A native application is the size and power it is, asking for nothing more. In addition, Java classes have the added overhead of a slow startup. If you click on a KVM class, you'll notice a few seconds of an annoying little Duke mascot waving at you. While this is going on, the KVM is going through the class, allocating heap space and verifying the bytecode.
Additionally, a Java programmer is restricted to the capabilities of the virtual machine. Because Java must work on a wide variety of devices, it is written for the lowest common denominator. The KVM, for example, doesn't support floating-point integers, Palm registers, native Palm widgets, or nifty wireless utilities such as the Palm VII's Web clipping. That's a lot of good stuff to lose!
Due to all the restrictions on a small device, there is no way of fitting in a just-in-time compiler (JIT). This means code will run quite slowly. In fact, while playing around with some casual tests, a Java 2 Micro Edition (J2ME) application runs about three to eight times slower than a native Palm application written in a compiled language such as C.
So is Java like war good for absolutely nothing?
Not quite. Java is perhaps the easiest modern language to develop in. With garbage collection of old objects and lack of memory allocation and pointers, it's a great way to create quick prototypes and develop full apps. The object-oriented nature of Java makes it easy to maintain, making sweeping code changes with little modifications to a superclass.
Writing a native Palm application requires countless hours of debugging, testing, and packaging. Write to a wrong memory location, and you can easily fry the machine, requiring a hard reset. Waste a little memory on a desktop or server application, and nobody will bat an eye. But when dealing with a tiny space like the Palm, every bad byte hurts.
Perhaps the most compelling argument for using Java is that you guessed it you can write once and run every-damn-where. Theoretically, an application written for a Motorola cell-phone can also run on a Palm. The same code could be compiled and run as an applet in a Web browser, as an application on a million-dollar server machine, in your car's dashboard, or eventually in a Java-powered neural link to your own brain!
There have been several attempts to bring Java technology down to the small devices such as Ghost Machine, Jump, and Waba. Jump is a Java language front-end. Java code is interpreted into assembly code and compiled natively. This is nice, this is fast, but it isn't really Java. Waba, on the other hand, has its own virtual machine. But it takes a few liberties with its abilities and doesn't meet exact Sun standards.
Hence the popularity of the KVM. The KVM is made and distributed by Sun Microsystems and is a component of Java 2 Micro Edition (J2ME). This means it is a true-to-its-word subset of the standard Java libraries. Currently the Palm is the reference platform for Sun's KVM development, until all the bugs and issues get ironed out. But the J2ME world extends well beyond the lowly Palm. The J2ME consists of:
- The KVM. This resides on the handheld device and actually runs the bytecode you write.
- Configurations. These are the core classes that must be implemented for a particular type of device. For example, the Connected, Limited Device Configuration (CLDC) is meant for any device that has limited memory, screen size, and input abilities, but that is connected to a network. This includes most cell phones. Companies like Sun, 3Com, Bull, Ericsson, Matsushita, Mitsubishi, Motorola, Nokia, NTT DoCoMo, and Siemens are hammering out this standard.
- Profiles. These are Java libraries for specific brands of devices. All the user interface, programming and event models, networking, and error handling is implemented in one of these. For example, the Mobile Information Device Profile (MIDP) is being developed using Sun's Community Process by companies such as AOL, Palm, Nokia, Sony, NEC, Motorola, Alcatel, Ericcson, NTT, DoCoMo, Psion, and Siemens. There are different profiles for different device families, and there is currently no official profile for the Palm.
There are, however, many snags to work out before J2ME can hit the big time. The KVM has no Java Native Interface (JNI), which means you cannot access all the cool aspects of the Palm, such as lists with several columns, drop-down lists, graffiti, or native dialog boxes. You also can't directly access the Palm's IR port or serial port. Palm is currently working on expanding their J2ME profile so that the full range of Palm's abilities can eventually be harnessed, but how well this will be implemented is anyone's guess.
Also, the Palm edition of J2ME currently includes a set of libraries in the
package that allow you to do things like detect stylus presses, beam data, and deal with bitmaps. Since this
package doesn't exist anywhere other than the Palm, the code you write isn't exactly upwardly compatible. These classes are only temporary placeholders for a more robust profile. In other words, any code you write today will need to be rewritten soon. Palm's commitment to Java and the KVM is also in question. At JavaOne 1999, the Palm booth was buzzing with info and promises. This year, however, the booth was all but unmanned. Also, the work being done on the Mobile Information Device Profile really applies to cell phones, not to more-powerful devices like the Palm.
Palm and Sun are currently working on a Java specification for a PDA profile. If you're interested in Java PDA development, be sure to keep close tabs on this!
In fact, all the J2ME configurations and profiles are still very much in flux. If you want to develop for J2ME realize that you aren't only riding the cutting edge, you're riding a rapidly moving edge. So wear a saddle!
In Java 2 Micro Edition and the Kilobyte Virtual Machine , we'll delve into the specifics of actually getting your hands dirty writing a J2ME application for the Palm.
Java programming for Windows CE and the Palm OS using Waba