A Brief Look at Java 2 Micro Edition
by Michael Nygard
Abstract
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.
Resources
Many of the best sources of information come from the Java Community Process site.
Configurations
Profiles
KVM
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 michael@wirelessdevnet.com.
