Download Java 2 Platform, Micro Edition (J2ME)

Java 2 Platform, Micro Edition (J2ME)
By Xiaorong Wang, 04/20/2001
For CS 616
INTRUDUCTION
Realizing that “one size doesn't fit all”, Sun Microsystems has regrouped its Java
technologies into three editions: Micro Edition (J2ME), Standard Edition (J2SE), and
Enterprise Edition (J2EE). Each edition has tools and supplies for developers to use with
a particular product:

Java virtual machines that fit inside the range of consumer devices

A library of APIs that are specialized for each type of device

Tools for deployment and device configuration

A profile (a specification of the minimum set of APIs) useful for a particular kind
of consumer device (set-top, screenphone, wireless, car, and digital assistant) and
a specification of the Java virtual machine functions required to support those
APIs
Java 2 Micro Edition (J2ME) is Sun’s version of Java aimed at machines with limited
hardware resources, including limited screen size, memory, and processing power. These
consumer devices cover the range of extremely tiny commodities such as smart cards or a
pager all the way up to the set-top box, an appliance almost as powerful as a computer.
Like the other editions, the J2ME platform maintains the qualities that Java technology
has become famous for:

Built-in consistency across products in terms of running anywhere, any time, over
any device

Portability of the code

Leveraging of the same Java programming language

Safe network delivery

Applications written with J2ME technology are upwardly scalable to work with
the J2SE and J2EE platforms
With the delivery of the J2ME platform, Sun provides a complete, end-to-end
solution for creating state-of-the-art networked products and applications for the
consumer and embedded market. J2ME technology enables device manufacturers, service
providers, and content creators to gain a competitive advantage and capitalize on new
revenue streams by rapidly and cost-effectively developing and deploying compelling
new applications and services to their customers worldwide.
CONFIGURATION and PROFILE
Java 2 Micro Edition (J2ME) encompasses VMs and core APIs specified via
Configurations as well as vertical – or market-specific – APIs specified in Profiles. In
this section, I will briefly introduce configurations and profiles in J2ME, in the following
sections I will go into details about CDLC configuration and MIDP profile.
A configuration defines the minimum Java technology libraries and virtual
machine capabilities that an application developer/content provider can expect to be
available on implementing devices. Each configuration addresses a particular class of
consumer electronics and embedded devices, which have similar requirements of
memory size and processing capabilities.
Sun introduced two configurations:

Connected limited device configuration (CLDC) – This configuration defines
Java APIs and technologies that support, as Sun documentation states, “devices
that you hold in your hand”. The Palm series of handheld devices are examples in
this area.

Connected device configuration (CDC) – This configuration defines APIs and
technologies that support, as Sun documentation puts it, “devices that you plug
into the wall.” A good example of such a device is a set-top box. (A set-top box is
a device that enables a television set to become a user interface to the internet and
also enables a television set to receive and decode digital television broadcasts.)
These two configurations differ in the capabilities of the devices they address. A
CLDC device has a processor of limited power (in comparison to a desktop system) and a
memory between 160KB and 512KB. On the other hand, a CDC system could support a
32- or 64-bit processor, with a memory above 512K. Because of the differences in
hardware capacities, each configuration is supported by a different virtual machine. A
CDC-based system uses a full-blown VM, while a CLDC-based system uses the KVM
(which I will describe later).
Each configuration represents a low-level, foundational API. On top of the
foundations are the profiles. A profile is a collection of Java technology-base APIs that
supplement a Configuration to provide capabilities for a specific vertical market or device
type. A profile is a complete environment. An application written to execute on a profile
needs no additional supporting classes. Figure 1. shows the two configurations and some
profiles in J2ME.
Figure 1. The Architecture of Configuration and Profiles
CLDC and MIDP
Overview
J2ME Platform Connected, Limited Device Configuration (CLDC) specifies the
core APIs and virtual machine features required to support Java technology on small
mobile devices such as cellular phones, two-way pagers, PDAs, organizers, and home
appliances. These CLDC targeted devices have the following characteristics:

160KB to 512KB total memory available for Java technology

Limited power (often battery)

Connectivity to some kind of network, often with a wireless, intermittent
connection and with limited (often 9600 bps or less) bandwidth

