A Survey of Java ME Today (Update)

This article surveys the state of the Java Platform, Micro Edition (Java ME). You'll find important background information and explanations of terminology that you need to understand. It complements Introduction to Mobility Java Technology and the Java ME specifications, both of which you should take the time to read.

The Java programming language was originally developed for programming consumer electronic devices, but over the years it evolved into a set of technologies used primarily to develop desktop- and server-based applications. In many ways, today's Java ME platform is a return to the origins of Java technology.

It all started in the early 1990s with the Green Project and the Oak programming language, later renamed Java. Today's Java ME is the descendant of earlier platforms for small devices created by Sun Microsystems: the Oak part of the Green Project (early 1990s), Java Card (1996), PersonalJava (1997), EmbeddedJava (1998), and more recently, the Spotless System (PDF) and the K virtual machine (1999).

Today, the Java ME platform targets high- and low-end electronic devices with a single Java platform. Java Card, described later in this article, remains an important independent Java platform, distinct from Java ME, based on smart cards.

Java Technology Editions
Java ME is one of three technology editions of the Java platform.^* Each edition packages and licenses Java technology differently and provides an appropriate runtime environment to meet the needs of specific application developers:

A typical enterprise application may well take advantage of all three editions, with Java EE technology-based applications on the server side providing services to applications based on Java SE and Java ME technology on the client side. Separating the Java platform into these editions allows for sharper focus on the varying needs of developers working in different target environments, and it enables the editions to evolve in different yet complementary directions.

Java technology evolves through the Java Community Process (JCP) program. The JCP is an open, community-based standards organization with a formal process for defining and revising Java technology specifications. JCP program members are individuals and organizations that share a common interest in seeing Java technology continue to evolve to meet market needs successfully. Even though the JCP is an open, community-based process, Sun Microsystems retains all Java technology-related trademarks and remains the ultimate authority for the Java platform.

The JCP process is straightforward: JCP members who want to extend the Java platform submit a formal proposal called a Java Specification Request (JSR), which then proceeds through a well-defined life cycle of drafts, reviews, and approval ballots. You can subscribe to the JCP mailing list to receive regular updates on JSRs and on JCP procedures, participate in public reviews by responding to requests for public comment, or even become a member of an expert group that shepherds a JSR through the development process.

To stay current with Java ME developments, keep up with the relevant JSRs. To start, read this Introduction to Mobility Java Technology and visit the JCP Java ME technology page. The JCP page lists more than 80 relevant JSRs, both those that have earned final approval and those that are still in process. Your contributions help ensure that Java technology continues to satisfy market needs.

Java ME does not define a new programming language. Rather, it adapts existing Java technology to handheld and embedded devices. Java ME maintains compatibility with Java SE wherever feasible. To address the stricter limitations of devices, Java ME sometimes replaces Java SE APIs and adds new interfaces. But the evolution of Java ME is as much about omitting unnecessary parts of the Java SE and Java EE platforms as it is about overriding and adding new ones.

Java ME is conceptually organized as a stack consisting of four software layers, as shown in Figure 1. To take fullest advantage of the Java ME platform, developers base their applications on a configuration appropriate to the category of target devices, a profile that supports the application's basic functionality, and optional packages or APIs that support needed specialized functions such as messaging or multimedia.

Let's look at Figure 1, starting at the bottom. The configuration consists of the virtual machine (VM) and core Java APIs. Above the configuration are profiles and the application environment, which consist of the APIs and application environment such as the Mobile Information Device Profile, the Java Technologies for Wireless Industry, and the Mobile Service Architecture clarifications.

Next on the stack are the mandatory, conditionally mandatory, or optional packages or APIs. These include vendor-specific classes that are not part of the Java ME standard but that extend or provide functionality that is specific to a given device, such as APIs to control radio transceivers. At the top of the stack are the Java ME applications themselves.

This article will discuss each layer in depth, but let's first look at where Java ME sits with respect to other Java technologies for handheld and embedded devices.

