Mobility Overview

Wireless communications is a huge field, encompassing everything from radio and television broadcasting through pagers, mobile phones, and satellite communications. The field of mobile phones is expanding very fast at the same time that standards and protocols are being adopted, used, updated, and sometimes discarded. The other rapidly expanding part of the wireless world is that of wireless local area networks (LANs). Driven by widespread acceptance of the IEEE 802.11 standard, wireless local networking for computers and other devices is spreading rapidly.

Although wireless may seem like a special case, it is actually more intuitive and more natural than wired networking. Someday soon the need to plug a laptop into a network physically will seem quaint and antiquated. The notion that you could walk into a room with your cell phone and have it unable to interact with other devices in the room will seem unbelievably primitive. The future will reveal that wired networks are the special case.

Conceptually, wireless communications can be split into two types, local and wide area. A local device is similar to a key fob with a button that unlocks a car, a 900 MHz cordless phone, a radio control toy, or a Bluetooth network. All of these devices operate over short distances, typically just a few meters.

Wide area wireless devices operate effectively over a much greater area. A pager or mobile phone is a good example; you can talk on your mobile phone to any other phone on the planet. These devices' greater range relies on a trick, however: a more elaborate land-based network. A mobile phone doesn't have that much more radio power than a radio control toy. What it does have is a network of carefully placed radio antennas (cell towers); the phone can continue to operate as long as it is within range of at least one tower. The mobile phone device receives service from a wireless carrier, a company that operates the land-based network.

While a number of industry consortia and standard bodies, such as the International Telecommunication Union, are trying to define or foster the development of standards for the wireless world, today's wireless world is still fragmented and complex. If you buy a mobile phone in the U.S. today, it might run on Motorola's iDEN network or Sprint's PCS network. Take it overseas to Europe and you'll be out of luck--your phone will not work with Europe's GSM network, nor will it work with the PDC network or any of the other mobile networks that live in Japan.

More information about wireless communications is available here:

Making Sense of Cellular gives an introductory overview of the wireless radio spectrum.
World of Wireless Communications provides a brief overview of wireless communications and the concept of an embedded device.

The Java Platform comprises three elements:

The Java programming language is syntactically similar to C++ but differs fundamentally. While C++ uses unsafe pointers and programmers are responsible for allocating and freeing memry, the Java programming language uses typesafe object references, and unused memory is reclaimed automatically. Furthermore, the Java programming language eschews multiple inheritance (a likely source of confusion and ambiguity in C++) in favor of a cleaner construct, interfaces.
A virtual machine forms the foundation of the Java platform. This architecture offers several attractive features: The virtual machine can be implemented to run atop a variety of operating systems and hardware, with binary-compatible Java applications operating consistently across many implementations. In addition, the virtual machine provides tight control of executed binaries, enabling safe execution of untrusted code.
Finally, an extensive set of standard application programming interfaces (APIs) rounds out the Java platform. These support almost everything you might want your applications to do, from user interface through cryptography, from CORBA connectivity through internationalization.

Taken together, the Java language, Java virtual machine¹, and Java APIs compose the Java platform. Moreover, the Java platform is designed to encompass a wide range of computer hardware, everything from smart cards through enterprise servers. Therefore, the Java platform comes in three flavors:

Java 2, Standard Edition (J2SE) is designed for desktop computers. Most often it runs on top of OS X, Linux, Solaris, or Microsoft Windows.
Java 2, Enterprise Edition (J2EE) is a comprehensive platform for multiuser, enterprise-wide applications. It is based on J2SE and adds APIs for server-side computing.
Java 2, Micro Edition (J2ME) is a set of technologies and specifications developed for small devices like pagers, mobile phones, and set-top boxes. J2ME uses subsets of J2SE components, such as smaller virtual machines and leaner APIs.

To learn much more about Java technology or the Java platform, visit http://java.sun.com/:

The New to Java Programming Center offers an excellent entry point into the Java platform, understanding it, getting it installed on your computer, and starting to program.

