Why Java?

There are three main reasons people might like to use Java to develop applications targeting the Pocket PC platform. First, and most important, it is very tempting to try to take advantage of the main promise of Java--"write once, deploy everywhere." In other words, if you could make a one-time investment in developing an application, and then deliver it to all sorts of computers running all sorts of operating systems, with no additional investment, that would not just be great--it would be fantastic!

The second reason is to try to leverage the existing skill set. Yep, that's right: there now exists quite a sizable pool of developers who have not worked with anything but Java in all of their professional lives! And third, it would be nice to be able to actually use those Java-based Web objects (better known as "applets"). Of course, there are not too many applets around optimized to run on mobile devices. However, things--as we all know very well--change quickly.

Let's take a look at options regarding Java-based application development in the Pocket PC universe.

The origins of Java

A neutral observer might ask: "Is Java really a suitable environment for anything besides full-blown personal computers, workstations, and servers?" The answer may surprise those unfamiliar with the history of Java itself. As it turns out, the origins of Java lie in the early 90's efforts by Sun to create a language and runtime environment for devices with limited computing capabilities. This effort, called the Green Project, included, among other things, Oak, an object-oriented language for programming consumer electronic devices and the first attempt to realize the now-famous "write once, run anywhere" paradigm. Eventually Oak was renamed Java.

The main reason that Java is a logical choice for the Pocket PC and, for that matter, any software development project isn't Java's heritage, but the fact that any Java-based development and runtime environment is well documented and therefore predictable and relatively easy to learn. Java itself is quite a compact language providing very little in the way of functionality. The bulk of that "other" computing functionality is delivered by supporting software called APIs--Application Programming Interfaces. And the key word here is application--emphasizing the fact that all the intricacies of dealing with the underlying operating system, such as databases and connectivity, are hidden by this software, so that the "application" developer, when using such an API, can concentrate on the features of his/her application without worrying too much about everything else.

Java APIs

APIs have proliferated, especially in the field of small devices. Let's take a bird's-eye view of them.

In the beginning there was Personal Java, targeted at devices to be used directly by a human user and therefore required to have some means of graphical output. Specifically, these devices would include things like TV set-top boxes, lightly configured networked computers, and PDAs. Personal Java even included optional support for software, called Truffle, that was designed to work with touchscreens—something even "big Java" didn't have.

Another API set is Embedded Java. It is very close to Personal Java in terms of the functionality it defines. The big difference is in the way it is used by implementers: Sun allows you to drop any features you deem inapplicable to your device and still use the name Embedded Java.

However, both Personal Java and Embedded Java are things of the past, or, to use Java lingo, "deprecated."

The new kid on Sun's block is J2ME--Java 2 Micro Edition. J2ME defines not a particular API, but instead an interconnected family of APIs. There are also two new terms introduced in conjunction with J2ME--configurations and profiles. Configurations are the most basic layers of the programming interface. They define the core set of services your application can expect to receive at the time it is running on your device. Profiles extend configurations to define additional, more specific functionality.