GETTING STARTED

An Introduction to J2ME Platforms

Sun Microsystems has released several versions of Java, and they have maintained architectural
consistency
across the various versions. These versions of Java, which have been released in a series, have
improved
their capabilities by adding several new features to each version. However, after the release of
Java 1.2,
there has been a change in the way Java is packaged and licensed. This has led to the Java
platform being
split into three editions.
The three platforms of Java that address different computing environments are:

Java 2 Standard Edition (J2SE)

Java 2 Micro Edition (J2ME)

J2SE is primarily used to create Java applets and applications that are stand alone and Web-based.
Standard
Edition is a core collection of tools and APIs. J2EE was Java's answer to enterprise computing
wherein a
single application is scattered across a distributed network and accessed remotely. J2EE contains
all the
functionality of J2SE and focuses on server programming by using Enterprise Java Beans (EJB),
Servlets
and Java Server Pages (JSP), and Extensible Markup Language (XML).
J2ME focuses on the wireless computing environment, which has been an area of continuous
advancements. One of the major limitations of wireless computing has been the restriction on
hardware
resources of devices such as mobile phones, Personal Digital Assistants (PDAs), and other
electronic and
embedded devices. The Java 2 Micro Edition (J2ME), a modular and customized platform from
Sun,
J2ME derives most of its features from J2SE. Some of the features of J2ME are as follows.

Portability

Built-in consistency across products

Security over the network

Compatibility with J2SE and J2EE platforms

J2ME and WAP

Another approach to the development of wireless applications is through Wireless Application
Protocol
(WAP). WAP is a specification that adapts several data-handling techniques used by Web protocols
TCP/IP and UDP. The development of WAP applications is relatively simple because it reuses
Web technologies. WAP was not designed for use with HTML, although many of the WAP
gateways can
Servlets and Java Server Pages (JSP) or Wireless Markup Language (WML). Although WAP and J2ME
are
complementary technologies, they operate in different ways. In the case of WAP, the mobile
device runs a
browser that accesses Intranet or Internet applications. The mobile device does not contain any
other
application. On the other hand, J2ME applications reside on the mobile device and these
applications are available to users even if the device is not connected to a network.

The Architecture of J2ME

J2ME consists of two major components, profiles and configurations. A profile is a
specification of a set of Java APIs fora particular catego ry of handheld devices. It also
includes the specification of Java Virtual Machine that is required for running applications
in a particular device. There are various types of profiles, such as Mobile Information Device
Profile (MIDP), Foundation Profile, and PDA Profile.
Configuration, on the other hand, specifies the basic J2ME run-time environment. It also
includes a collection of classes from J2SE. Profiles are implemented on configurations. The
two currently available configurations are:
Connected Device Configuration (CDC)
Connected Limited Device Configuration (CLDC)

The J2ME Architecture

CDC
CDC is mainly used for high-end consumer devices with network connectivity. These
devices include set-top boxes, Internet TVs, and automobile navigation systems.
NOTE:
A set-top box is a device that enables a television set to act as a user interface to the Internet and also to
receive Digital Television (DTV) broadcasts.

This configuration includes a wide range of Java libraries and a comprehensive collection of virtual
machine features. CDC supports the following Java packages:
Package

Description

java.net

Networking classes and interfaces

java.util

Standard utility classes

java.udl.zio

Zip utility classes

java.util.jar

Java Archive (JAR) utility classes

ja va. Io

Standard 1/0 classes and interfaces

ja va. Text

The text package

java.security

Security classes and interfaces

java.security.cert

Security Certificate classes

java.math

The math package

java.lang

Virtual machine classes

Java.lang.ref

Reference classes

Java. lang. reflect

Reflection classes and interfaces

Java. microedition. io

Generic connection framework classes and interfaces

