Proceed to WirelessDevNet Home Page
Publications, e-books, and more! Community Tutorials Store Downloads, tools, & Freebies! IT Career Center News Home

EMail Address:

  - Articles
  - Columns
  - Training
  - Library
  - Glossary
   Career Center
  - Career Center Home
  - View Jobs
  - Post A Job
  - Resumes/CVs
  - Resource Center
  - Marketplace Home
  - Software Products
  - Wireless Market Data
  - Technical Books
  - Daily News
  - Submit News
  - Events Calendar
  - Unsubscribe
  - Delivery Options
  - Discussion Boards
  - Mailing List
  - Mailing List Archives
   About Us
  - About WirelessDevNet
  - Wireless Source Disks
  - Partners
  - About MindSites Group
  - Advertising Information

A Brief Look at Java 2 Micro Edition

by Michael Nygard


Java now presents an incredible variety of platforms and APIs: J2ME, J2SE, J2EE, PersonalJava, EmbeddedJava, TV, Telephony, and the KVM (to name a few.) As Java moves off of the desktop, these diverse specifications accommodate the wide variety of device capabilities and features. For the programmer who already knows Java, this article will help put J2ME and its close relatives in their places.

The History of Small (and not-so-small) Java

Java did not start out as a 20MB platform. (In fact, it didn't even start as "Java", but that is another story.) Java started small, aimed at television set top boxes and other interactive devices. Of course, once it got aimed toward web browsers and applets, the brakes were off. As a result, the platform got all kinds of amazing features like Swing, Java 2D, Java 3D, JDBC, EJB, and so on. With each new API, the size of the platform got bigger and bigger and bigger. So did the runtime footprint. These days, it is not uncommon to see Java virtual machines with a gigabyte or more of heap space. Whether you want to call this featuritis, bloat, or customer responsiveness, the fact remains that the Java 1 platform was big, and the standard Java 2 platform is huge.

Obviously, the large size of the platform conflicts with the goal of WORA (write once, run anywhere). Not every device that needs programming can support a multi-megabyte process size. Sun first addressed this need in 1997 with the introduction of several Java platforms, aimed at different segments of the market. JavaCard would take the very smallest devices-smart cards. EmbeddedJava covered devices with no user interface. PersonalJava aimed at the "network appliance" market. Enterprise Java would handle entire corporations. These platforms differed mainly in the subset of the Java API they each supported.

Introducing J2ME

As time and technology moved on, Sun recognized the need to collect the device-oriented platforms under one umbrella. At JavaOne in 1999, Sun introduced the Java 2 Micro Edition. J2ME is not a specific virtual machine, API, or specification. Instead, J2ME provides a modular, scalable architecture to support a flexible deployment of Java technology to devices with diverse features and functions. A J2ME "configuration" targets devices with a specific range of capabilities. A "profile" selects a configuration and a set of APIs to target a specific domain of applications. By selecting the best configuration and profile, a vendor can produce a wide range of flexible applications. Since lightweight appliances do not need to support the entire Java 2 platform, their resource requirements (and therefore cost) will be reduced. At the same time, by allowing modular extensions, J2ME allows vendors to differentiate themselves by producing innovative applications and incorporating value-added features.

J2ME Configurations

A J2ME configuration defines an API and a virtual machine optimized to service devices that fall into a particular range of capabilities and resources.

Two configurations have been defined, the Connected, Limited Device Configuration and the Connected Device Configuration. At this time, there is no configuration for disconnected devices.

The Connected Device Configuration expects devices with substantial resources. In particular, it requires at least 512K ROM and 256K RAM, and a device that can support a complete JVM implementation.

The Connected, Limited Device Configuration provides a platform for more resource constrained, but still network-connected devices. (The network connection may be intermittent.) It specifically requires (from "JSR-000030 J2ME Connected, Limited Device Configuration" ):

  • 128K to 512K total memory available with <= 256K ROM/Flash and <= 256K RAM. In most cases devices will have more ROM than RAM or Flash memory.
  • Limited power, often battery operation.
  • Connectivity to some type of network, although with possibly limited(9600/bps or less) bandwidth.
  • User interfaces with varying degrees of sophistication down to and including none.

This category of device includes cell phones, two way pagers, and PDAs.

J2ME Profiles

Profiles define additional class libraries and APIs needed to enable domain-specific applications on a particular configuration. Profiles provide the vertical specialization built upon the horizontal configurations. For instance, the Mobile Information Device Profile requires at least the Connected, Limited Device Configuration. It enables development of applications to provide wireless access to information.

The most basic profile is the Foundation Profile. The Foundation Profile requires the Connected Device Configuration. It explicitly supports devices with no user interface whatsoever, but which do have networking support.

What About All Those Other APIs?

So what happened to PersonalJava, EmbeddedJava, JavaPhone, and the others? In the future, they will be migrated to J2ME profiles. PersonalJava 1.3 is already moving in that direction.

The 'K' Virtual Machine

Sun has introduced a new Java virtual machine to support J2ME on 16 or 32 bit microcontrollers. Aimed at the Connected, Limited Device Configuration, the KVM is only 40K of object code and needs only "a few tens of kilobytes" at runtime. A KVM developer's release is available from the Java Developer's Connection (see Resources below.) This early release runs on 3Com's PalmOS v3.01 and higher. The distribution includes documentation, the KVM class library, and tools to package and install Java applications on PalmOS-based devices.

The Good

KVM is small. Really, really small. In its tightest configuration, it requires only about 40 kilobytes. It can also be customized. Several Java language and virtual machine features not required by most applications have been made optional. A particular J2ME configuration defines which of these optional features must be included in the KVM implementation. The follow features are optional:

  • Long, float, and double
  • Multi-dimensional arrays
  • Class file verification
  • Recoverable handling of Error classes
  • Threads
  • Event Handling
  • JNI
  • Class loaders
  • Finalization

If you install the developer's release of the KVM, you will see that some of these optional features are included in this implementation. Future configurations are likely to support some of the rest. One of the goals of the KVM was to support incremental deployment of J2ME features, so a future KVM implementation should allow selection of these features.

The Bad

The KVM weaknesses are directly connected to its biggest strength. In order to make it so small, Sun made some compromises in the Java language and virtual machine. This seems to be the long-feared fragmentation of the Java hegemony. Programming Java for J2ME is not like programming desktop Java or enterprise Java. More than even, it will be practically impossible for a developer to keep current on "Java Technology" as a whole. Specialization will be more necessary in the future. (Remember this when hiring!) 

Watch out for this one: The KVM does not implement the Java Virtual Machine Specification! It implements a subset of that specification. What does this mean? Well, first of all, do not expect WORA in all J2ME applications. A smart phone application will be extremely unlikely to work on a PalmPilot, or vice versa. This seems like it should be obvious, since the two devices have totally different capabilities, but since portability has been so much a part of the Java message, it pays to note its limitations under the J2ME. In general, J2ME applications will be portable across the profile they were designed for. In many cases, an application will also be portable from one profile to a more capable profile.

The Future of J2ME

J2ME is still very new and much of the platform is evolving. A lot of specifications remain to be written. Sun and its partners will define the future of J2ME together via the Java Community Process. Through the JCP, members will jointly define new profiles and configurations. One area of hot interest is real-time embedded Java.

Jini is conspicuously absent from J2ME at this point.  Sun acknowledges that Jini is absolutely essential. Expect to see Jini support in a forthcoming version of the KVM. It is also likely that the Community Process will result in a new J2ME profile for a Jini-enabled device.

The future certainly has more J2ME devices in store. Obviously any PalmOS licensee will be able to use the KVM. Sun is also aggressively pursuing other partners, like Motorola and NTT DoCoMo. 

Support for J2ME is widespread, but not universal. IBM has their own JVM for embedded devices, called J9, that does not support J2ME. There are other, non-J2ME embedded virtual machines available, such as CrEme from NSIcom. Nevertheless, it is likely that J2ME compliance will rapidly become a must-have feature for embedded Java.


Many of the best sources of information come from the Java Community Process site.




Alternative Embedded Java Virtual Machines

About The Author: Michael is Chief Scientist of Javelin Technology, a Minneapolis-based consulting firm. His experience runs the gamut, covering scientific, military, financial, educational, banking, and manufacturing applications. Michael is focusing on true integration of wireless devices in the enterprise. He can be reached at



Eliminate irrelevant hits with our industry-specific search engine!

Wireless Developer Network - A MindSites Group Trade Community
Copyright© 2000-2010 MindSites Group / Privacy Policy
Send Comments to: