J2ME Building Blocks For Mobile Devices: White Paper On KVM and The Connected, Limited Device Configuration (CLDC)
J2ME Building Blocks For Mobile Devices: White Paper On KVM and The Connected, Limited Device Configuration (CLDC)
Mobile Devices
All rights reserved. Copyright in this document is owned by Sun Microsystems, Inc.
Sun Microsystems, Inc. (SUN) hereby grants to you at no charge a nonexclusive, nontransferable,
worldwide, limited license (without the right to sublicense) under SUN's intellectual property rights that are
essential to practice the Java 2 Platform Micro Edition, K Virtual Machine (KVM) or J2ME CLDC Reference
Implementation technologies to use this document for internal evaluation purposes only. Other than this
limited license, you acquire no right, title, or interest in or to the document and you shall have no right to
use the document for productive or commercial use.
Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87)
and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-1(a).
TRADEMARKS
Sun, Sun Microsystems, the Sun logo, Java, PersonalJava, Java Card, Jini, JDK, and Java Embedded Server
are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
THIS PUBLICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
1. Executive Summary 1
Information Appliances and the Wireless Revolution 1
Everything Connected 1
Customizable, Personal Services 2
Java™ 2 Platform Micro Edition (J2ME™) 4
J2ME Configurations and Profiles 4
Connected, Limited Device Configuration (CLDC) 7
The K Virtual Machine 7
About this White Paper 7
Contents iii
CLDC Scope 20
Security 21
Adherence to the Java Language Specification 21
Adherence to the Java Virtual Machine Specification 22
Classfile Verification 22
Classfile Format 23
CLDC Libraries 24
Classes Inherited from J2SE 24
System Classes 24
Collection Classes 24
I/O Classes 25
Exception Classes 25
Error Classes 26
Limitations 26
CLDC-Specific Classes 26
General Form 26
Examples 27
5. Future Directions 35
Contents v
vi J2ME Building Blocks for Mobile Devices • May 19, 2000
1
Executive Summary
Everything Connected
We anticipate that within the next two to five years, the majority of new
information appliances will be connected to the Internet. This will lead to a
radical change in the way people perceive and use these devices. The users of
the information appliances will want to access information—Web content,
enterprise data, and personal data—conveniently from anywhere, any time,
and from a variety of devices (Figure 1-1).
1
1
Internet
Several wireless device manufacturers are already working on cell phones that
allow the users to download new applications such as interactive games,
banking and ticketing applications, wireless collaboration and so on
(Figure 1-2).
Advertise
Advertise User
User User
User
App
App on
on Selects
Selects Downloads
Downloads
Web
Web Page
Page App
App App
App
Web Page
The need for customizability and personalized applications requires a lot more
from the application development platform than is available in mainstream
small consumer devices today. With the power of a widely used, extensible
programming platform such as the Java™ platform, the development of such
applications and services will become significantly easier.
4. the need for applications and capabilities to change and grow (often in
unforeseen ways) in order to accommodate the future needs of the
consumer.
Profiles
Configuration
Java Virtual
Virtual Machine
Machine
The J2ME architecture currently has two configurations that have been defined
using the JCP. The Connected Device Configuration (CDC) uses the classic Java
virtual machine, a full-featured VM that includes all the functionality of a
For wireless devices and other systems with severely constrained memory
environments, J2ME uses the Connected Limited Device Configuration (CLDC),
discussed in more detail below.
Java Editions
Recognizing that one size does not fit all, Sun has grouped its Java
technologies into three editions, each aimed at a specific area of today’s vast
computing industry:
• Java 2 Enterprise Edition (J2EE)—for enterprises needing to serve their
customers, suppliers, and employees with solid, complete, and scalable
Internet business server solutions.
• Java 2 Standard Edition (J2SE)—for the familiar and well-established desktop
computer market.
• Java 2 Micro Edition (J2ME)—for the combined needs of:
— consumer and embedded device manufacturers who build a diversity of
information devices;
— service providers who wish to deliver content to their customers over
those devices; and
— content creators who want to make compelling content for small,
resource-constrained devices.
Each Java edition defines a set of technology and tools that can be used with a
particular product:
• Java virtual machines that fit inside a wide range of computing devices;
• libraries and APIs specialized for each kind of computing device; and
• tools for deployment and device configuration.
9
2
Figure 2-1 below illustrates the target markets of each edition.
workstation POS
communicator
server
pager
NC
PDA
PC, laptop
screen-
set-top box, phone
net TV
Java 2 cell phone card
smartphone
Enterprise Java 2
Edition Standard CDC
CDC CLDC
CLDC
Edition Java 2 Micro Edition
Java Language
HotSpot JVM KVM Card VM
The line between these two product categories is fuzzy and becoming more so
every day. As a result of the ongoing technological convergence in the
computer, telecommunication, consumer electronics and entertainment
industries, there will be less distinction between general-purpose computers,
personal communication devices, consumer electronics devices and
entertainment devices. Also, future devices are more likely to use wireless
connectivity instead of traditional fixed or wired networks. In practice, the line
between the two categories is defined more by the memory budget, bandwidth
considerations, battery power consumption, and physical screen size of the
device, rather than by its specific functionality or type of connectivity.
Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000 11
2
special-purpose, limited-function devices. To address this diversity, an essential
requirement for J2ME is not only small size but also modularity and
customizability.
The J2ME architecture is modular and scalable so that it can support the kinds
of flexible deployment demanded by the consumer and embedded markets. To
enable this, J2ME provides a range of virtual machine technologies, each
optimized for the different processor types and memory footprints commonly
found in the consumer and embedded marketplace.
J2ME configurations and profiles are defined through the Java Community
Process (JCP).
J2ME Profiles
Application portability is a key benefit of Java technology in the desktop and
enterprise server markets. Portability is also a critical element of the J2ME
value proposition for consumer devices. However, application portability
requirements in the consumer space are generally quite different from
In general, the consumer device market is not so homogeneous that end users
expect or require universal application portability. Rather, in the consumer
space, applications should ideally be fully portable between devices of the
same kind. For example, consider the following types of consumer devices:
– cellular telephones
– washing machines
– intercommunicating electronic toys
In addition, there are important economic reasons to keep these device families
separate. Consumer devices compete heavily on cost and convenience, and
these factors often translate directly into limitations on physical size and
weight, processor power, memory size, and power consumption (in battery-
powered devices.) Consumers’ wallets will always favor devices that perform
the desired functions, but that do not have added cost for unnecessary features.
Thus, the J2ME framework provides the concept of a profile to make it possible
to define Java platforms for specific vertical markets. A profile defines a Java
platform for a specific vertical market segment or device category. Profiles can
serve two distinct portability requirements:
Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000 13
2
• A profile provides a complete toolkit for implementing applications for a
particular kind of device, such as a pager, set-top box, cell phone, washing
machine, or interactive electronic toy.
• A profile may also be created to support a significant, coherent group of
applications that might be hosted on several categories of devices. For
example, while the differences between set-top boxes, pagers, cell phones,
and washing machines are significant enough to justify creating a separate
profile for each, it might be useful for certain kinds of personal information
management or home banking applications to be portable to each of these
devices. This could be accomplished by creating a separate profile for these
kinds of applications and ensuring that this new profile can be easily and
effectively supported on each of the target devices along with its “normal”
more device-specific profile.
In our example above, each of the three families of devices (cell phones,
washing machines, and intercommunicating toys) would be addressed by a
separate J2ME profile. Of course, the only one of these profiles in existence at
the current time is the MIDP, designed for cell phones and related devices.
J2ME Configurations
In J2ME, an application is written “for” a particular profile, and a profile is
“based upon” or “extends” a particular configuration. Thus, all of the features
of a configuration are automatically included in the profile and may be used by
applications written for that profile.
In our example above, each of the three profiles (for cell phones, washing
machines, and intercommunicating toys) would most likely be built upon the
same configuration, the CLDC. This configuration provides all the basic
functionality to serve the needs of each of these, and perhaps many more,
profiles.
Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000 15
2
To avoid fragmentation, there will be a very limited number of J2ME
configurations. Currently, the goal is to define two standard J2ME
configurations (see Figure 2-2):
• Connected, Limited Device Configuration (CLDC). The market consisting
of personal, mobile, connected information devices is served by the CLDC.
This configuration includes some new classes, not drawn from the J2SE
APIs, designed specifically to fit the needs of small-footprint devices.
• Connected Device Configuration (CDC). The market consisting of shared,
fixed, connected information devices is served by the Connected Device
Configuration (CDC). To ensure upward compatibility between
configurations, the CDC shall be a superset of the CLDC.
CDC CLDC
Figure 2-2 Relationship between J2ME configurations and Java 2 Standard Edition
Figure 2-2 illustrates the relationship between CLDC, CDC and Java 2 Standard
Edition (J2SE). As shown in the figure, the majority of functionality in CLDC
and CDC has been inherited from J2SE. Each class inherited from J2SE must be
precisely the same or a subset of the corresponding class in Java 2 Standard
Edition. In addition, CLDC and CDC may introduce a number of features, not
drawn from the J2SE, designed specifically to fit the needs of small-footprint
devices. For further details, refer to Configurations and Profiles Architecture
Specification, Java 2 Platform Micro Edition (J2ME), Sun Microsystems, Inc.
The most important reason for the configuration layer of J2ME is that
configurations and Java virtual machines are very closely related and are
rather complex pieces of software. Small differences in a configuration’s
specification can require a large number of modifications to the internal design
of a Java virtual machine, which would be very expensive and time-consuming
KVM
The KVM is a compact, portable Java virtual machine specifically designed
from the ground up for small, resource-constrained devices. The high-level
design goal for the KVM was to create the smallest possible “complete” Java
virtual machine that would maintain all the central aspects of the Java
programming language, but would run in a resource-constrained device with
only a few hundred kilobytes total memory budget.
The “K” in KVM stands for “kilo.” It was so named because its memory budget
is measured in kilobytes (whereas desktop systems are measured in
megabytes). KVM is suitable for 16/32-bit RISC/CISC microprocessors with a
total memory budget of no more than a few hundred kilobytes (potentially less
than 128 kilobytes). This typically applies to digital cellular phones, pagers,
personal organizers, and small retail payment terminals.
Introduction to the Java 2 Platform Micro Edition, CLDC, and KVM—May 19, 2000 17
2
varies considerably depending on the implementation, the device, the
configuration, and the profile. A simple KVM implementation without system
class prelinking support needs more volatile memory than a KVM
implementation with system classes (or even applications) preloaded into the
device.
The actual role of a KVM in target devices can vary significantly. In some
implementations, the KVM is used on top of an existing native software stack
to give the device the ability to download and run dynamic, interactive, secure
Java content on the device. In other implementations, the KVM is used at a
lower level to also implement the lower-level system software and applications
of the device in the Java programming language. Several alternative usage
models are possible.
At the present time, the KVM and CLDC are closely related. CLDC runs only
on top of KVM and CLDC is the only configuration supported by KVM.
However, over time it is expected that CLDC will run on other J2ME virtual
machine implementations and that the KVM may perhaps support other
configurations as they are defined.
For further information on the KVM, refer to the KVM web site at
http://java.sun.com/products/kvm.
As mentioned previously, the KVM and CLDC are very closely related. In
essence, CLDC is the specification for a “class” of Java virtual machines that can
run on the categories of devices targeted by CLDC and support the profiles
layered on top of CLDC. The KVM is a particular implementation (currently the
one and only Sun reference implementation) of a Java virtual machine meeting
the CLDC specifications. Therefore, no discussion of KVM can be complete
without an understanding of the CLDC requirements. This chapter briefly
describes some of the CLDC specifications that affect the KVM.
CLDC Goals
• To define a standard Java platform for small, resource-constrained,
connected devices.
• To allow dynamic delivery of Java applications and content to those devices.
• To enable 3rd party application developers to easily create applications and
content that can be deployed to those devices.
19
3
CLDC Requirements
• To run on a wide variety of small devices ranging from wireless
communication devices such as cellular telephones and two-way pagers to
personal organizers, point-of-sale terminals and even home appliances.
• To make minimal assumptions about the native system software available in
CLDC devices.
• To define a minimum complement or the “lowest common denominator” of
Java technology applicable to a wide variety of mobile devices.
• To guarantee portability and interoperability of profile-level code between
the various kinds of mobile (CLDC) devices.
The entire CLDC implementation (static size of the virtual machine + libraries)
should fit in less than 128 kilobytes. The CLDC Specification assumes that
applications can be run in as little as 32 kilobytes of Java heap space.
CLDC Scope
The CLDC configuration addresses the following areas:
• Java language and virtual machine features
• Core Java libraries (java.lang.*, java.util.*)
• Input/output
• Networking
• Security
• Internationalization
The CLDC configuration does not address the following areas. These features
are addressed by profiles implemented on top of the CLDC:
• Application life-cycle management (application installation, launching,
deletion)
• User interface
• Event handling
• High-level application model (the interaction between the user and the
application)
Security
The CLDC specification addresses the following topics related to security:
• Low-level-virtual machine security is achieved by requiring downloaded
Java classes to pass a classfile verification step.
• Applications are protected from each other by being run in a closed
“sandbox” environment.
• Classes in protected system packages cannot be overridden by applications.
Apart from floating point support, which has been omitted primarily because
the majority of the CLDC target devices do not have hardware support for
floating point arithmetic, the features above have been eliminated either
because of:
• strict memory limitations, or
• because of potential security concerns in the absence of the full J2SE security
model.
Classfile Verification
CLDC requires that a Java VM be able to identify and reject invalid classfiles.
However, since the standard classfile verification approach defined by J2SE is
too memory-consuming for small devices, CLDC defines an alternative
mechanism for classfile verification.
Note that since stack maps have been implemented by utilizing the extensible
attribute mechanism built in Java classfiles, classfiles containing stack maps
will run unmodified in larger Java environments such as J2SE or J2EE.
Development workstation
MyApp.java
…download... Target device
javac (KVM runtime)
MyApp.class verifier
preverifier
interpreter
MyApp.class
Classfile Format
In order to enable dynamic downloading of 3rd party applications and content,
CLDC requires that implementations support the distribution of Java
applications via compressed Java Archive (JAR) files. Whenever a Java
application intended for a CLDC device is “represented publicly” or
“distributed publicly” it must be formatted in a compressed Java Archive (JAR)
file, and classfiles within a JAR file must contain the stackmap attribute.
(However, once an application is admitted into the kinds of closed, private,
CLDC Libraries
In order to ensure upward compatibility and portability of applications, the
majority of the class libraries included in CLDC are a subset of those specified
for the larger Java editions (J2SE and J2EE). Only those classes that are
appropriate for mobile devices are specified by CLDC.
System Classes
From java.lang:
Object, Class, Runtime, System, Thread, Runnable,
String, StringBuffer, Throwable
Collection Classes
From java.util:
Vector, Stack, Hashtable, Enumeration
I/O Classes
From java.io:
InputStream, OutputStream, ByteArrayInputStream,
ByteArrayOutputStream, DataInput, DataOutput,
DataInputStream, DataOutputStream, Reader, Writer,
InputStreamReader, OutputStreamWriter, PrintStream
Exception Classes
From java.lang:
Exception, ClassNotFoundException,
IllegalAccessException, InstantiationException,
InterruptedException, RuntimeException,
ArithmeticException, ArrayStoreException,
ClassCastException, IllegalArgumentException,
IllegalThreadStateException, NumberFormatException,
IllegalMonitorStateException, IndexOutOfBoundsException,
ArrayIndexOutOfBoundsException,
StringIndexOutOfBoundsException,
NegativeArraySizeException, NullPointerException,
SecurityException
From java.util:
EmptyStackException, NoSuchElementException
From java.io:
EOFException, IOException, InterruptedException,
UnsupportedEncodingException, UTFDataFormatException
Error Classes
From java.lang:
Error, VirtualMachineError, OutOfMemoryError
Limitations
• CLDC includes limited support for the translation of Unicode characters to
and from a sequence of bytes using Readers and Writers.
• CLDC does not support class java.util.Properties, which is part of
J2SE. However, a limited set of properties beginning with the keyword
“microedition” can be accessed by calling the method
System.getProperty(String key).
CLDC-Specific Classes
The J2SE and J2EE libraries provide a rich set of functionality for handling
input and output access to storage and networking systems via the java.io
and java.net.* packages, However, it is difficult to make all this
functionality fit in a small device with only a few hundred kilobytes of total
memory budget.
This has led to a generalization of the J2SE network and I/O classes for J2ME.
The general goal for this new system is to be a precise functional subset of J2SE
classes, which can easily map to common low-level hardware or to any J2SE
implementation, but with better extensibility, flexibility and coherence in
supporting new devices and protocols.
General Form
All connections are created using a single static method in a system class called
javax.microedition.Connector. If successful, this method will return an
object that implements one of the generic connection interfaces. There are
number of these interfaces that form a hierarchy with the Connection
interface being the root. The method takes a URL parameter in the general
form:
Examples
NOTE—These examples are provided for illustration only. CLDC itself does
not define any protocol implementations. It is not expected that a particular
J2ME profile would provide support for all these kinds of connections. J2ME
profiles may also support protocols not shown below.
• HTTP records: Connector.open("http://www.foo.com");
• Sockets: Connector.open("socket://129.144.111.222:9000");
• Communication ports: Connector.open("comm:0;baudrate=9600");
• Datagrams: Connector.open("datagram://129.144.111.333");
• Files: Connector.open("file:foo.dat");
• Network file systems: Connector.open("nfs:/foo.com/foo.dat");
The high-level design goal for the KVM was to create the smallest possible
“complete” Java virtual machine that would maintain all the central aspects of
the Java programming language, and that would nevertheless run in a
resource-constrained device with only a few tens or hundreds of kilobytes of
available memory (hence the name K, for kilobytes). More specifically, the
KVM is designed to be:
• Small, with a static memory footprint of the virtual machine core in the
range 40 kilobytes to 80 kilobytes (depending on the target platform and
compilation options).
• Clean and highly portable.
• Modular and customizable.
• As “complete” and “fast” as possible without sacrificing the other design
goals.
29
4
various compile-time flags and options to aid porting efforts and improve
space optimization.
Sun Implementations
Sun’s KVM reference implementation can be compiled and tested on two
platforms:
• Solaris
• Windows
The Solaris and Windows platforms are used for KVM development,
debugging, testing, and demonstration. They leverage a wealth of
development tools and allow rapid porting and development efforts due to the
increased workstation-class performance. The Solaris and Windows versions of
the KVM are used as the basis for official CLDC reference implementations
that customers can use for the device-specific ports.
The Palm OS platform is the primary test bed to ensure that KVM meets its
goals of efficiently executing on a resource-limited device.
Other Implementations
At the time of this writing, the KVM has been successfully ported to more than
25 devices by Sun’s Early Access licensees.
Compiler Requirements
The KVM is designed to be built with any C compiler capable of compiling
ANSI-compliant C files. The only non-ANSI feature in the source code is its use
of 64-bit integer arithmetic.
Our reference implementation has only been tested on machines with 32-bit
pointers and that do not require “far” pointers of any sort. We do not know if
it will run successfully on platforms with pointers of other sizes.
Porting KVM
The majority of KVM source code is common to all implementations. The
relatively small amount of machine-dependent and/or platform-specific code
is isolated to small number of files. New or modified versions of these files
must be created for each port.
Compilation Control
A large number of macro definitions are provided to control features relating
to:
• Data alignment
• Long (64-bit) integers
• Floating point (if used)
• Endianness (big endian vs. little endian)
• Classpaths (if used or not)
• System class preloading (ROMizing)
• Platform-specific features
• Memory allocation
• Garbage collection
• Interpreter options and optimizations
• Debugging and tracing options
• Networking and storage options (Generic Connections)
For devices that do not have such a user interface, the KVM provides a
reference implementation of a facility called the Java Application Manager
(JAM), which serves as an interface between the host operating system and the
virtual machine. The JAM assumes that applications are available for
downloading as JAR files by using a network (typically HTTP) or storage
protocol implemented using the Generic Connection framework. The JAM
reads the contents of the JAR file and an associated descriptor file from the
Internet, and launches the KVM with the main class as a parameter.
Class Loading
The KVM reference implementation can load classes from a directory path as
well as from a JAR file. Alternative device-specific class loading mechanisms
can be created where necessary.
64-Bit Support
The KVM is most easily ported to compilers that support 64-bit arithmetic.
However, macros are provided that can be redefined to perform the
appropriate operations for compilers that do not support 64-bit integers.
Native Code
The KVM does not support the Java Native Interface (JNI). Rather, any native
code called from the virtual machine must be linked directly into the virtual
machine at compile time. Invoking native methods is accomplished via native
method lookup tables, which must be created during the build process.
Event Handling
For porting flexibility, there are four ways in which notification and handling
of events can be done in the KVM:
• Synchronous notification (blocking).
• Polling in Java code.
• Polling in the bytecode interpreter.
• Asynchronous notification.
Each KVM port can use the mechanism that is most appropriate for its
platform.
Classfile Verification
As described in the CLDC chapter, KVM makes use of the new “stack map”
method attribute in order to quickly and efficiently verify classfiles.
In conventional class loading, you use javac to compile Java source files into
Java class files. These class files are loaded into a Java system, either
individually, or as part of a jar archive file. Upon demand, the class loading
mechanism resolves references to other class definitions.
JavaCodeCompact can:
• Combine multiple input files.
• Determine an object instance’s layout and size.
• Load only designated class members, discarding others.
The JCC tool itself is written in Java, and so is portable to various development
platforms.
Future Directions
As we move into the future, our goals for the CLDC and KVM technologies are
to further evolve them, and to provide tools to accomplish the following goals:
• Optimize the class file format to reduce space requirements and to reduce
time to install applications on resource-constrained devices.
• Provide better support for Java-level debugging and IDE integration.
• Improve the performance of essential virtual machine components such as
the garbage collector, class loader, and thread synchronization operations.
• Provide other space and performance optimizations.
35
5