Note
A J2ME application cannot access customized
packages.
CLDC
CLDC, on the other hand, handles devices that are less powerful than high-end consumer devices. Some of
the commonly used devices that use CLDC are mobile phones, personal organizers, and pagers. CLDC is a
subset of CDC. In addition to some of the J2SE classes, CLDC includes some new classes that are specifically
used for low-end consumer devices. CLDC specifies the basic set of libraries and virtual machine features for
running J2ME applications. Java has launched a new virtual machine named Kilobyte Virtual Machine
(KVM) for implementing the CLDC specifications. KVM is derived from JVM and is written in C
programming language. KVM also specifies several optional features that can be used depending upon the type
and capabilities of a mobile device. CLDC, along with KVM, forms a part of the new J2ME run-time
environment.

A Pictorial Representation of CDC and CLDC

CLDC Library APIs
ME APIs are not suitable for handheld devices because they require large memory.
Therefore, all the ME APIs are not included in CLDC library APIs. The various categories of
CLDC library APIs are as follows:
The CLDC library contains classes that are subsets of ME APIs. These J2SE-specific
classes are located in the j ava. 1 ang, j ava . io, and j ava . ut i 1 packages. The
following table lists some of the inherited classes from these packages.
Package

java.lang

Classes
Class, Long, Runnable, Thread, ArithmeticException,
ArraylndexOutOfBoundException, ArrayStoreException,
ClassCastException,
ClassNotFoundException, Error, IllegalAccessException,
IllegalArgumentException,
IllegalMonitorStateException, IllegalThreadStateException,
IndexOutOfBoundException, Instantiation Exception,

ja va. io

ja va. util

ByteArraylnputStream, ByteArrayOutputStream, Datalnput,

DataOutput,
DatalnputStream, Data OutputStream, InputStream,
OutputStream,
InputStreamReader, OutputStream Writer, PrintStream, Reader,
Calendar, Date, Random, Stack, TimeZone,
EmptyStackException,

The CLDC library contains several new interfaces and classes that are specific to
CLDC. These form a part of the j avax . microedit i on . io package, which is used
in J2ME to support the networking capabilities of CLDC. The following table lists these
classes.
Package

Classes

Javax.microedition.i
o

Connection, ConnectionNotFoundException, Connector,

ContentConnector, Datagram, DatagramConnection,
InputConnection, OutputConnection, StreamConnection,
StreamConnectionNotifier

Core APIS in J2ME

The core APIs in J2ME includes several classes from packages such as java.lang and
java.util. All these APIs are used by different configurations and, therefore, these APIs
should be supported by all virtual machines including KVM. The following table lists
various classes available in the core APIs used in J2ME.

Package

Classes

java.lang

Object, Runtime, System, Throwable, Exception,

RuntimeException, Boolean, Byte, Integer, Character,
Short, Void, String, StringBuffer, and Math

java.util

BitSet, Dictionary, Enumeration, Hashtable, and Vector

NOTE:
In some cases, the J2SE packages are used as is in J2ME, for example, the java.util and java.io packages. However,
due to resource constraints, only a sub set of certain J2SE packages, such as java.lang is used. Some of the
packages, such as the microedition package are completely rewritten for J2ME.4
.
Mobile Information Device Profile (MIDP)
MIDP contains additional libraries that provide Java APIs that interact with the user interface and database. In
addition, these Java APIs address issues such as application life cycle and device-specific networking. You can use
APIs available under MIDP to create a variety of applications, such as consumer applications and games. MIDP
applications are known as MIDlets.
The following table describes the various MIDP packages.
MIDP PACKAGE
ja vax. microedition.
lcdui

DESCRIPTION
User interface classes and interfaces

javax.microedition. rms Record Management System classes

ja vax. microedition.
MIDP application definition support classes
midlet

javax.microedition.io

MIDP generic connection framework classes and interfaces

java.lang

Virtual machine classes and interfaces

java.util

Standard utility classes and interfaces

Note
The PDA profile, which belongs to the category of mobile information devices, is still in its construction stage.
MIDP is used in mobile information devices, such as mobile phones and pagers, which have the following
characteristics:

A minimum screen size of 96 x 54 pixels

1 -bit display depth

Input devices, such as keyboards or touch screens

A minimum of 128 KB nonvolatile memory for MIDP components

Two-way wireless connectivity

In addition, MIDP runs on low-end processors and creates minimum garbage. In J2ME, CLDC combines
with MIDP to forma comprehensive run-time environment. The interface for system-level services is provided by
the configuration, CLDC, and the interface for application-level services is provided by the profile, MIDP.