Unlike J2SE, J2ME is not a piece of software, nor is it a single specification. This difference can be confusing, even for developers who are already familiar with J2SE. Instead, J2ME is a platform, a collection of technologies and specifications that are designed for different parts of the small device market. Because J2ME spans such a variety of devices, it wouldn't make sense to try to create a one-size-fits-all solution.

J2ME, therefore, is divided into configurations, profiles, and optional packages. Configurations are specifications that detail a virtual machine and a base set of APIs that can be used with a certain class of device. A configuration, for example, might be designed for devices that have less than 512 KB of memory and an intermittent network connection. The virtual machine is either a full Java Virtual Machine¹ (as described in the specification) or some subset of the full JVM¹. The set of APIs is customarily a subset of the J2SE APIs.

A profile builds on a configuration but adds more specific APIs to make a complete environment for building applications. While a configuration describes a JVM¹ and a basic set of APIs, it does not by itself specify enough detail to enable you to build complete applications. Profiles usually include APIs for application life cycle, user interface, and persistent storage.

An optional package provides functionality that may not be associated with a specific configuration or profile. One example of an optional package is the Bluetooth API (JSR 82), which provides a standardized API for using Bluetooth networking. This optional package could be implemented alongside virtually any combination of configurations and profiles.

The current universe of configurations, profiles and optional packages is shown in the diagram below. The tables immediately following provide more details about the abbreviations in the figure.

J2ME Overview

Configurations
JSR 30	CLDC 1.0	Connected, Limited Device Configuration
JSR 139	CLDC 1.1	Connected, Limited Device Configuration 1.1
JSR 36	CDC	Connected Device Configuration
Profiles
JSR 37	MIDP 1.0	Mobile Information Device Profile
JSR 118	MIDP 2.0	Mobile Information Device Profile 2.0
JSR 75	PDAP	PDA Profile
JSR 46	FP	Foundation Profile
JSR 129	PBP	Personal Basis Profile
JSR 62	PP	Personal Profile
Optional Packages
JSR 75	PIM	PDA Optional Packages for the J2ME Platform
JSR 82	BTAPI	Java APIs for Bluetooth
JSR 120	WMA	Wireless Messaging API
JSR 135	MMAPI	Mobile Media API
JSR 164		JAIN SIMPLE Presence
JSR 165		JAIN SIMPLE Instant Messaging
JSR 172		J2ME Web Services
JSR 177	SATSA	Security and Trust Services API for J2ME
JSR 179		Location API for J2ME
JSR 180	SIP	SIP API for J2ME
JSR 184	3D	Mobile 3D Graphics API for J2ME
JSR 186		JAIN Presence
JSR 187		JAIN Instant Messaging
JSR 190		Event Tracking API for J2ME

As the diagram shows, J2ME has two main branches. The first is based on the Connected, Limited Device Configuration (CLDC). This configuration is for small wireless devices with intermittent network connections, like pagers, mobile phones, and Personal Digital Assistants (PDAs). The Mobile Information Device Profile (MIDP), which is based on CLDC, was the first finished profile and thus the first finished J2ME application environment. MIDP-compliant devices are widely available.

The other major branch of the J2ME tree is based on the Connected Device Configuration (CDC). This configuration is for larger devices (in terms of memory and processing power) with robust network connections. Set-top boxes and internet appliances are good examples of CDC devices, although high-end PDAs like the Sharp Zaurus also fit this configuration well. The Foundation Profile extends CDC and serves as the basis for several other profiles. It provides fundamental APIs gleaned from J2SE, including classes and interfaces from java.lang, java.io, java.security, java.util, and more. For a list of J2ME terms and definitions, see our glossary.

Optional packages bubble like a froth above the CLDC and CDC branches of J2ME. These provide all sorts of capabilities ranging from Bluetooth communication through web services and instant messaging. Look in the table for links to the specifications themselves.

For a thorough look at J2ME, see:

A Survey of J2ME Today

The world of wireless Java technology also includes Java Card, for smart cards. For more information on Java Card, see:

