1 / 24

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)

kieu
Download Presentation

J2ME

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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)

More Related