Extremely constrained UIs, small screens
CLDC 1.0 specification now is available for free download from Sun
Microsystems (http://java.sun.com/products/cldc/). The reference implementation of the
CLDC uses the K Virtual Machine (KVM).
A configuration (for example, CLDC) is designed to run with a profile. The
Mobile Information Device Profile (MIDP) is a specification that provides a core set of
libraries for writing Java applications targeted for mobile devices implementing J2ME
CLDC. A profile defines the libraries that are used by developers to write applications for
a specific device or for range of devices. MIDP defines classes for creating user
interfaces (textboxes, forms, etc), handling user input, and communicating over a
network with HTTP. MIDP 1.0 spec and implementation are available for download from
Sun Microsystems (http://java.sun.com/products/midp/).
A MIDlet is a Java application that conforms to the specifications set out by
CLDC and MIDP, and runs in a mobile information device. Figure 2. shows the detailed
architecture of CLDC and MIDP.
KVM
KVM is the minimal Virtual Machine for the J2ME platform and is the VM of
choice for the CLDC configuration. But J2ME applications are not restricted to the
KVM, J2ME technology can use any virtual machine that is at least as capable as the
KVM.
The KVM was not a modification of an existing VM, it was written from scratch
in C to address the fact that KVM-based devices would have cramped memory spaces
and limited processor power. This permitted the engineers to incorporate optimizations
that would otherwise not have been possible. In addition, the KVM is modular. It is built
so that features that are not needed for a particular target implementation can be easily
excised. Such optional features include: large datatypes (long, float, and double),
multidimensional arrays, classfile verification, and more. The KVM’s native interface
was built for portability, so task switching within KVM does not depend on hardwaregenerated timer interrupts and is therefore not preemptive in that sense.
An optional attendant to the KVM is the Java Application Manager (JAM), see
Figure 2. JAM’s role is to handle the details of downloading, installing, executing, and
uninstalling applications on those CLDC devices that are so resource constrained that
such functions don’t exist. JAM also handles updating an installed application. It even
sees to it that if the update process fails, the old, not updated application is still available.
CLDC Details
Connected Limited Device Configuration (CLDC) specification specifies VM
features required of CLDC implementation in terms of additions to and deviations from
the Java Virtual Machine Specification. CLDC specifies requirement for interfaces and
APIs for the following:

Input/output, Networking

Security model

Internationalization features
The general goal of CLDC is: full java programming language and virtual machine
specification compatibility. There is only language-level exception: floating point is not
supported in CLDC 1.0. There is no hardware floating point support on most devices due
to space limitations. However, manufacturers and developers may choose to include their
own floating point.
The CLDC VM implementation has the following differences:

No Java Native Interface (JNI)

No reflection

No thread groups

No weak references

No finalization

New implementation of bytecode verification using preverifier and bytecode
annotations
Due to the limited resource of the devices upon which the MIDP/CLDC APIs will
run, some Java functionality has been removed or modified from the specification. CLDC
libraries include:

Classes inherited from Java 2 Standard Edition (J2SE) are in packages:
 java.lang.*
 java.util.*
 java.io.*

New classes introduced by CLDC are in package:
 javax.microedition.*
CLDC libraries have limited support for the translation of Unicode characters to
and from a sequence of bytes. By default, the only character encoding for which a
converter is provided in ISO-LATIN1.
MIDP Details
The primary goals of the MIDP specification are:

Size: MIDP implementation must fit in small memory (as little as 128 KB ROM)

Efficiency: 1. Must run on low-end microprocessors. 2. Must run with limited
heap size (32-200KB RAM). 3. Minimal creation of garbage.

Time to market is critical for manufacturers of Mobile Information Devices
MIDP libraries specify APIs for: Persistent storage (lightweight record oriented
database), Networking (implement HTTP protocol), Timer (handles queuing and
delivery), and User Interface.
New classes introduced by MIDP are in packages:
 Javax.microedition.rms.*
 Javax.microedition.midlet.*
 Javax.microedition.io.*
 Javax.microedition.lcdui.*
PROGRAMMING WITH CLDC/MIDP
Programming Steps
As shown in Figure 3., the steps to program with CLDC/MIDP are:
1. Edit source code (MIDP application – MIDlets)
2. Compile the Java code
3. Run the classes through the preverify tool
4. Put all the verified classfiles and the resource files in a JAR file
5. Use emulator to test run programs
6. Download the application to devices
Example Code
Below is a simple MIDlet example: HelloMidlet.java.
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloMidlet extends MIDlet implements CommandListener
{
// Initialize the Midlet Display variable
private Display midletDisplay;
// Initialize a variable for the doneCommand
private Command doneCommand;
public HelloMidlet()
{
// Retrieve the display from the static display object
midletDisplay = Display.getDisplay(this);
// Initialize the doneCommand
doneCommand = new Command("DONE", Command.SCREEN, 1);
}
/* Create the Hello Midlet World TextBox and associate
* the exit command and listener.
*/
public void startApp()
{
// Create the TextBox containing the "Hello Midlet World!!" message
TextBox textBox =new TextBox("Hello Midlet","Hello Midlet World!!",256,0);
// Add the done Command to the TextBox
textBox.addCommand(doneCommand);
// Set the command listener for the textBox to the current midlet
textBox.setCommandListener( (CommandListener) this);
// Set the current display of the midlet to the textBox screen
midletDisplay.setCurrent(textBox);
}
/* PauseApp is used to suspend background activities and release
* resources on the device when the midlet is not active.
*/
public void pauseApp()
{
}
/* DestroyApp is used to stop background activities and release resources
* on the device when the midlet is at the end of its life cycle.
*/
public void destroyApp(boolean unconditional)
{
}
/* The commandAction method is implemented by this midlet to satisfy
* the CommandListener interface and handle the done action.
*/
public void commandAction(Command command, Displayable screen)
{
// If the command is the doneCommand
if (command == doneCommand)
{
// Call the destroyApp method
destroyApp(false);
// Notify the midlet platform that the midlet has completed
notifyDestroyed();
}
}
}
Life Cycle of MIDlet
The third line in the above program:
public class HelloMidlet extends MIDlet implements CommandListener
declares the HelloMidlet class to extend the MIDlet class and implement the
CommandListener interface. Each midlet must extend the abstract MIDlet class, which
contains three methods that each midlet must override to complete its life cycle. As
shown in Figure 4., the three methods are:
Method Name
Method Purpose
startApp
To allocate desired system resources and initialize the application.
pauseApp
To temporarily suspend resource-intensive processes.
destroyApp
To release resources used by the midlet and dispose of the midlet.
Developing Tools – J2ME Wireless Toolkit
Now we have a MIDlet program. Before we can run it, we need to download the
required software: the Java Developer’s Kit (JDK, version 1.3.0 or higher), Connected,
Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP).
The reason that you need to have JDK is : neither the CLDC or MIDP includes the Java
compiler (javac.exe) as part of their respective installation.
You can download CLDC and MIDP from Sun’s sites separately, or you can
download the Java 2 Micro Edition Wireless Toolkit
(http://java.sun.com/products/j2mewtoolkit/) from Sun Microsystem. J2ME Wireless
Toolkit provides a comprehensive toolset for MIDlet development. It simplified the
development of MIDlets. Currently, this toolkit has two limitations. First, it will only run
in the Windows environment. Second, the installation directory name must not contain
any spaces due to the internal build process used by the tool. Nevertheless, I found the
J2ME Wireless Toolkit is easy to use, so I will talk about how to program MIDlet using
this toolkit.
I downloaded the J2ME Wireless Toolkit 1.0.1, and installed under directory
J2mewtk. The following directory structure is created in my J2mewtk directory.
Directory
Purpose
J2mewtk/apps
Holds the files related to the individual projects. All source,
resources, and configuration files will be contained here. In
addition, these directories contain the products of the build
process run by the toolkit.
J2mewtk/bin
Holds the bin files used to preverify and build the application
code for the midlet environment.
J2mewtk/lib/midpapi.zip
Contains the classes used for the CLDC and MIDP APIs.
J2mewtk/docs
Contains the API Javadoc files and the MIDP UserGuide pdf
file.
Using the KToolbar
You can launch the KToolbar either from the command line or from the Start
menu item created during the J2ME Wireless Toolkit installation process. The KToolbar
window is shown in Figure 5.
Figure 5. KToolbar of the J2ME Wireless Toolkit 1.0.1.
To create a project, click on the “New Project…” button on KToolbar, a dialog
box will appear as shown in Figure 5. For the HelloMidilet program in the Example code,
type “HelloMidlet” for both the ProjectName and MIDlet Class Name (Figure 5). Click
the Create Project button after entering the information, the toolkit will create a project
named “HelloMidlet”, and save it in the directory J2mewtk/apps.
The project files are organized in the following structure:
Directory
Description
J2mewtk/apps/HelloMidlet
Holds all the source, resource and binary files of the
HelloMidlet project
J2mewtk/apps/HelloMidlet/src
All the sources of the project
J2mewtk/apps/HelloMidlet/res
All the resource files of the project
J2mewtk/apps/HelloMidlet/bin
The Jar file, the application descriptor file and the
unpacked manifest file.
So I put HelloMidlet.java file in J2mewtk/apps/HelloMidlet/src.
To configure the project, click on the Settings button from the KToolbar, and a
window shown in Figure 6 will allow you to change the MIDlet attributes.
Figure 6. MIDlet settings.
Building the MIDlet
The build tool provided by the J2ME Wireless Toolkit will compile, preverify,
and package the project in one continuous operation. To build the project, click on the
Build button on KToolbar (Figure 5). As a result of the build process, a jar file will
contain all the preverified classes needed to deploy the application to the device and the
project’s jad file. The jad (Java Application Descriptor) file contains all the information
about the midlet, its property names, and its associated properties’ values.
All the steps of the building process are:
1. Create the classes and tmpclasses directories for build process
2. Compile the Java source files into the tmpclasses directory
3. Preverify the classfiles contained in tmpclasses and output to classes directory
4. Jar up the verified classfiles
5. Jar up the resource files
6. Create a reminder to update the jar file size in the jad file
So why do we need to preverify the compiled class files? This process ensures
that the classfiles do not attempt any of the invalid operations. In addition, it is beneficial
to perform some steps of the standard virtual machine on a more capable computer rather
than leave them to the device’s KVM. The KVM was designed to fit within 1K. It has
been optimized for processing on the devices, not basic duties that can be outsourced
through preverification.
Running the MIDlet
J2ME Wireless Toolkit can also handle running the midlet through emulators.
Once a project is loaded (either by opening an existing project, or after building a new
project), the Run button on the KToolbar will be active. The toolkit provides four
different emulators for the devices you intend to test:

DefaultColorPhone: A color version of the default phone

DefaultGrayPhone: The default phone

MinimumPhone: A very basic emulator

Pager: A two-way pager
After you select the device, click the Run button to launch the emulator. Figure 7. shows
the output of HelloMidlet on three of the devices after I run the HelloMidlet project.
Figure 7. Output of HelloMidlet project.
SUMMARY
The J2ME platform is built upon the Java programming language to provide the
maximum functionality available on the resource-limited device. A subset of the base
functionality is provided along with some specialized classes.
A MIDlet is a Java application that conforms to the specifications set out by the
Connected, Limited Device Configuration (CLDC) and the Mobile Information Device
Profile (MIDP). MIDlets are targeted at mobile devices that provide some level of
network connectivity and have limited memory, processing power, and screen size.
Typical devices include cellular phones and pagers.
Some of the companies that making J2ME-related products:

Research In Motion (RIM): Blackberry two-way handhelds

Lucky Goldstar: J2ME-based CDMA mobile phones

Sega: Personal Java for Dreamcast consoles

Nokia: EPOC-based mobile phones

Sony: Mobile phones

American Express: Java Card for its Blue credit cards

NEXTEL just released two Java-powered mobile phones: i85s and i50sx
Resources:

http://java.sum.com/j2me

http://www.javaworld.com

Develop wireless applications using J2ME
http://www.javaworld.com/javaone00/j1-00-j2me.html

What J2ME Is and What It Isn’t
http://www.devx.com/upload/free/features/javapro/2000/13iss00/rg0013p.asp

Device programming with MIDP
http://javaworld.com/javaworld/jw-01-2001/jw-0105-midp_p.html

Java 2 ME and MIDP Development http://www.onjava.com/lpt/a/697