Java 2 Micro Edition

Java 2 Micro Edition (J2ME) was Sun Microsystems’ version of the Java platform for devices too small to run desktop Java: mobile phones, pagers, personal organizers, set-top boxes and embedded controllers. It was not a new language. It kept Java’s syntax, static typing, classes and garbage collection, but defined smaller virtual machines and smaller class libraries, and split the device market into configurations and profiles so each class of hardware got only the APIs it could support. For most of the 2000s the combination of the Connected, Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP) was the most common way to write a downloadable application for a feature phone. On many phones of that period, the games and utilities sold through carrier portals were MIDlets. Sun renamed the platform Java ME in 2005.

History & Origins

From PersonalJava to Micro Edition

By 1999 Sun already had two Java variants for small machines, PersonalJava and EmbeddedJava. Both were trimmed-down versions of desktop Java and still needed more memory than a phone or pager had. At the JavaOne conference in San Francisco in June 1999, Sun reorganized Java 2 into three editions: Standard Edition, the newly launched Enterprise Edition, and Micro Edition for consumer and embedded products. Computer Business Review summed up the announcement on 15 June 1999 with the headline “Sun Changes Low-End Strategy With Java Micro Edition.”

The centre of the announcement was a new virtual machine, the K Virtual Machine (KVM), previously called the KJava VM. Computer Business Review reported that it was built in cooperation with Motorola and that companies including 3Com, Groupe Bull, Fujitsu, Matsushita, Mitsubishi Electric, NEC, NTT DoCoMo and Siemens had also contributed. Sun and 3Com announced the same day that the Palm OS would be “a primary reference platform for application development using KVM,” and attendees could buy a Palm V at a special price with a developer release of the KVM on it.

Spotless

The KVM came out of Sun Labs. Sun’s May 2000 white paper on the KVM and CLDC says that “the KVM is derived from a research system called Spotless developed originally at Sun Microsystems Laboratories,” and points readers to Sun Labs technical report SMLI TR-99-73, The Spotless System: Implementing a Java System for the Palm Connected Organizer. Antero Taivalsaari, who according to his publisher’s biography co-founded the Spotless project and designed the original KVM, became the specification lead for the first J2ME standard.

Standardization through the JCP

J2ME was defined through the Java Community Process, and most of its pieces are numbered JSRs:

The CLDC expert group shows who had a stake in it. The JCP’s page for JSR 30 lists AOL, Bull, Fujitsu, HiddenMind, Matsushita, Mitsubishi Electric, Motorola, Nokia, Oracle, Research In Motion, Samsung, Sharp, Siemens, Sony, Sun and Symbian. The MIDP 1.0 group added carriers and handset makers such as Ericsson, Hitachi, KDDI, NEC and SoftBank Mobile (the JCP shows members under their current names), and its specification lead was Brian Deuser of Motorola.

Design Philosophy

Configurations and profiles

J2ME’s main idea was that “Java everywhere” could not mean the same Java everywhere. Sun’s 2000 white paper describes three layers on top of the device’s own operating system:

• A virtual machine customized for the device and its host OS.
• A configuration, which defines the minimum virtual machine features and core class libraries for a broad, “horizontal” category of devices. The white paper calls it the “lowest common denominator” of the platform.
• A profile, layered on a configuration, which adds the APIs a particular “vertical” device family needs, such as user interface, persistence and application lifecycle.

Applications are written for a profile and are, in principle, portable to any device that supports it. Two configurations came to matter:

• CLDC for small, battery-powered, intermittently connected devices. The white paper puts the target at 160 kB to 512 kB of total memory, with “a more typical implementation” using 256 kB: half for application heap, 40 to 80 kB for the virtual machine, and the rest for class libraries.
• CDC for devices with “a sufficient 32-bit microprocessor and ample memory” (JSR 36), such as set-top boxes and communicators. It carried the Foundation, Personal Basis and Personal profiles, the successors to PersonalJava.

Small enough to fit

The KVM was designed, in the white paper’s words, to be “small, with a static memory footprint of the virtual machine core in the range of 40 kilobytes to 80 kilobytes (depending on compilation options and the target platform).” That is a design target for the VM’s static size, not a benchmark. The “K” stands for kilobytes. The KVM was written in C around a straightforward bytecode interpreter, so it could be ported to any platform with a C compiler. Sun’s reference implementation built on Solaris and Windows, with Palm OS as a third, test-bed port.

Key Features

What CLDC 1.0 left out

To reach those sizes, CLDC 1.0 removed parts of the Java language and virtual machine. The 2000 white paper lists:

• No float or double types
• No Java Native Interface (JNI)
• No user-defined class loaders
• No reflection
• No thread groups or daemon threads
• No finalization (Object.finalize() does not exist)
• No weak references
• Limited error handling, with most java.lang.Error subclasses unsupported

The lack of floating point is the restriction people remember. Early MIDlet games did their physics and 3D maths in fixed-point integers. JSR 139’s stated aim was to make CLDC “compliant with the Java Language and Virtual Machine Specifications by possibly reintroducing features such as floating point support,” and CLDC 1.1 (2003) did bring float and double back.

Pre-verification

Full Java bytecode verification was too expensive for a phone, so CLDC split it in two. On the developer’s workstation, a preverifier added a “stack map” attribute to each class file. On the device, a much simpler verifier used those stack maps to check the code quickly. Sun’s white paper shows the pipeline as MyApp.java → javac → preverifier → download → verifier → interpreter. Later versions of desktop Java adopted the same stack-map approach.

