slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
J2ME PowerPoint Presentation


391 Vues Download Presentation
Télécharger la présentation


- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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 configurationdefines 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 MIDP PDAP CLDC

  11. CDC Configuration RMI personal game Personal basis foundation foundation CDC

  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)