J2MEOverviewWhat is J2ME?ConfigurationsSlide 5Slide 6ProfilesCLDC ProfilesCDC ProfilesCLDC ConfigurationCDC ConfigurationOther small Javas (all based on Java 1.1)The CLDCCLDC specificationsCLDC class loadingCLDC securityCLDC sandboxMIDP and MIDletsMIDP requirementsMIDP java platformMIDletsMIDlet suiteMIDlet suite securityMIDlet executionJ2ME25 July 2002OverviewWhat is J2ME?The CLDC and CDC configurationsMIDP and MIDletsDevelopment ToolsDemonstrationsWhat 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 serversConfigurations 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 supportsConfigurations 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 CLDCProfiles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 configurationCLDC 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 profileCLDC ConfigurationCLDCMIDP PDAPCDC ConfigurationCDCRMIgamefoundationfoundationpersonalPersonal basisOther 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 JVMThe 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 JNICLDC 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 runtimeMIDP 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 propertyMIDlets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 portabilityMIDlet 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 synchronizationMIDlet 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 APIMIDlet 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