Java ME has evolved into an organized architecture for electronic devices, including sets of Java APIs for high-end PDAs and embedded devices, as well as for more constrained devices such as cell phones, low-end PDAs, and headless devices -- those without display or user interface (UI) facilities. Today the Java technologies for handsets, smart cards, and embedded devices are split as illustrated in Figure 2.

Java ME comprises the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC):

Java Card technology consists of the Java Card VM, the Java Card framework, and the security and remote invocation APIs.

Java SE for Embedded is Java SE technology with special support, functionality, and a licensing model for embedded platforms. It has a smaller footprint Java SE technology-based runtime, memory optimizations, and other savings, access to read-only memory (ROM) or compact flash, and support for embedded CPUs and operating systems. It replaces EmbeddedJava and PersonalJava.

The Mobile Service Architecture (MSA) specification defines a common architecture and programming platform for wireless handsets. Like its predecessor, Java Technology for the Wireless Industry (JSR 185), MSA is an umbrella Java specification, a collection of familiar, updated, and new JSRs that cooperate to support applications with a wide range of standardized capabilities.

Two flavors of MSA are defined: The basic MSA (JSR 248) addresses CLDC-based platforms, and the MSA-Advanced (JSR 249) addresses CDC-based platforms. The architectures define a comprehensive structure of APIs aimed at facilitating development and deployment of the widest possible variety of applications, in a form that will be easily portable across the broadest possible spectrum of mobile devices.

The basic MSA defines two stacks: a full MSA stack that comprises 16 JSRs and a subset of eight JSRs, as illustrated in Figure 3.

Some of the JSRs are mandatory, and others are conditionally mandatory. To comply with MSA, an implementation must support a mandatory JSR or one that is conditionally mandatory, that is, one that becomes mandatory when relevant conditions are true. A typical example of the latter is JSR 82, the Bluetooth API, which is not always required but must be supported if the device claims to support the Bluetooth wireless technology.

A configuration, at the bottom of the Java ME organization stack shown in Figure 1, defines a basic lowest-common-denominator Java runtime environment. This includes the VM and a set of core classes derived primarily from the Java SE platform. Each configuration is geared for a broad family of constrained devices with some type of network connectivity.

As this article mentioned earlier, two configurations have been defined: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). CLDC is a subset of CDC, as Figure 4 shows.

CDC includes all the classes defined by CLDC, including any new ones not included in the Java SE platform, such as the Generic Connection Framework.

The Connected Limited Device Configuration (CDC)
A direct descendant of the Spotless System, CLDC is a minimal Java ME configuration for devices with stringent restrictions on computational power, battery life, memory, and network bandwidth. These limits directly affect the kinds of Java technology-based applications they can support.

CLDC does not require a lot of resources. It supports devices with 16-bit or 32-bit processors with at least 160 KB of persistent memory and at least 32 KB of volatile memory, for a total of 192 KB. Power consumption is low, and devices are typically battery-powered. Network connectivity may be over an intermittent, slow-speed connection. At the heart of this configuration is a Java virtual machine with some Java SE capabilities removed. For example, CLDC does not support class finalization or thread groups. For a list of all the restrictions, visit the CLDC product page.

CLDC defines a subset of the standard core Java language packages familiar to Java SE developers, and it adds classes tailored for constrained devices. In addition, CLDC has introduced the streamlined Generic Connection Framework package, javax.microedition.io, to support I/O in devices that lack the memory to use the larger java.net and java.io packages. This framework is a straightforward hierarchy of interfaces and classes that create connections of various types -- including HTTP, datagram, and streams -- and that perform I/O. Table 1 lists the Java packages included in the CLDC.

Name	Description

`java.lang`	CLDC subset of core Java programming language classes
`java.lang.ref` (CLDC 1.1 only)	CLDC subset to support weak references
`java.util`	CLDC subset of Java SE utility classes
`java.io`	CLDC subset of system I/O through data streams
`javax.microedition.io`	Network support based on the Generic Connection Framework

Note that CLDC 1.1, JSR 139, has superseded the original CLDC 1.0 specification, JSR 30.

Differences Between CLDC 1.0 and 1.1
CLDC 1.0 and 1.1 are very similar. From the developer's perspective, the most important enhancements in the newer release are the new floating-point math capabilities and support for weak references. The following list, taken from the CLDC specification document, summarizes CLDC 1.1's main differences from version 1.0:

