Okay. Let's get one thing clear right away. I am not writing (or better yet, dictating) this on a Java-enabled PDA while sitting on the bus on my way to work - a fact that I find somewhat disturbing, and more than a little annoying. Perhaps not as disturbing as my fellow passengers would find it if I was talking into a little box, but disturbing nonetheless. Instead, I'm balancing my notebook on my lap, at a 45-degree angle, while lying on the sofa.

The other way would really be more convenient for those times when I'm just too lazy to sit properly.

Why then, you may ask, is there no cute little coffee cup logo on the bottom right-hand corner of my screen? The answer is that despite the fact that Java 2 Micro Edition software has been out for some time, there are few devices out there for me to play with that have J2ME installed (out of the box). This is not to say that there are no devices available, but it's not easy to walk into a consumer electronics store and find something sitting on the shelf, waiting for you.

Impatience aside, it seems likely that relatively soon there will be plenty of devices to choose from. A number of big players in the device market have announced Java support in some form. Motorola jumps immediately to mind, with their iDEN developer community - aimed at providing assistance to embedded Java developers. The expert group for the MID Profile (more on that later) reads like a who's who of big multinationals: AOL, Ericsson, Fujitsu, Matsushita (Panasonic), Mitsubishi, Motorola, NEC, Nokia, NTT DoCoMo, Palm Computing, Sharp, Siemens, Sun Microsystems (obviously), and Symbian, among others, sit in the group. (For the full list, see the MIDP FAQ listed in the References section at the end of this article.)

So what is Java 2 Micro Edition, and why is everyone so keen on it?

The Electronic Coffee Cup
Java (before it was even called Java) was originally destined for consumer electronics devices. Obviously this focus changed along the way, and the Java we know today eventually emerged (for a full history lesson, see the References section). It seems we are now coming full circle and returning to the very devices it was originally intended for.

However, despite hardware technology advances, you are unlikely to find a handheld device with the requisite storage space to handle the Standard Edition of Java (a runtime size of around 5Mb) plus the processor requirements to make the most out of it. Which is undoubtedly the reason why PersonalJava emerged, in due course.

More recently Java was split into three main platforms: Java 2 Standard Edition, Enterprise Edition and, of particular interest to us, Micro Edition. In the words of Sun, Micro Edition "specifically addresses the vast consumer space, which covers the range of extremely tiny commodities such as smart cards or a pager all the way up to the set-top box..." (Java 2 Platform, Micro Edition, Sun Microsystems).

This is a shrewd move on Sun's part: the Java space is fragmenting somewhat because of these new platforms. Since an application written specifically for Standard Edition may not necessarily work unchanged on a Micro Edition device, it makes sense to have some form of delineation between the groups. It becomes even more necessary when you look at the number of products that fall beneath the J2ME umbrella.

Configurations and Profiles
Before looking at actual products, it's worth taking a look at how a product is defined within J2ME.

Configurations are the low-level APIs and virtual machine used by a product. There are currently two configurations defined as part of J2ME: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC targets devices with 160-512KB of total memory, limited power, possibly intermittent network connectivity, and limited or no user interface. The CDC targets devices with a 32-bit processor, 2MB of total memory and, again, intermittent network connection with limited or no UI.

Profiles sit on top of the configuration and specify all the other APIs required to provide a runtime environment for a particular type of device. The user interface also falls under the control of the profile. Figure 1 shows the relationships between configurations and profiles.

PersonalJava
Most people already know what PersonalJava is, so there's probably not much point in going into detail about the API. Suffice it to say that PersonalJava was there before J2ME emerged as a concept and the specification describes a cut-down version of the Java Standard Edition to fit into resource-constrained devices. PersonalJava, as it stands, does not really fit into the concept of "Configuration and Profile" and hence there are two specifications currently in development aimed at the same kinds of target device - JSR-000075 PDA Profile for J2ME and JSR-000062 J2ME Personal Profile. The latter is "...intended to provide the next generation of Sun's PersonalJava environment, and as such has the explicit requirement of providing compatibility..." with previous versions of the specification (see References). So it looks like PersonalJava will eventually be absorbed fully into the framework.