MIDlets

A MIDP application is a MIDlet, a class that extends javax.microedition.midlet.MIDlet. The phone’s application manager drives it through startApp(), pauseApp() and destroyApp(), because a phone call can interrupt a game at any moment. Applications were packaged as a JAR plus a small text descriptor, the JAD file, which carried attributes such as MIDlet-Name, MIDlet-Version, MIDlet-Jar-Size, MicroEdition-Profile and MicroEdition-Configuration, so a phone could check an application before downloading it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

import javax.microedition.midlet.MIDlet;
import javax.microedition.lcdui.Command;
import javax.microedition.lcdui.CommandListener;
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.Form;

public class HelloMIDlet extends MIDlet implements CommandListener {
    private final Form form = new Form("Hello");
    private final Command exit = new Command("Exit", Command.EXIT, 1);

    public HelloMIDlet() {
        form.append("Hello, World!");
        form.addCommand(exit);
        form.setCommandListener(this);
    }

    protected void startApp() {
        Display.getDisplay(this).setCurrent(form);
    }

    protected void pauseApp() {
    }

    protected void destroyApp(boolean unconditional) {
    }

    public void commandAction(Command c, Displayable d) {
        if (c == exit) {
            destroyApp(false);
            notifyDestroyed();
        }
    }
}

There is no main method. The user interface comes from javax.microedition.lcdui, MIDP’s own toolkit. It offers a high-level layer of screens, forms, lists and abstract commands that each handset maps to its own soft keys, and a low-level Canvas for games. Persistent data goes into the Record Management System (javax.microedition.rms), a store of byte-array records, because a phone could not be assumed to have a file system.

MIDP 2.0

MIDP 2.0 (JSR 118, November 2002) made the platform suitable for commercial games and network applications. Its API reference adds javax.microedition.lcdui.game (sprites, tiled layers and a game canvas), javax.microedition.media (a sound subset of the Mobile Media API), and javax.microedition.pki (certificates). The JSR also called for a push architecture that routes incoming messages to MIDlets, HTTPS and socket networking, and a domain security model based on signed applications. Signing mattered to carriers: an unsigned MIDlet would prompt the user before using the network, while a signed one could be trusted with more.

Optional packages and umbrella specs

Many capabilities came as separately numbered optional APIs (messaging, multimedia, Bluetooth, 3D graphics, location and others), and each handset chose which to implement. This caused fragmentation. Developers often shipped dozens of builds of the same game for different screen sizes, key layouts and API sets. JSR 185 (JTWI, 2003) and JSR 248 (MSA, 2006) tried to fix this by specifying a required bundle. JTWI’s JSR page lists MIDP 2.0, CLDC 1.1, the Wireless Messaging API and the Mobile Media API as its components.

Evolution

• 1999-2000: Announcement, KVM, CLDC 1.0, MIDP 1.0.
• 2001: Java phones reach the market. NTT DoCoMo’s i-appli service starts in Japan in January on a CLDC-based platform with its own DoJa profile. In April, Motorola’s i85s and i50sx become the first MIDP-certified phones on North American iDEN networks.
• 2002-2003: MIDP 2.0 and CLDC 1.1. The CDC family (Foundation, Personal Basis and Personal profiles) replaces PersonalJava for larger devices.
• 2005: At JavaOne in June, Sun announces it will drop the “2” from its platform names, and J2ME becomes Java ME. Sun reportedly also discouraged the abbreviation “JME” in favour of “Java ME.”
• 2006-2009: MSA and MIDP 3.0. MIDP 3.0 took almost five years from JSR ballot (March 2005) to final release (December 2009). By then smartphone platforms with their own application models were displacing MIDP on new high-end phones.
• 2010 onwards: Oracle acquired Sun in January 2010, and its later Java ME work centred on embedded devices. CLDC 8 (April 2014) brought the language level closer to Java SE 8, with enums, compile-time-only annotations and generic collections. MEEP 8, released the same day, updated the earlier IMP-NG embedded profile “to align with state-of-the-art features and current embedded device market requirements.” Java ME Embedded 8.3 followed in 2016, with reference binaries for boards such as the Raspberry Pi.

Current Relevance

As a phone platform, J2ME is historical. Smartphone operating systems with their own application models replaced it, and the carrier storefronts that sold MIDlets are gone. The specifications remain on jcp.org, and Oracle still hosts Java ME documentation and the Java ME SDK.

The software is still around in two places. Emulators and preservation projects keep 2000s MIDlet games playable, since for many players those were their first mobile games. And the CDC branch lives on wherever Blu-ray players run BD-J discs, whose interactive menus are Java ME Xlets on the Personal Basis Profile.

Why It Matters

J2ME was one of the first serious attempts at a portable application platform for mobile phones, and among the first to deliver downloadable third-party software to mass-market handsets. It established ideas that later mobile platforms reused in their own forms: an application lifecycle controlled by the system rather than the program, packaging with a descriptor that could be checked before download, permissions tied to code signing, and distribution through an operator or store rather than by copying files.

It also showed the limits of “write once, run anywhere” on fragmented hardware. A shared language and virtual machine did not make phones with different screens, keypads, memory limits and optional APIs behave the same, and JTWI and MSA did not fix that in time. The configuration-and-profile split did hold up, though. It let a single language reach from phones with a memory budget of a few hundred kilobytes up to set-top boxes and disc players.