J2ME
The Java 2 Platform, Micro Edition (or J2ME Platform) is one of the three Java 2
editions published by Sun Microsystems. You are probably more familiar with
Standard (J2SE) and Enterprise (J2EE), but Micro is rapidly gaining popularity
with vendors and developers.
Just as J2SE and J2EE comprise a set of tools and libraries,
so too does J2ME. However, J2ME's tools and libraries are targeted at a
different set of devices than its larger siblings. Everything from smart cards
and pagers to mobile phones, PDAs, and set-top television boxes are potential
targets. These information appliances span a wide range of functionality,
features, and capabilities.
To address this range of functions, J2ME has a layered
architecture that allows vendors and developers to maximize the capabilities of
the target device while still retaining some interoperability and platform
independence. Consider the differences between a set-top television box and
one-line pager:
| Set-Top Box
|
Pager
|
| Virtually unlimited
power supply
|
Battery powered
|
| Lots of memory
|
Very little memory |
| Relatively speedy
performance |
Slow performance
|
| Big monitor for user
interface (TV)
|
Single line of LCD
|
| Always – on
high bandwidth network
|
Low bandwidth
network |
| Persistent storage
|
Little persistent
storage |
We wouldn't want the libraries on the one-line pager to have
to include the class
javax.swing.tree.DefaultMutableTreeNode, but maybe we would want
it on the set-top box. To maximize the capabilities of both devices while still
using the same Java 2 edition, the following layered architecture was designed:
Some of these VMs may not fit into the J2ME-specified framework.
- Configuration layer: base classes that must be available to any profile (and application)
compliant with a particular configuration. For example, I/O classes, data types
and structures, and network connections are typically specified in this layer
- Device profile layer: classes built upon ones specified in the
configuration layer. GUI classes are specified here. Choosing a profile
dictates a configuration, as profiles are typically only available for one
configuration. Applications written for a particular profile are guaranteed to
work on any device that implements that profile
- Application layer:
this is your application code. Before writing an application, you must decide
upon what profile it will depend. Choosing a profile is an important step
because it breaks interoperability; your application is not guaranteed to work
on another profile. Just like any Java application, J2ME applications define
their own classes and have main() entry points. Applications make use of classes published by the profile and configuration layers
It's worth mentioning that there are a number of products
that allow applications written in Java to run on information appliance
operating systems without virtual machines. They work by compiling Java
bytecode into native operating system-dependent machine code. Some of these
products are compilers that are intended to compile during an off-line build
process, before application deployment. Others are complete VMs containing a
compiler that compile during or just before runtime (similar to just-in-time
and HotSpot).
Configurations
A configuration is a device
class. If we remember our set-top box and
pager comparison (see J2ME, page 571), these are
clearly two different classes of
devices. As such, they represent very different target platforms. The J2ME
engineers knew the Write-Once, Run-Anywhere model that made J2SE and J2EE so
successful wouldn't work for all classes of information appliances, so they
made a decision to break application interoperability when they defined configurations.
A configuration is a class of information appliance.
There are currently two configurations within J2ME:
"connected devices" (like set-top boxes) and "limited connected
devices" (like PDAs or pagers). Each focus has different qualities, so
they have their own definition of classes, which must be available to the VM.
These two focuses, or configurations, are named:
Sun provides reference implementations of these two
configurations, but other vendors have also implemented them along with their
own VMs.
In this chapter, we will concern ourselves primarily with
the CLDC.
CLDC
As stated before, each configuration defines and
implements a set of classes that must be available to the VM. The CLDC both
inherits classes from the J2SE and defines its own classes. Here is a partial
list of those classes inherited from the J2SE, many of which are subsets of
their original, reducing them only to their essentials:
java.lang.Object, java.lang.Runtime, java.lang.System, java.lang.Throwable, java.lang.Exception, java.lang.RuntimeException (and all its subclasses) java.lang.Boolean, java.lang.Byte, java.lang.Character, java.lang.Integer, java.lang.Short, java.lang.Void, java.lang.String, java.lang.StringBuffer, java.lang.Math, java.util.BitSet, java.util.Dictionary, java.util.Enumeration, java.util.Hashtable, java.util.Vector
Sun provides a reference implementation of the CLDC, which
includes the Java KVM. Other vendors are working on CLDC implementations that
hold great promise, such as IBM's VisualAge Micro Edition with the J9 virtual
machine.
Profiles
Profiles specify another set
of Java classes that must exist along with the classes made available by the
configuration to which the profile belongs. They are targeted at specific
industry segments. Together, a profile and its configuration specify a full set
of Java classes for a particular type of device. Applications written for a
particular profile are guaranteed to work on any device that implements that
profile.
An important point to note is that user interface components
are specified in profiles, not configurations. This is because the
configuration encompasses too broad a spectrum. For instance, a PDA and a pager
are both CLDC devices, but of what need is the CheckBox
class on a one-line pager?
User Interface components are specified in
profiles, whereas I/O, network connectivity, and data types are defined in
configurations.
There are hundreds of proposed profiles. Here are four examples. Note
that a profile defines the configuration on which it depends.
- PDA Profile for CLDC - defines user interface and data
storage APIs for small, resource-limited handheld devices (this profile is not
currently available). http://jcp.org/jsr/detail/075.jsp
- Mobile Information Device Profile for CLDC - defines user interface, data storage,
messaging, networking, security, and wireless telephony for mobile devices. http://jcp.org/jsr/detail/037.jsp
- Foundation Profile for CDC - defines a base profile for devices that have
1MB ROM, 512KB RAM, rich network connectivity, but no user interface. User
interfaces can be layered on top of this profile by defining another profile. http://jcp.org/jsr/detail/046.jsp
- Personal Profile for CDC - this profile/configuration combination actually defines the
successor to PersonalJava (http://java.sun.com/products/personaljava/).
Applications written to versions 1.1.x and 1.2 of the PersonalJava API
specification will work with this combination. It appears that PersonalJava will be absorbed into the J2ME framework under this
profile/configuration.
Java KVM
Part of Sun's reference
implementation of the CLDC, the Java Kilobyte Virtual Machine (KVM) was
designed to operate with as little as 160 to 512KB of total memory on 25MHz 16
or 32 bit RISC or CISC processors. It was written in C and is freely available
for four operating systems:
- Win32 (Windows 2000/NT/ME/98)
- Solaris
- Linux
- Palm OS
It's interesting to note that Java Native
Interface (JNI) calls cannot be made from Java code unless the native call was
linked into the KVM when it was compiled. The KVM source code is provided so
you can do this. The reason JNI calls cannot be made without this step is so
that the size of the KVM is kept to a minimum. Opening up native access to a
device allows for the execution of potentially hostile code unless security
mechanisms are put into place, such as exist in the Java 2 Standard Edition.
This would increase the footprint and complexity of the KVM. Its implementers
apparently weighed the tradeoffs and chose size over secure JNI capabilities.
Other VMs, such as the Kada VM,
do allow JNI calls.
We'll be focusing on the Palm OS build of the KVM for this
chapter since it's a good demonstration of the usability of the VM in a
constrained device.
Package com.sun.kjava: A KVM User Interface
Remember
that in the J2ME architecture, user interface and device-specific network
classes are defined at the profile level. However, the KVM for the Palm was
released at Sun's JavaOne conference in 1999 – before the CLDC was
released and a PDA profile was defined. Actually, to date, there still isn't an
implementation of the PDA Profile for the CLDC, just a Java Specification
Request.
As the 1999 KVM release for the Palm wouldn't have been very
interesting without including user interface classes, the package
com.sun.kjava.* was born. It includes:
- A set of simple user interface classes, such as com.sun.kjava.Button
- An event callback mechanism so events like penUp,
beamReceive,
and keyDown
can be handled by application code
- PDB (Palm database) access classes for file
input/output
- Data structure classes, such as com.sun.kjava.List
and com.sun.kjava.IntVector
The package com.sun.kjava is unsupported and
quite limited. Additionally, with the newer J2ME architecture, it doesn't
belong as part of the CLDC distribution (it is currently provided as an
"overlay" to the CLDC files – see Setting Up the
Environment, CLDC/Java KVM, page 640). It is
generally accepted that the package will be renamed (for example, com.palm.kjava),
rolled into the PDA profile, or incorporated into a Palm OS-specific profile.
REPORTS
ANALYTICS
Follow 