An Introduction to Java Card Technology - Part 1

Devices implement a complete software stack, which usually consists of a configuration, a profile, and optional APIs. First generation J2ME mobile phones usually implemented the following software stack:

Example J2ME Stack

Given the plethora of configurations, profiles, and especially optional packages, how does a developer know what to expect on a device? JSR 185, Java Technology for the Wireless Industry, addresses this question by assembling other building blocks into a complete application environment. JSR 185 mandates CLDC 1.0 or 1.1, MIDP 2.0, and WMA. Support for MMAPI is optional. This helps nail things down for developers; on a JTWI device, the developer has a clear understanding of what APIs will be available. The following figure shows a JSR 185 stack:

JSR 185 Stack

For more information on JSR 185, see:

Understanding JSR 185

Wireless Java technology is the intersection of two vast worlds, wireless data communications and the Java platform. Wireless Java technology spans parts of Java Card, J2ME, J2SE, and J2EE. That said, some common misconceptions about wireless Java technology need clearing up:

Wireless Java technology and J2ME are not the same thing. On the one hand, J2ME encompasses more than just wireless devices. While some parts of J2ME are expressly designed for wireless devices, other parts are not--CDC devices are likely to have standard Ethernet connections. On the flip side, wireless Java technology is not confined to J2ME alone. You could have a laptop or palmtop computer running J2SE applications, connecting to other computers via an 802.11 LAN.
MIDP is not all of J2ME. MIDP is the first finished profile and has the first installed base of devices out in the world, so people sometimes assume that you are talking about MIDP whenever you talk about J2ME. As you can see from the diagram above, though, J2ME has many facets; MIDP just happened to cross the finish line first.
MIDP is not all of wireless Java technology. The Java platform offers plenty of choices for wireless programming: Personal Profile, J2SE on wireless devices, even the forthcoming PDA Profile.

For other perspectives on wireless Java technology, select:

Developing Wireless Applications with J2ME Technology (PDF) contains a high-level view of wireless Java technology.
Introduction to Wireless Technologies describes Sun's wireless technologies briefly.

The Java platform is an excellent choice for wireless development for many reasons. Here are three compelling advantages:

The Java platform is safe. Java code always executes within the confines of the Java Virtual Machine¹, which provides a safe environment for executing downloaded code. A binary application could freeze a device or crash it (imagine a blue screen on your mobile phone!) By contrast, at worst a Java applications can bring down only the Virtual Machine, not the device itself.
The Java language encourages robust programming. The garbage collector saves programmers countless hours of hunting down memory leaks. Likewise, the Java language's exception mechanisms encourage programmers to create robust applications.
Portability is a big win for wireless Java technology. A single executable can run on multiple devices. For example, when you write a MIDlet (a MIDP application) it will run on any device that implements the MIDP specification. Given the dizzying profusion of wireless devices, not having to maintain a plethora of implementations is a big advantage. Even if a Java application makes use of vendor specific APIs, applications written using the Java programming language are inherently easier to modify for another device than applications written in C or C++.

A second benefit of portability is the ease of delivering applications to a device over the wireless network (sometimes called Over-the-air, or OTA, provisioning). Binary applications can be moved from a server onto a device, too, but not safely. Because Java code runs inside the Java Virtual Machine¹, code that is downloaded from the network can be run safely. Binary code cannot be contained at execution time and is much less safe.

For more information on the motivations for using the Java platform for wireless development, select:

Why Java Technology for Wireless?

Perhaps the best next step toward getting a good grip on wireless Java technology is to create some:

Wireless Development Tutorial Part I
Learn how to set up a development environment for building J2ME client applications. You'll install the tools, then build and run a simple MIDlet. This article has all the information you need to get started with J2ME development.
Wireless Development Tutorial Part II
In this article, you'll learn how to set up a Java servlet development environment, either Tomcat or the J2EE Reference Implementation server. You'll write a servlet and create a MIDlet that makes a network connection to the servlet.

¹ As used in this document, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.