1.2.1.1 K-Virtual Machine

1.2.1.1 K-Virtual Machine

Sun’s original VM for CLDC was known as the KVM (which stood for Kauai Virtual Machine, sometimes also known as the Kilo Virtual Machine). The CLDC VM is, apart from a few differences which we shall

outline shortly, compliant with the Java Virtual Machine Specification and the Java Language Specification.

The libraries available are typically split into two categories: those defined by CLDC and those defined by a profile and its optional packages such as MMAPI and WMA. Figure 1.2 demonstrates at a high level how

these components fit together.So that the CLDC virtual machine can run within a small footprint and also to take into account additional security requirements for CLDC devices, CLDC differs from CDC in the following respects:

• no floating point support (although it has been added for CLDC

1.1) – this means that float and double numbers cannot be used and alternative means of storing these values have to be found, for example, ”string math”

• no finalization – the Object.finalize() method does not exist(Object.finalize() is used to carry out any tidying up that maybe needed when an object is collected by the garbage-collector.However, there is little, if any, practical need for this method.)

• limited error handling – only three error classes exist: java.lang.

Error, java.lang.OutOfMemory and java.lang.VirtualMachineError

• no Java Native Interface (JNI) – this is due to security concerns and

the overhead exerted by JNI on the device memory

• no user-defined class loaders – the built-in class loader cannot be

overridden, for security reasons

• no reflection

• no thread groups and daemon threads – although threading is available,

thread groups cannot be created (however, Thread arrays can

be created if a similar effect is required)

• no weak references, although these will be added to CLDC 1.1.

1.2 CLDC and MIDP

1.2 CLDC and MIDP

1.2.1 CLDC

A developer wishing to create applications for mobile devices may be tempted to ignore the full specification of CLDC. A developer may initially be interested in getting acquainted with MIDP as a standalone technology. It is, however, important to understand the underlying technology that forms MIDP.