PersonalJava, in its current incarnation, is probably the most common version of Java you will find on small devices. The runtime environment from Sun is available for a number of WinCE machines, and compatible software is also available from a number of other manufacturers.

Mobile Information Device Profile
The Mobile Information Device Profile (MIDP) is one of the newer sets of APIs, and targeted at smaller gadgets than PersonalJava. In fact, if you take a look at the MIDP specification, devices are severely constrained. A MIDP device "should" have a screen size of 96x54 pixels, display depth of 1 bit, have 128KB of nonvolatile memory (in other words, memory that is retained when the device is switched off) for the application components, 8KB of nonvolatile memory for persistent data, and 32KB for the Java runtime (taken from the Mobile Information Device Profile JSR-37 JCP Specification, Sun Microsystems, Dec. 2000).

The first home computer I ever used was a Radio Shack TRS-80 (or Trash 80, as it was affectionately known). At the time, this had 64KB of total memory and pixel depth of 1 bit (I don't remember what the screen size was, but I seem to recall the actual "pixels" themselves were about 3mm X 4mm, or something close) - so the MIDP minimum specification is scarily close to the average spec of home computers available in the '70s. Luckily, the machines themselves will be a good deal smaller (I hope, because carrying a mobile phone around that's the size of a Trash-80 would result in one really muscular arm), but the environment you would be developing for is not that far removed.

(Note: MIDP sits on top of the Connected Limited Device Configuration [CLDC] and uses the K Virtual Machine.)

Foundation Profile
Another profile currently in development is a device the Foundation says does not require a graphical interface, but "...will also be used as the basis for other profiles that will add GUI as well as other functionality" (from the JSR #000046 J2ME Foundation Profile specification, Sun Microsystems). The Foundation Profile sits on top of the Connected Device Configuration and uses the C Virtual Machine. At the moment it is only available as part of Sun's Community Source Licensing, for Linux or VxWorks, and as such is a little bit beyond the scope of this discussion.

Other Players
There are many other players in the market, supplying virtual machine software for numerous devices. Some have virtual machines that fall within the boundaries of J2ME; others fall somewhere just outside, but are intended for the same market.

IBM has the J9 virtual machine, with runtime support for a variety of architectures (Linux/ARM, Linux/PPC, Linux/x86, QNX in various forms, the Palm OS, and Windows CE). They also have CLDC and a Personal Profile, currently in beta form. Insignia has their Jeode EVM, Wind River has Personal JWorks, Hewlett Packard has ChaiVM, Tao Group has Intent JTE. Most of these are either compatible with PersonalJava or, at the very least, are aimed at a similar type of device.

Support for MIDP is still emerging, but Motorola has a J2ME software development kit, with support for MIDP in their Accompli 008 All-In-One Phone, and the i85s (possibly others as well). NTT DoCoMo supports the KVM on some of their i-mode cellular phones. With Sega developing entertainment content for both, the popularity of the phones would seem assured (see References).

The Great Mobile Land Grab
So success for J2ME appears reasonable, considering wide industry support. But why are all these companies so enthusiastic about the idea?

The answer would appear to lie - at least in part - in the current state of the PC industry. Handheld devices and mobile phones (games consoles, as well) are selling in larger and larger quantities, compared with what seems to be a downturn in the personal computer market. Handheld devices are, of course, cheaper than PCs, and a degree more approachable to the nontechnical public, and fashion is also playing a part in their popularity. The Compaq iPaq is an undeniably sleek piece of hardware (not to forget the Claudia Schiffer Edition Palm PDA although, as much as I squint at the thing, I can't see the resemblance). So with the handheld and mobile market continuing to blossom, Java is, I believe, a logical choice for many of these manufacturers.

The problem with developing software using a language compiled to native code (especially for PDAs and mobiles) is that portability becomes a major issue. The architecture of each platform may differ significantly, and thus, a developer will have to invest considerable time and effort to move their applications from one to the next. Therefore, unless the device has a majority market share, it may be difficult to entice developers to the platform.

J2ME may very well solve this problem for manufacturers. The time to port an application across multiple platforms should be greatly reduced; the developer expends less effort to do so, and the market they're selling to is even larger. The manufacturer gains by having more software available for their product, and the developer gains by the larger market. (I agree that this is an oversimplification of the issues, I merely hope to provide at least one reason why industry support is growing.)

The Master of Many Disciplines
Hopefully, you now have a vague idea of what you might find beneath the branches of the J2ME tree. Wondering what to do with it?

A developer building applications for PersonalJava or MIDP will undoubtedly be expected to be a "Master of Many Disciplines." Applications that must work within a limited environment are likely to rely on a certain amount of server-side support. This will be especially true for MIDP apps (or MIDlets, as they're called). So not only will you need a working knowledge of Standard Edition, but probably of the servlet API, networking using http and/or datagrams, and possibly even J2EE (Enterprise Edition). Putting all those disciplines together, what can you do with them? Pretty much anything.

The first applications to emerge (at least for MIDP) will be entertainment-related. Take a quick look at Bill Day's J2ME archive and you'll find that a majority of the applications offered are games. This is not surprising since games (especially multiplayer) are a good (and fun) way to learn the capabilities of a platform. Game development requires graphics, event handling, thread control, and sometimes networking.

My personal belief - probably not shared by the majority, but then it's just an opinion - is that developing games is more challenging, and therefore more rewarding, than developing other types of applications, purely because it exercises your abilities in all those disciplines.

An added advantage is that buyers of these new mobile phones are more likely to download games than other applications, at least until someone comes up with an idea for the product that everyone has to have. I've lost count of the number of times I saw people playing "Snake" on Nokia mobile phones when they first came out.

Some Ideas
Multiplayer applets and shockwave apps are a good place to start looking for ideas. Potentially, a basic shockwave app should scale fairly well, down to a MIDlet. For example, looking at something like Habbo Hotel (www.habbohotel.com), which uses simple 3D-styled graphics to create a chat room with a difference, it is not unreasonable to think that a similar paradigm would work well even in the restricted MIDP environment. The graphics are sprite-based, and the interface is a simple point-and-click affair (in other words, you point your mouse and click, and your character moves to that position), so network traffic is relatively light. The only really ambitious part of the exercise would be the chat mode. I personally wouldn't want to sit pushing 44-33-555-pause-555-666-0-6-999-0-66-2-6-33-0-444-7777-0-5-2-7777-666-pause-66 on my mobile just to say, "Hello my name is Jason," but who knows, the idea might take off, and as an added bonus, it might create a thriving industry in repetitive-finger-strain-injury medicine.

Games that were popular in the "days of old" will also provide a likely source of material. Don't yawn. Porting a classic game to MIDP might not sound very innovative, or very exciting, but it's another way to learn the technical side of the platform, as well as the limitations, without having to worry about game-play mechanics, balancing, and all the other little issues that go into the design of a game.

Murmurings from Sun
Over the last few months, more and more stories have appeared on the Sun Web site (and on others) regarding Java and gaming. More recently, a Sun press release announced the imminent launch of a new Web site for Java games developers (www.javagaming.org) to provide resource and up-to-date information to the Java gaming community. Hopefully, by the time this article goes to print, the Web site should be up and running.

This support from Sun is another good incentive to get into game development for J2ME. There are very few sites dedicated to game development in Java, so you're forced to glean information from places where there may be as much misinformation as genuine facts and useful resources. An example of this is asking a question at a general game development forum such as, "Has Java3D performance improved enough for games development?" Replies to this could range from outright flame attacks to "I've never tried, but last time I looked it was garbage," instead of something practical like, "I've used it for modeling a walk-through of the architectural design of a new building, and performance was acceptable, but improved when we did this... ."

Decisions, Decisions...
Assuming you're not just experimenting with the technology, and actually want to work on a real product, which of the two main J2ME platforms should you be developing for?

The decision depends very much on your application. PersonalJava provides a much richer API to draw from; the target devices have more screen real estate, faster processors and more memory. MIDP is very limited, which presents its own set of challenges, the devices (likely to be mobile phones initially) have small screens, a minimal amount of memory, and a processor that a snail would find fast, but the rest of us will find somewhat taxing.

Competition may also be a deciding factor in your decision. PersonalJava has been around much longer, so your concept may have been "done to death" on PDAs. Therefore MIDP might be a better choice (assuming that the application will scale to a much smaller device; the next best-selling word processor is not a likely candidate for a mobile phone).

On the other hand MIDlets (MIDP applications) may rely quite heavily on server-side support to provide advanced functionality. Establishing this resource could be a complicated proposition for a small developer. Issues such as middleware and database platforms, initial and projected storage requirements, and scalability - to name just a few - all have to be taken into consideration: setting up database, middleware and Web servers, to support your app, is potentially an exercise in draining your wallet.

Partnerships and development deals might be more accessible for a MIDP application developer than for PersonalJava. With the market so new, the mobile networks will possibly be quite enthusiastic to fill their software catalogs, if only to keep one step ahead of the competition.

C and C++ have an established tradition in the PC and console games market. It has been difficult to argue Java the language, or Java the platform, as a replacement for this tried, tested, and trusted technology. Which is not to say that there isn't an argument for Java on these platforms. However J2ME starts off on a more level footing with other languages, probably on a better footing considering the portability advantages.

One negative thought in all this is that it's not completely clear whether there is definitely money to be made in the burgeoning mobile market for embedded Java developers. The promise is there, but will that promise turn into hard cash? Will all that hard graft actually pay off? These are questions that, certainly when the technology is just emerging, won't be clear until after the fact. I imagine that predicting the direction the industry is going to take would be like trying to foresee the dot-com boom and bust, back before the Netscape team had rolled out their first browser. At the very least, we could expect to see a huge games market emerging for Micro Edition over the next few years.

Footnote
Are you working on MIDP or PersonalJava software, be it a game or a "serious" application? Is your app likely to knock the socks off anything else out there? Or do you have a Java-compatible device that will be the doohickey of choice for the X-Y-Q-R-what-letter-are-we-up-to-generation?

If so, please drop me a line for the possible inclusion of your product in a future article.

References

1. The J2ME home page: http://java.sun.com/j2me/
2. The MIDP Frequently-Asked-Questions List: http://java.sun.com/products/midp/faq.html
3. Bill Day's J2ME archive: http://www.billday.com/j2me
4. A brief history of Java: http://ei.cs.vt.edu/~wwwbtb/book/chap1/java_hist.html
5. The two Community Process specifications that seem to fall within a similar space to PersonalJava: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_062_pprof.html http://java.sun.com/aboutJava/communityprocess/jsr/jsr_075_pda.html
6. The Mobile Information Device Profile Community Process specification: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_037_mid.html
7. The Foundation Profile: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_046_j2mefnd.html
8. Motorola's press release (last November) about Sega developing games for Motorola phones: www.motorola.com/NSS/Press/press_archive_2000/20001129.html
9. Information on the Motorola i85s mobile phone: www.mot.com/LMPS/iDEN/products/i85s/i85s.html
10. The Accompli 008: www0.motorola.com/developers/wireless/products/matrix/details/index.html?product=11
11. Sun's games press release: www.sun.com/media/pressrel.mar_egaming.html
12. The new Java Gaming Web site: www.javagaming.org