The Connected Device Configuration (CDC)
CDC is designed for more powerful devices than those that CLDC supports, such as high-end cell phones and PDAs, and the more sophisticated embedded devices: TV set-top boxes, Web-based devices such as Internet appliances, and even car navigation systems.

Devices that support CDC have 32-bit processors, typically ARM-based devices, at least 2 MB of main memory and 2.5 MB of ROM, and some type of network connectivity. At the heart of this configuration is a Java VM such as the CDC HotSpot Implementation, with full Java SE capabilities.

CDC is a superset of CLDC. It includes all the classes defined by the CLDC, including any new ones not included in Java SE, such as the Generic Connection Framework. CDC includes many more core Java SE classes than does CLDC, making it a more familiar environment for experienced Java SE programmers. Table 2 summarizes the packages in CDC.

Name	Description

`java.lang`	CDC subset of the core Java programming language
`java.lang.ref`	Reference-object classes, which support a limited degree of interaction with the garbage collector
`java.lang.reflect`	Classes and interfaces for obtaining reflective information about classes and objects
`java.math`	CDC subset of classes for performing arbitrary-precision integer arithmetic
`java.text`	CDC subset of classes and interfaces for handling text, dates, numbers, and messages in a manner independent of native languages
`java.io`	CDC subset of system input and output through data streams, serialization, and the file system
`javax.microedition.io`	Network support based on the Generic Connection Framework; support for `file:` and `datagram:`
`java.util`	CDC subset of collections, date and time facilities, internationalization, and miscellaneous utility classes
`java.util.zip`	CDC subset of classes for reading the standard ZIP file format
`java.util.jar`	CDC subset of classes for reading files in the Java archive (JAR) format, which is based on the standard ZIP file format, with an optional manifest file
`java.net`	CDC subset of classes for implementing a networking application; support for datagram: and JAR I/O
`java.security`	CDC subset of classes and interfaces for the security framework
`java.security.cert`	CDC subset of classes and interfaces for parsing and managing certificates

CDC release 1.0 was introduced as JSR 36. More recently, CDC 1.1 was introduced as JSR 218.

Differences Between CDC 1.0 and 1.1
CDC 1.1 is very like its predecessor. Existing APIs have been cleaned up. Enhancements center mainly on support for J2SE 1.4, including Unicode 3.0, assertions, and the new security optional packages: Java Authentication and Authorization Service (JAAS), Java Secure Socket Extension (JSSE), and Java Cryptography Extension (JCE).

Configurations do not provide classes for managing the application life cycle, for driving the UI, for maintaining and updating persistent data locally in the device, or for accessing securely information that is stored on a network server. Instead, that type of functionality is provided by the profiles or by optional packages. A profile adds domain-specific classes to the core set of classes provided by the configuration, classes that are geared toward specific uses of devices and provide functionality missing from the underlying configuration.

At this writing, there are six profiles, three based on CLDC and three on CDC. The three standard CLDC-based profiles are the following:

Not all these profiles are restricted to mobile handsets, with the latter targeted to digital set-top boxes.

Figure 5 shows how profiles relate to their underlying configurations and to each other.

Multiple profiles can exist on top of the same configuration, as in the case of MIDP and IMP. They can also depend on or build on each other. For example, the Personal Profile extends the Personal Basis Profile, which in turn depends on the Foundation Profile. Expect more profiles to appear as Java ME technology evolves.

CLDC-Based Profiles
Of the profiles designed for CLDC, MIDP is the most prevalent. Although MIDP 2.0 has superseded MIDP 1.0 in capability, many devices still support only MIDP 1.0, so you should not ignore the older version. At the time of this writing, version 3.0 is being defined in the JCP program.

IMP promises to do for headless devices -- that is, those without display or UI facilities, such as vending machines, industrial devices, and security systems -- what MIDP has done for smart cell phones and low-end PDAs. There are two versions of IMP: Version 1.0 is based on MIDP 1.0, and the Next Generation (NG) version is based on MIDP 2.0.

