1. J2ME 25 July 2002

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

3. 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

4. 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

5. 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)

6. 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

7. 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

8. 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)

9. 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

10. CLDC Configuration CLDC MIDPPDAP

11. CDC Configuration CDC RMI gamegame foundation personal Personal basis

12. 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

13. 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,…

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

15. 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)

16. 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”

17. 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

18. 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)

19. 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”

20. 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

21. 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

22. 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

23. 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

24. 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)