J2ME

							 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



  MIDP      PDAP




         CLDC
        CDC Configuration


      personal                 g
                   RMI         a
Personal basis                 m
                               e

                  foundation
                 foundation

                   CDC
        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)