Use of CLDC is not restricted to such devices, however. As Figure 6 illustrates, the Digital Set Top Box Profile (JSR 242) is a CLDC-based profile specifically defined for the cable market. Also referred to as OnRamp, this profile is based on a subset of the PersonalJava technology-based OpenCable Application Platform (OCAP), which defines a set of APIs for the development of applications for set-top boxes and similar devices.

OnRamp is quite large, with 31 Java packages and approximately 1500 APIs. But it is not as large as its superset, OCAP, which has approximately 8000 APIs. These include a subset from the Personal Basis Profile such as support for the Abstract Window Toolkit (AWT), Xlet, file access, and network APIs, as well as support for several media-related interfaces including Java TV, Java Media Framework (JMF), Digital Audio Visual Council (DAVIC), Home Audio/Video Interoperability (HAVI), Digital Video Broadcasting (DVB), and as previously mentioned, the OpenCable Application Platform (OCAP).

As the first Java ME profile, MIDP is the most mature and widely adopted, with millions of deployments all around the world, primarily on PDAs, cell phones, and other handheld communicators.

IMP's targets are devices with characteristics similar to those of MIDP devices but with little or no capabilities for UI: headless embedded devices in vending machines, industrial applications, and security systems. First defined by JSR 195, IMP borrows all of its functionality from MIDP, including application-management, storage, networking, security, and timer APIs. IMP 1.0 is a strict subset of MIDP 1.0, excluding the APIs for UI, specifically javax.microedition.lcdui. IMP applications are called IMlets, but for all intents and purposes, they are MIDP applications or MIDlets: They subclass MIDlet and have the same packaging, deployment, security features, and life cycle as MIDlets.

MIDP 1.0 was introduced in JSR 37 and is still in wide use. MIDP 2.0, defined by JSR 118, enhanced the profile's capabilities. To the original APIs for networking, UIs, local persistence, and MIDlet life cycle, MIDP 2.0 added new networking APIs to support TCP socket streams and UDP datagrams,as well as serial, push-initiated, and secure connections. Other additions include a robust security API and policy, as well as APIs for sound and gaming.

The MIDP 2.0 profile specification also includes an update of the Over-the-Air (OTA) User-Initiated Provisioning recommendation that was originally defined as an addendum to the MIDP 1.0 specification, which describes how users can discover and download applications over wireless networks. Even though the MIDP specification indicates the use of CLDC 1.0, nothing precludes use of CLDC 1.1 as the base for either version of MIDP.

At this writing, IMP is undergoing its first revision. JSR 228, also known as IMP-NG, is IMP's next generation. It will take advantage of MIDP 2.0's new security and networking types and APIs, and other APIs such as PushRegistry and platformRequest(), but like IMP 1.0, it will not include any of the UI, game, or media APIs. Table 3 summarizes the device requirements for MIDP and IMP.

Table 4 summarizes the packages available in both versions of MIDP and in IMP 1.0.

Name	Description	MIDP 1.0	MIDP 2.0	IMP 1.0

`java.lang`	MIDP subset of the core Java programming language	X	X	X
`java.util`	Small subset of utility classes	X	X	X
`java.io`	MIDP subset of system input and output through data streams	X	X	X
`javax.microedition.io`	Networking support using the Generic Connection Framework; includes new socket, UDP, serial, and secure connection types, as well as push functionality	X	X	X
`javax.microedition.lcdui`	MIDP classes for UI	X	X
`javax.microedition.lcdui.game`	Gaming classes such as sprites, game canvas, and layer manager		X
`javax.microedition.media`	Interfaces for controlling (`Control`) and rendering (`Player`) audio -- sound classes compatible with the Mobile Media API specification (JSR 135)		X
`javax.microedition.media.control`	Sound-control classes (`ToneControl` and `VolumeControl`) -- compatible with the Mobile Media API specification (JSR 135)		X
`javax.microedition.midlet`	Application interface, life-cycle classes, and interactions with the runtime environment and application manager	X	X	X
`javax.microedition.pki`	Public key class for certificates used to authenticate information for secure connections		X	X
`javax.microedition.rms`	Classes for storing and retrieving persistent data	X	X	X