The CLDC, as specified by Java Specification Request (JSR) 30 (http://jcp.org/en/jsr/detail?id=30), is the smaller of the two configurations and sets out to define a standard for devices with the following capabilities:

• 160 KB to 512 KB of total memory budget available for the Java

platform

• 16-bit or 32-bit processor

• low power consumption, often operating on battery power

• intermittent network connection, possibly wireless and limited to a

bandwidth of 9600 bps or less.

The 160 KB memory budget is derived from the minimum hardware

requirements, as follows:

• at least 128 KB of non-volatile memory available for the Java Virtual

Machine and CLDC libraries

• 32 KB of volatile memory for the Java runtime object memory.

CLDC itself defines the minimum required Java technology in terms of libraries and components for small-connected devices. Specifically, this addresses the Java language itself, the virtual machine definition, core

libraries, I/O capabilities, networking and security. Interestingly, from an early stage, one of the focuses for the CLDC definition was to recognize that much of the content for these devices would come from third-party developers. Another was that the idea of being able to create applications portable across a range of devices should be adhered to. This would provide an easier path to revenue generation and therefore  roliferate content for more devices. The nature of Java means that a programmer can create applications that use the device’s features without having to actually understand the working of the device. The developer only needs to comprehend the interface to the device. CLDC does not guarantee portability and it does not implement any optional features. Variants of devices within CLDC should be specified through profiles, rather than the configuration. It must be said that true application portability can only be obtained if a few principles are applied during the application design stage. We shall be looking at these issues later in this book.

1.1.3 Profiles

1.1.3 Profiles

Whereas a configuration provides the lowest common denominator for a group of devices, the profile adds an additional layer on top of theconfiguration providing APIs for a specific class of device. This creates

the ability for each configuration to be adapted and targeted towards vertical markets. That is to say, while some devices may appear to have similar functionality, they do in fact have different requirements in terms

of the available APIs and interfaces to their own hardware. Some mobile phones, for example, offer more memory, CPU speed or I/O interfaces than others and therefore might want to offer more in terms of an nterface between the programmer and the hardware. Currently, four Java Community Process profiles exist across the two J2ME configurations, but only one of those is a CLDC profile. However, an additional profile called ’DoJa’, defined by NTT DoCoMo, operates on the J2ME CLDC APIs and is used on i-mode devices. With only one JCP profile currently defined, a developer new to J2ME might ask themselves:

why is a profile required at all? Using the example of two-way pagers as a possible type of CLDC

device, it becomes easier to understand the need for another profile. We can see there are similarities between two-way pagers and mobilephones. Both usually connect intermittently over a wireless network,  both can communicate via text type messaging and, possibly, both may store a certain level of information, such as phone numbers. They will both also have a screen of some description. However, the user interface (UI) signals the beginning of the diversity between the two types of device. The method by which data input is captured and indeed displayed will be very different. Each device should have a UI in tune with its own capabilities. While both types of device are CLDC, each will require a separate profile so that the most appropriate APIs are available to the developer.

Mobile Information Device Profile (MIDP)

This profile offers the core functionality required by mobile applications, such as the user interface, network connectivity, local data storage and, importantly, application lifecycle management. As well as the reference

implementation for mobile phones and pagers, there is a second implementation that caters for the Palm OS. It is known as MIDP for Palm OS and it provides for the different user interface on such devices.

Information Module Profile (IMP)

This profile is based upon the MIDP 1.0 profile. IMP combined with CLDC provides a Java application environment targeted at resourceconstrained and embedded networked devices. These devices do not

have rich graphical user interfaces, but their relationship to MIDP 1.0 means that developer skills can be easily transferred to IMP.

Foundation Profile

This profile is the first of three, tiered CDC profiles. It provides a networkcapable implementation without a user interface. It can be combinedwith the Personal Profile and Personal Basis Profile when devices require

a UI.

Personal Profile

This profile is aimed at devices that require full GUI or Internet applet support, such as high-end PDAs or communicator-type devices. It provides a full Abstract Window Toolkit (AWT) library and offers web fidelity. It is capable of running web-based applets designed for the desktop environment.

Personal Basis Profile

This profile is a subset of the Personal Profile and provides a networkbased environment for network-connected devices that support a limited GUI or require specialized graphical interfaces. Devices include set-top boxes and in-vehicle systems. The Personal Basis Profile and Personal Profile have replaced PersonalJava technology and provide a clear migration path for PersonalJava applications to J2ME. Although Personal Information Management and Telephony APIs are not mandatory in this profile, replacements are being specified for J2ME use. Both the Personal Basis Profile and Personal Profile

are layered on top of the CDC and Foundation Profile.

1.1.2 Configurations

1.1.2 Configurations


So far we have examined the bigger Java picture and looked at how J2ME fits within that. We have also established that J2ME provides an environment for the development and execution of applications for
constrained devices. These devices cover a broad range of functionality and use: we may want to program devices that provide telemetry data from a vehicle, or create data applications for a TV set-top box; but we
might instead want to develop applications for mobile phones. These three examples show immediately why we might want to split J2ME into configurations. While an application sitting in a motor vehicle transmitting data back to a server has much in common with a gaming application transmitting high scores to a server,  ne thing that becomes apparent is the differential in power source available to both. One device
is able to draw on the car battery, whereas a mobile phone has to rely on a rechargeable battery. The requirements in the cost and size of the hardware are also different. This provides particular constraints on the capabilities of the processor and therefore the virtual machine within the device. While all these devices  ave common attributes, not all of them are the same. It is therefore necessary to provide a set of base classes
appropriate to each grouping of devices. A configuration consists of a combination of a virtual machine and a
minimal set of class libraries designed to provide the base functionality for a distinct set of devices with similar characteristics, such as network connectivity, processor power and memory. There are two such current configurations, defined as follows:

• Connected Device Configuration (CDC) This configuration is designed for devices with more memory, faster processors and greater network bandwidth. It is appropriate, at least in the near term,or home automation and automotive entertainment,
• navigation, and telemetry systems. A programming model closer to
• J2SE simplifies porting existing desktop clients for enterprise systems
• to mobile devices that support CDC.
• • Connected Limited Device Configuration (CLDC)
• This configuration is intended for devices with intermittent network
• connections, small processors and limited memory. Expected targets
• included two-way pagers, mobile phones and entry-level PDAs.
• However, in practice, the functionality delivered by CLDC and the
• associated profiles and optional packages is very close to that of CDC.
• As a consequence it is used today on most high-end mobile phones,
• or smartphones, which are replacing PDAs in the marketplace.

1.1 Configurations and Profiles

1.1 Configurations and Profiles
1.1.1 Architecture

J2ME is the newest and smallest addition to the Java family. It is the smaller brother of J2SE (Standard Edition) and the server-based J2EE (Enterprise Edition). As mentioned, J2ME provides a development environment for a range of small, constrained devices. Even though J2ME is targeted at devices with limited capabilities, it has been derived from J2SE and shows all the characteristics of the Java language. We have already introduced the concepts of configurations and profiles; the rest of this chapter will explain how and why these concepts have been derived and implemented.


Each combination of configuration and profile matches a group of products specifically optimized to match the memory, processing power and I/O capabilities of each device.


The full Java architecture can be seen in Figure 1.1. It shows how the technology has developed to offer a platform for a range of circumstances. Enterprise applications can be developed using the J2EE packages, taking full advantage of the power of large servers capable of transmitting large chunks of data across networks. The J2SE edition complements J2EE and provides the basis for desktop-type applications. Already we can see that these two versions of Java are defined with consideration of processor
power, memory and communication ability: it would be inefficient for the virtual machine running on a desktop machine (J2SE) to also include large packages targeted towards an enterprise application (J2EE).


Further inspection of the Java architecture reveals that there are two groups of special interest to us, under the banner of J2ME. J2ME provides an environment for developers wishing to develop applications for smaller devices. This environment has been specialized to cater for machines with even less capacity.

Programming Java 2Micro Edition on Symbian OS

Programming Java 2Micro Edition on Symbian OS

Introduction to J2ME

In order to understand how Java 2 Micro Edition (J2ME) lies within the wider Java landscape it is best to explore the overall Java architecture. J2ME has been developed primarily as a technology for the execution of applications on constrained devices. In this case, constrained devices are mobile phones, PDAs, TV set-top boxes, in-vehicle telemetry, residential gateways and other embedded devices. J2ME as a whole can be described as the technology that caters for all these devices. Given that many of them have limited resources, it would be imprudent to expect all of these devices to be able to deliver all of the functionality of the few. The Java community therefore decided that these devices should be grouped to best reflect their purpose and capabilities.

This would provide a lowest common denominator for each device

group and arrange them into configurations. To further differentiate these devices and to accommodate vertical markets within each configuration, profiles were created, refining the Java APIs for each device type. The following analyzes how J2ME is positioned within the Java architecture and how the J2ME configurations and profiles complement each other. It also describes the packages and classes within the commonly used environments, with special emphasis on MIDP 2.0.