A Pictorial Representation of the Three Java Platform's

You can control the display of a pixel by specifying the color or gray-scale using bits. A one-bit display
means that a single bit is used for one pixel.
J2ME WIRELESS TOOLKIT

The J2EE and J2SE platforms are used to create applications that run on high speed, and
large memory devices. Java applications written for such devices are compiled by JVM
that uses large memory. However, KVM takes up lesser memory but is severely restricted
in its capabilities compared to JVM. Any virtual machine in a mobile application must be
able to identify and reject invalid class files. One of the restrictions of KVM is that it
cannot perform class file verifications. These verifications are required to filter the class
files that do not belong to the CLDC configuration. Therefore, a mechanism is needed to
perform the class file verifications outside KVM and this is accomplished by J2ME
Wireless Toolkit. This toolkit is a set of tools from Sun that is used to build and test MIDlets.
After a MIDlet is created, it has to be tested to ensure that the application runs successfully. If
the MIDlet is developed to run in different mobile devices, it needs to be tested in each of

these devices. J2ME Wireless Toolkit provides a mechanism to simulate these

environments and test the application. These simulated tests eliminate the possibility of a
MIDlet malfunctioning in a particular device.

The Structure of J2ME Wireless Toolkit

The J2ME Wireless Toolkit consists of two components:

Bytecode verifier

J2ME emulator

In addition, certain J2ME Wireless toolkits, such as SDK for J2ME, released by Motorola
also contain an additional component known as Configuration editor.
The Bytecode Verifier
As mentioned earlier, a J2ME MIDlet must conform to the CLDC configuration. J2ME
does not support all class files available in J2SE. CLDC configuration further limits the
usage of these class files. In such a scenario, the virtual machine must be able to locate
and reject all invalid class files from a MIDlet and retain only the valid ones. KVM
cannot perform these tasks. Therefore, a bytecode verifier is used for this purpose. This
process of filtering invalid classes is known as pre-verification. The pre-verification
process is carried out during the development phase of a MIDlet. The verified MIDlet is
then ready to be loaded as an application. The advantage of having a bytecode verifier is
that it reduces the workload of KVM. This enables KVM to concentrate entirely on the
compilation process without having to check for invalid class files. To summarize, the
bytecode verifier:

Is used to locate and reject all invalid class files from a MIDlet and retain
only the valid ones. This process of filtering invalid classes is known as
pre-verification.

Reduces the workload of KVM and enables KVM to concentrate entirely

on the compilation process without having to check for invalid class files.

In the pre-verification process the .class file is converted to a .jar file.

After the MIDlet is compiled, it is stored with a .class extension similar to a Java
bytecode file. The next step is the pre-verification process, after which the . class file is
converted to a .jar file.

The Pre-verification Process

In addition to the MIDlet classes and other support classes, a MIDlet JAR file
contains the following elements:

MIDlets: The MIDlet class files.

Manifest file: Also called application descriptor, this file describes the
MIDlets, such as name of MIDlet, vendor name, and so on. This file is
saved with the extension jad.

Other resources: These resources include image files and sound files that are used
by the MIDlets.

A single JAR file might contain more than one MIDlet. A number of MIDlets together
forma MIDlet suite. The application descriptor provides information needed to access a
particular MIDlet from a suite. This application descriptor is stored as a .j ad file within a
JAR file. The other resources stored in a JAR file include sound and image files.
The J2ME Emulator
Before a MIDlet is ready to be deployed, it has to be tested in real-life conditions. This
involves testing a MIDlet within each device for which it is created. The J2ME emulator
is used to perform this test. The emulator provides an efficient simulated environment to
test the code on a PC. When the simulation is carried out, the image of the device
appears on the screen and the application executes exactly as it would execute in that
particular device. The user can interact with the device by using the mouse to click the
various buttons available on the device.
J2ME Wireless Toolkit is capable of simulating the environments of the following devices:
DefaultColorPhone
DefaultGrayPhone
Motorola i85s
PaImOSDevice
FJMavaHand-held
A J2ME emulator offers the following advantages:

Helps you run a MIDlet repeatedly in a simulated environment until the errors are
fixed

Provides a single interface on which you can test run the MIDlets on different
devices

Analyzes specific aspects of a MIDlet, such as garbage collection and loading of

class files

Although you might consider the J2ME emulator as a complete solution provider, it has
certain limitations. There area few characteristics of MIDlets that an emulator cannot test and
verify with absolute accuracy.
These limitations include:

Execution speed

Memory availability

A MIDlet is created to run in various devices, each with its own processor speed. Therefore, it is desirable
to have an emulator that tests the MIDlets in various speeds. Unfortunately, this is not possible with the
current version of J2ME Wireless Toolkit.
The same holds true for testing the memory available for MIDlets in various
devices. Memory availability determines how well an application runs within a
device. It is not possible to test run a MIDlet in an emulator by varying the
available memory.
Another limitation of the emulator is its inability to simulate the working of
the application manager that resides on every mobile device. The
application manager is responsible for adding, removing, and executing
the MIDlets within a mobile device. The emulator cannot simulate the
working of an application manager. Therefore, it cannot determine exactly how
these MIDlets are managed within a device.
The Configuration Editor
The Configuration editor helps a user configure the device environment. It
means that the user can alter the various profiles available within a device.
For example, the user can modify the device image, screen size, and buttons
available in a device. In this way, the editor provides a mechanism for the user to
control the simulated environment.
Note
The configuration editor is not available with the standard J2ME Wireless Toolkit released
by Sun. However, this standard toolkit enables a user to configure the device environment.
It is available in the SDK for J2ME released by Motorola.

The Testing Environments in J2ME

J2ME provides two types of testing environments:
0 Command line environment
6 Visual environment
The Command Line Environment
This is a simple environment wherein a user types in commands to perform a required
task. This is similar to the earlier versions of Java where coding takes place in a text
editor and compilation is performed by using command line statements.
The Visual Environment
In addition to the command line environment, J2ME Wireless Toolkit also provides a visual
platform to compile and test run MIDlets. It provides a user-friendly GUI that considerably
reduces the task of a developer in building and testing the MIDlets. Presently, the following
visual environments are available in J2ME:

KToolbar

9 Forte for Java

CodeWarrior for Java

Jbuilder Handheld Express

Note
You will learn more about the KToolbar environment because you will be building most of your
applications in this environment.

KToolbar
KToolbar provides a simple visual environment to test run MIDlets. It has limited features compared
to those offered by Forte for Java, the latest visual environment from Sun Microsystems. It manages
source code files effectively and automates the building process of MIDlets. However, it does not have an
editor of its own. Therefore, code has to be written in a text editor outside the KToolbar environment.
KToolbar provides all the utilities required to perform pre-verification and emulation of code.

Note
KToolbar is available with J2ME Wireless Toolkit and is automatically installed with the toolkit. To open
KToolbar, select Start, Programs, J2ME Wireless Toolkit 1.0.3, KToolbar.

SUMMARY

In this lesson, you learned that:

The three platforms available in Java are:

Java 2 Standard Edition (J2SE)

Java 2 Enterprise Edition (J2SE)

Java 2 Micro Edition (J2ME)

J2ME is used for small handheld devices, such as mobile phones, pagers, and PDAs, which have major
hardware constraints.

J2ME architecture consists of profiles and configurations.

A Profile is a specification of a set of Java APIs for a particular category of

handheld device.

Configuration is a specification of the basic J2ME run-time environment

The two types of configurations in J2ME platform are CDC and CLDC.
There are various categories of CLDC library APIs, such as classes that are a subset of J2SE and classes
that are specific to CLDC.
CLDC, along with KVM, combines with MIDP to form the run-time environment for a J2ME
application.
The structure of J2ME Mobile Toolkit consists of the bytecode verifier and J2ME emulator.
The bytecode verifier performs checks to ensure that invalid class files are not

present in a MIDlet.

The J2ME emulator simulates different environments of various

mobile devices and helps to test run MIDlets.

There are two testing environments in J2ME:

The command line environment
The visual environment

KToolbar provides a user-friendly visual testing environment for J2ME applications.