CDC-Based Profiles
A richer configuration than CLDC, CDC is aimed at higher-end handheld and embedded devices, those with more memory and more processing power, but the configuration and profile pattern are the same. CDC provides a generic, low-level interface to the device, and one or more CDC-based profiles provide classes whose capabilities are appropriate to particular categories of devices. You've already seen that the Foundation Profile, Personal Basis Profile, and Personal Profile build on each other, as illustrated in Figure 7.

The Foundation Profile includes all the classes in CDC and adds more Java SE classes, security features, and other APIs. The Personal Basis Profile includes all of CDC and Foundation Profile, and then adds a minimum core set of UI classes, among other features. The Personal Profile incorporates all of CDC, Foundation Profile, and Personal Basis Profile, and it provides a more complete set of the Abstract Window Toolkit (AWT) API, including its heavyweight APIs and support for applets.

The Foundation Profile
The Foundation Profile is a base for building other CDC-based profiles. In addition to providing all of CDC's interfaces and classes, the Foundation Profile extends the configuration by adding security, utility, and locale classes.

Because the Foundation Profile does not provide any UI classes -- no AWT, no Swing -- it is the profile of choice for small devices that don't need a UI, such as headless, dedicated, connected, and embedded devices. Table 5 summarizes the Foundation Profile's Java packages.

Name	Description

All the packages in CDC	See Table 2
`java.lang`	The core Java programming language
`java.lang.ref`	Reference-object classes, which support a limited degree of interaction with the garbage collector
`java.lang.reflect`	Classes and interfaces for obtaining reflective information about classes and objects
`java.math`	Subset of classes for performing arbitrary-precision integer arithmetic
`java.text`	Classes and interfaces for handling text, dates, numbers, and messages in a manner independent of native languages
`java.util`	Set of generally useful classes such as collections, event model, date and time facilities, internationalization, and miscellaneous utility classes
`java.util.jar`	Classes for reading and writing the Java archive (JAR) file format, which is based on the standard ZIP file format, with an optional manifest file
`java.util.zip`	Classes for reading and writing the standard ZIP file format
`java.io`	Subset of system input and output APIs through data streams, serialization, and the file system
`java.net`	Classes for implementing networking applications; support for all CDC protocols (`datagram:` and JAR), as well as `socket:` and `http:`
`java.security`	Classes and interfaces for the security framework
`java.security.acl`	Access Control List support. Note: Some classes and interfaces in this package have been superseded by classes in `java.security`
`java.security.cert`	Classes and interfaces for parsing and managing certificates
`java.security.interfaces`	Interfaces for generating RSA PKCS#1 keys and DSA NIST's FIPS-186 keys
`java.security.spec`	Classes and interfaces for key and algorithm parameter specifications
`javax.microedition.io`	Network support based on the Generic Connection Framework; support for all CDC protocols (`file:` and `datagram:`), as well as `socket:` and `http:`

Version 1.0 of the Personal Basis Profile was defined in JSR 129. More recently, version 1.1 was introduced in JSR 217, which is still in progress.

Differences Between Foundation Profile 1.0 and 1.1
The two versions of Foundation Profile are very similar. Existing APIs are being cleaned up. Enhancements are mainly centered on support for J2SE 1.4, including support for the next generation of the Internet Protocol IPv6, and java.net.URI.

The Personal Basis Profile
The Personal Basis Profile builds on the Foundation Profile and is a subset of the Personal Profile. In addition to providing all CDC and Foundation Profile interfaces and classes, the Personal Basis Profile includes a lightweight subset of the AWT that supports graphics, images, and widgets on devices that require a simple UI, such as automotive devices, consumer devices, and simple appliances. This profile also supports JavaBeans programming and a new Xlet application model. Table 6 summarizes the Java packages in the Personal Basis Profile.

Name	Description

