C H A P T E R 1

Introduction

Customers use mobile phones and other handheld devices for many tasks, such as making phone calls, taking photographs, playing games, organizing contact information, keeping a calendar of events, and accessing web sites. It is natural for them to want to do more than one of these tasks at a time. For example, a customer might not want to shut the address book to receive a flight-delay alert. The Java Wireless Client software, which can concurrently run multiple MIDlets, meets this need.

Device manufacturers and service providers also benefit from being able to run multiple MIDlets concurrently. This functionality enables them to write built-in (resident) applications, such as address books, in the Java programming language. Applications written in the Java programming language (Java applications) are easier to write and maintain, more portable, and easier to customize than those written in native code. The Java Wireless Client software meets this need too.

In addition, the Java Wireless Client software enables MIDlet writers to take advantage of multitasking without changing their code. MIDlet suites that run in the Java Wireless Client software's multitasking environment are no different from any other MIDlets: They have no new APIs and they have the same life cycle. The MIDP 2.1 Specification advises all MIDlet writers about managing resources when the MIDlet is paused and resumed. In a multitasking environment, a MIDlet might compete with other MIDlets for resources, so it is more important than ever for MIDlet writers to follow that advice and to use resources carefully.

Multitasking

The Connected Limited Device Configuration HotSpot trademark Implementation can run multiple Java applications within a single operating system (OS) process. Historically, a CLDC virtual machine (VM) could run one Java application at a time, and each virtual machine typically required its own OS process. Running more than one Java application meant running more than one OS process. This could use too many resources on some small devices. The multitasking feature enables a single virtual machine, in a single OS process, to function as multiple virtual machines. From the standpoint of each Java application, it is running in a separate virtual machine.

When a MIDlet exits or encounters an error, it always leaves the virtual machine in a consistent state. This works because each MIDlet is isolated from other MIDlets that might also be running at the same time. If the MIDlets were not isolated from each other, an error in one MIDlet might be visible to other MIDlets. This might result in deadlock or crashes caused by corrupted data structures.

Multitasking, then, runs multiple logical virtual machines within a single OS process. The CLDC HotSpot Implementation enables this by providing fundamental mechanisms in the virtual machine. Mechanisms include threads, the isolation of objects in the Java runtime environment (Java objects) belonging to different programs, and safe termination. See the CLDC HotSpot Implementation Virtual Machine White Paper at http://java.sun.com/j2me/docs/pdf/CLDC-HI_whitepaper-February_2005.pdf for more information.

The OS mechanisms are important and necessary, but they aren't sufficient to provide a complete application environment. A complete system needs mechanisms for managing the application life cycle (starting, stopping, and switching between applications) and for enabling the user to control the application life cycle. It also needs mechanisms for managing competition for limited shared resources, such as memory and network sockets, among multiple applications. The Java Wireless Client software provides all of these additional mechanisms.

The Java Wireless Client software is a high-performance, feature-rich, deployment-ready implementation of Java Technology for the Wireless Industry that takes advantage of the multitasking functionality in the CLDC HotSpot Implementation.

The logical virtual machines in the Java Wireless Client software are called tasks. Each application has its own task. The Application Management System (AMS) runs at all times in its own task. This architecture provides improved performance and robustness.

Robustness

In addition to providing the multitasking that users want, tasks have the following benefits:

Fault containment - If a Java application crashes, then any problems caused by this crash are limited to the task. Applications running in other tasks are unaffected.

Clean termination - When a Java application exits, it leaves the virtual machine in a consistent state. In the past, some have tried to run multiple Java applications in a single process by running the applications in separate threads within a single virtual machine. When applications share a virtual machine, it is impossible to guarantee that an application can exit cleanly, because objects might be left in an inconsistent state. In contrast, tasks can and do terminate cleanly.

Note that in MIDP, a Java application is a MIDlet suite. A MIDlet suite is one or more MIDlets in the same Java Archive (JAR) file. Each MIDlet suite, then, runs in its own task. The user interacts with one of the MIDlets in the MIDlet suite.

Mechanisms Compared With Policies

Mechanisms are actions that the system carries out, such as starting, pausing, and stopping a MIDlet. Policies are the system-wide decisions that device manufacturers and service providers make about when and how to use the available mechanisms. Policies take generic mechanisms and combine them into a predictable set of system behaviors.

The Java Wireless Client software provides both the necessary mechanisms for a complete application environment, such as mechanisms for managing competition for limited shared resources, and a default set of policies. For example, memory is a limited shared resource for which the Java Wireless Client software provides mechanisms and a few default policies. The mechanism is the allocation of heap memory. One default policy is to allow the applications to compete for available heap memory.

The default policies are useful, but device manufacturers and service providers are likely to need to tailor policies to their particular platforms. Devices of different capabilities might use different policies. Devices with different user interface styles might use different policies so that their Java applications interact with users in ways that match the native applications interactions. Because policy decisions are often intertwined with user interface style and user model decisions, the Java Wireless Client software enables the development of alternative policies.

Because policies are so device dependent, this book does not recommend specific policy combinations. As you determine the policies for your device, keep in mind that policies interact with each other and not all combinations of policies make sense. For example, if you have a policy to allow a MIDlet to access a sound device while it is in the background, it does not make sense to also have a policy to suspend a MIDlet's execution when it is in the background.