J2ME 25 July 2002

Overview  What is J2ME?  The CLDC and CDC configurations  MIDP and MIDlets  Development Tools  Demonstrations

What is J2ME?  Java implementation for devices that cannot support full Java 1.3 (J2SE)  Ironic: Java was initially developed for use in portable,embedded systems  Examples: PDA’s, mobile phones, very small servers (Tini), webpads  The family also includes J2EE for servers

Configurations  A configuration defines a class of devices in hardware terms: type and speed of processor, memory size, type of network connection  Consists of a virtual machine specification for the configuration and a set of java classes that the configuration supports

Configurations  Two configurations currently defined  CLDC = low-end consumer electronics device, 512K RAM, e.g. mobile phone (currently also PDA’s)  CDC = device with circa 2MB RAM (high end PDA’s, set-top boxes, 3G phones)

Configurations  Particular virtual machine is NOT part of the spec, but the reference designs tend to get used  For CLDC, the Kilobyte (KVM) virtual machine implements the configuration  CVM implements CDC specification for Linux and Wind River VxWorks  Other VM’s exist, eg. IBM J9 for CLDC

Profiles  A profile consists of a set of classes that extend a configuration to add particular functionality  There are profiles to extend CLDC, different profiles to extend CDC  Profile can depend on another profile for functionality, as well as on the configuration

CLDC Profiles  MIDP = mobile information device profile: display and storage for mobile phones, network connection based on http v1.1. Code for MIDP devices called “MIDlets”  PDAP = better screen and more memory (not implemented)

CDC Profiles  Foundation Profile = includes almost all core java 2 v1.3 classes.  Personal Basis Profile = basic user interface profile (written?)  Personal Profile = adds multi-window user interface functionality to personal basis profile (written?)  RMI profile, Game profile

CLDC Configuration CLDC MIDPPDAP

CDC Configuration CDC RMI gamegame foundation personal Personal basis

Other small Javas (all based on Java 1.1)  JavaCard (smartcard, e.g. GSM SIM card, French phone card, 16K RAM)  EmbeddedJava -- allows class-by-class definition of device capabilities  PersonalJava -- v1.1.8, devices such as iPaq, Nokia 92xx communicator, full feature JVM

The CLDC  Assumes 128KB of flash or battery backed persistent storage  32KB volatile storage  Assumes no display or input device  Assumes only that the OS can run the VM (e.g. KVM). Could be PalmOS, BREW, NOS,…

CLDC specifications  No floating point (NB there is no separate J2ME compiler)  No reflection  No finalization  Limited multithreading  Limited error reporting  No JNI

CLDC class loading  Class loading mechanism provided by the implementation and cannot be extended by application code  Must support compressed.jar files  Can convert to whatever internal format is needed (e.g..prc)

CLDC security  CLDC devices range from those on which no new code can be loaded at all by user to those in which code can be downloaded from untrusted sources  Not enough computational power for J2SE security model  Application code runs in a “sandbox”

CLDC sandbox  Application code cannot create its own class loaders  Application cannot substitute its own classes for core java or javax.microedition classes  No JNI, hence no native code except that installed with the VM  Preverification of class files on host before download, used to assist bytecode verification at runtime

MIDP and MIDlets  CLDC by itself is more limited than most handheld devices  MIDP extends CLDC to include a simple UI  Runs on KVM  PDAP intended for PDA’s, but currently MIDP being used for them (e.g. Palms)

MIDP requirements  128KB RAM (vs. 32KB for CLDC)  Additional 32KB for Java heap  8KB nonvolatile storage  96x54 pixel display  Input device that can enter 0-9, arrow keys, select  Support http 1.1 “in some way”

MIDP java platform  CLDC packages plus stuff in javax.microedition and timer in java.util  MIDlet more restricted than application  MIDlet cannot halt the VM  MIDlet does not enter at main()  Device must set microedition.locale property  Must also set microedition.profiles property

MIDlets  Must contain at least one class derived from javax.microedition.midlet.MIDlet  A number of methods must be implemented by the MIDlet so it will run in the sandbox  Must use only API’s from the MIDP specification for portability

MIDlet suite  Set of MIDlets installed/removed as a group that can access device resources in shared manner  All MIDlets in a suite run on same VM, share same instances of classes and resources (share data)  Usual java primitives for synchronization

MIDlet suite security  MIDlets in a suite can access persistent storage in a shared fashion -- no access across suites to persistent storage (security and namespace issues)  No authentication (SecurityManager) as in J2SE  Some protections against malicious MIDlets in the limited API

MIDlet execution  Must have default public constructor  3 states: paused, active, destroyed  Upon loading, constructor runs, and then MIDlet is paused  Upon becoming active, runs method startApp()  May later pause, then become active again, later be destroyed, etc. (pauseApp, destroyApp methods)