All the packages in CDC and Foundation Profile	See Table 2 and Table 5
`java.awt`	Subset of classes for creating simple UIs and for painting graphics and images
`java.awt.color`	Subset of classes for manipulating colors
`java.awt.event`	Subset of interfaces and classes for handling events fired by AWT components
`java.awt.image`	Subset of classes for creating and modifying images
`java.beans`	Subset of classes related to JavaBeans development
`java.rmi`	Subset of RMI classes to support inter-Xlet communication
`java.rmi.registry`	Subset of RMI classes to support inter-Xlet communication
`javax.microedition.xlet`	Defines new Xlet application model, life-cycle classes, and interactions with the application manager
`javax.microedition.xlet.ixc`	Defines classes for inter-Xlet communication

Version 1.0 of the Personal Basis Profile was defined in JSR 129. More recently, the Personal Basis Profile 1.1 was introduced in JSR 217, which is still in progress.

Differences Between Personal Basis Profile 1.0 and 1.1
Version 1.1 is very similar to the original version. Existing APIs are being cleaned up. Enhancements are mainly centered on J2SE 1.4 support, including changes related to graphics and UI.

The Personal Profile
The Personal Profile is the new embodiment of the PersonalJava application environment, now at the end of its product life. The Personal Profile is a superset of the Personal Basis Profile and provides all the Java packages in both CDC and the Foundation Profile. It then adds heavyweight AWT classes and applet support missing from the Personal Basis Profile.

The Personal Profile thus provides a more complete application environment and looks very similar to Java SE. It is aimed at devices that require advanced UI and secure network connectivity, such as high-end PDAs, set-top boxes, and other high-end appliances. Table 7 summarizes the Personal Profile Java packages.

Name	Description

All packages in CDC, Foundation Profile, and Personal Basis Profile	See Table 2, Table 5, and Table 6
`java.applet`	Classes needed to create an applet, as well as classes that an applet uses to communicate with its applet context
`java.awt`	Adds the heavyweight AWT components: `Component`, `Menu`, `Button`, `Choice`, and so on
`java.awt.datatransfer`	Subset of interfaces and classes for transferring data between and within applications

Personal Profile 1.0 was defined in JSR 62. More recently, Personal Profile 1.1 was introduced in JSR 216, which is still in progress.

Differences Between Personal Basis Profile 1.0 and 1.1
Version 1.1 is very like version 1.0. Existing APIs are being cleaned up. Enhancements are mainly centered on J2SE 1.4 support, including changes related to graphics and UI.

For a handy comparison of APIs in CDC and its profiles to the corresponding Java SE interfaces, see the CDC API Comparison (PDF).

Optional Packages
Optional packages are very important components of the Java ME platform. You can look at them as profile extensions. They provide support in relatively narrow areas of functionality that some devices and applications need but others don't, such as messaging, multimedia, and location services.

With optional packages taking over such burdens, profiles can concentrate on supporting only those capabilities that most or all devices in a class need. Profiles can supply the runtime environment, while optional packages supply specific kinds of functionality, some of which were not even envisioned when the profiles were designed.

All Java ME optional packages are defined by the JCP, making them standard APIs. As the name implies, inclusion of these packages is optional. Some are mandatory, while others are conditionally mandatory as defined by the JCP. Still others are optional as defined by the handset manufacturers that may choose to include them in a particular product, or in extensible environments such as PDAs on which developers may elect to include them. For example, in a particular MIDP handset that has hardware support for Bluetooth, the Java APIs for Bluetooth (JSR 82) might be present.

The number of optional packages is increasing, with some for CLDC environments, some for CDC, and some for both. Some are already approved, and many new ones are in the definition phase. For this purpose, the MSA specification defines a common architecture and programming platform for wireless handsets. Two flavors of MSA are defined: the basic MSA that addresses CLDC-based platforms, and MSA-Advanced that addresses CDC-based platforms.

Java Card technology complements the Java ME platform. It slims down the Java platform for use within the severe memory and processing constraints of smart cards, a very specialized environment not suitable for general-purpose programming. A typical Java Card device has an 8- or 16-bit CPU running at 1 to 5 MHz and memory on the order of 1.2 K of RAM and 32 K of nonvolatile memory, typically EEPROM or flash.

The Java Card platform consists of the Java Card Virtual Machine, the Java Card Framework, security and remote invocation APIs, and Extension APIs, as illustrated in Figure 8.

The Java Card specification, in version 2.2.2 at this writing, includes a carefully chosen subset of the Java programming language. It does not support large primitive data types such as long, double, float, strings, dynamic class loading, multithreading, and other features characteristic of Java technology. Java Card technology comes in three parts:

The Java Card Development Kit provides a reference implementation of the runtime environment and the VM, as well as other tools to help you develop applications based on Java Card technology, commonly called Java Card applets.

Table 8 summarizes the Java technology APIs available in the Java Card specification.

Name	Description

`java.lang`	Subset of the Java SE core Java programming language for Java Card technology-based development
`java.rmi`	Base exception class and tagging interface for Java Card RMI functionality
`java.io`	Base `IOException` class to complete the RMI exception hierarchy
`javacard.framework`	Framework of classes and interfaces for the core functionality of a Java Card applet
`javacard.framework.service<`	Framework of classes and interfaces for a service-based Java Card applet
`javacard.security`	Classes and interfaces in the Java Card security framework
Extension APIs
`javacardx.apdu`	Extension API that enables support for ISO 7816 specification defined optional APDU-related mechanisms
`javacardx.biometry`	Extension API that contains functionality for implementing a biometric framework on the Java Card platform
`javacardx.crypto`	Extension API that contains functionality, which may be subject to export controls, for implementing a security and cryptography framework on the Java Card platform
`javacardx.external`	Extension API that provides mechanisms to access memory subsystems that are not directly addressable by the Java Card RE on the Java Card platform
`javacardx.framework.math`	Extension API that contains common utility functions for BCD math and parity computations
`javacardx.framework.tlv`	Extension API that contains functionality for managing storage for BER TLV formatted data, based on the ASN.1 BER encoding rules of ISO/IEC 8825-1:2002, as well as parsing and editing BER TLV formatted data in I/O buffers
`javacardx.framework.util`	Extension API that contains common utility functions for manipulating arrays of primitive components -- `byte`, `short`, or `int`
`javacardx.framework.util.intx`	Extension API that contains common utility functions for using `int` components

Java Card applets commonly include digital IDs and secure storage, and they are often found on subscriber identity module (SIM) cards that are inserted in cell phones to hold telephone and user account information.

Recently, Sun Microsystems introduced the concept of a protection profile, which defines a set of security requirements for the Java Card RE, the Java Card VM, the Java Card API Framework, and the on-card installer components. Its purpose is to help creators of Java Card technology-based products develop a secure Java Card platform and obtain high-level security certifications.

For more information on the most compact of the Java platforms, see the Java Card technology product page and read the three-part series titled "An Introduction to Java Card Technology": Part 1, Part 2, and Part 3.

The Java ME platform has been evolving into a complete runtime environment and numerous sets of APIs for developing Java technology-based applications for a wide variety of electronic devices.

Java technology began with an embedded programming language for consumer devices that was ahead of its time -- the small devices available then simply did not have enough capacity. Instead, Java technology became a desktop-based general-purpose programming language and then evolved into a platform particularly useful for server-based enterprise applications. The Java ME platform brings the power of Java technology back to PDAs, mobile phones, and other handheld and embedded devices.

At the heart of Java ME are the two configurations that define the core functionality of the platform for a family of devices: CLDC for the smallest devices and CDC for larger, more powerful devices. On top of the configurations, profiles add classes for building UIs, making network connections, and controlling application life cycles.

The three CLDC-based profiles are MIDP, IMP, and the Digital Set Top Box Profile. The three CDC-based profiles are the Foundation Profile, Personal Basis Profile, and Personal Profile. Java ME also includes optional packages, sets of APIs that extend profiles by adding specific functionality that only some devices and applications need.

Java Card technology is another Java platform in its own right, providing smart cards with a supercompact Java Card RE, VM, and programming interface.

C. Enrique Ortiz is a mobile technologist, software architect, developer, writer, and blogger. He has been author or co-author of many publications and is an active participant in the Java mobility community and in various Java ME Expert Groups.

Developers Home > Mobility > Reference > Technical Articles and Tips >