Java 2 Platform, Micro Edition (J2ME)

1. Java 2 Platform, Micro Edition (J2ME) Masha Gutkhen Keren Gazit

2. Contents • What’s J2ME? • J2ME core concepts • Configurations (CLDC, CDC) • Profiles (MIDP) • MIDlet, MIDlet Suite • Basic classes API • Installation and using the Toolkit • Demos!!!

3. Introduction • Personalized and intelligent information appliances are necessities in our life today. • Such appliances can be: • cell phones • two-way pagers • smart cards • personal organizers • palmtops • These appliances tend to be special-purpose, limited-resource, network-connected devices.

4. Environment requirements • We need an environment which is adapted for constrained devices - devices that have limitations on what they can do when compared to standard desktop or server computers. • The constraints are: • extremely limited memory • small screen sizes • alternative input methods • slow processors

5. So – what’s the solution? • Because of the vast need, Sun has decided to develop a special edition of Java - J2ME (Java 2 Micro Edition).

7. Java Editions • Different devices have different requirements and different expectations of Java. • One platform (solution) cannot address all the market segments (web server, video games etc.) • Users/developers want flexibility. They want to choose what they want to use and what they do not.

8. Java Editions • The Java 2 Platform is split into three editions. • Each edition provides a complete environment for running Java-based applications, including the Java virtual machine (VM) and runtime classes. • The three editions target different kinds of applications running on different kinds of devices.

9. Java Editions Java 2 Platform Java2 Standard Edition (J2SE™) Java2 Enterprise Edition (J2EE™) Java2 Micro Edition (J2ME™) Standard desktop & workstation applications Heavy duty server systems Small & memory constrained devices

10. J2EE J2SE J2ME Java Editions • Each edition defines different sets of class libraries. • There are thousands of core J2SE runtime classes, taking up to 10-20 megabytes of space. • J2ME-based devices have fewer classes.

11. PersonalJava and EmbeddedJava • J2ME is not the first attempt at adapting Java for constrained environments. • PersonalJava • Uses the basic Java 1.1 runtime classes with a few features from Java 2. • Implementation still requires a couple of megabytes of memory and a fast processor to run.

12. PersonalJava and EmbeddedJava • EmbeddedJava • Makes every behavior of the JVM and the runtime classes optional - the implementor can choose exactly which classes and methods are required. • The limitation: "write once, run anywhere".

13. J2ME Profile Profiles J2ME Libraries Configuration Java Language Java Virtual Machine Host Operating System J2ME Core Concepts • Configuration • Minimum platform required for a group of devices • Profile • Addresses specific needs of a certain device family • Optional Packages

14. J2ME Core Concepts J2ME is based on 3 core concepts: • Configurations • Profiles • Optional packages

15. Configurations • A configuration is a complete Java runtime environment, consisting of: • Java virtual machine (VM) to execute Java bytecode • Native code to interface to the underlying system • Set of core Java runtime classes • To use a configuration, a device must meet certain minimum requirements.

16. Configurations • The set of core classes is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by configuration implementor. • Configurations do not define any user interface classes.

17. Configurations Connected Limited Device Configuration Connected Device Configuration

18. CLDC vs. CDC • CLDC • For very constrained devices • 160 - 512 KB of total memory • 16-bit or 32-bit processor • Low power consumption and often operating with battery power • Connectivity with limited bandwidth • CDC • 2 MB or more memory for Java platform • 32-bit processor • High bandwidth network connection, most often using TCP/IP

19. CLDC vs. CDC - VM • Features missing in the CLDC VM: • Floating point types • Object finalization • JNI or reflection • Thread groups or daemon threads • User Class loaders • Change in classfile verification  preverification • The CDC supports a complete, full-featured Java 2 virtual machine

20. The KVM and CVM • KVM - Java virtual machines for the CLDC • CVM - Java virtual machines for the CDC • Written specifically to work in the constrained environment of a handheld or embedded device and to be easily ported to different platforms. • CLDC and CDC specifications do not require the use of the KVM or the CVM.

21. CLDC vs. CDC – J2SE Subset • The CLDC includes classes from: • java.lang • java.io • java.util • Only selected classes from each package are included • The CDC includes 17 packages • Includes more classes even in the shared packages

22. J2SE CDC CLDC CLDC vs. CDC – J2SE Subset

23. Handling I/O • J2SE includes many classes for performing input and output. • There are a large number of I/O classes and they tend to encapsulate I/O models that are not necessarily found on all devices. • For example, some handheld devices do not have file systems. Socket support is not universal, either.

24. Handling I/O in CLDC • The CLDC has define a new set of APIs for I/O called the Generic Connection Framework. • The GCF, part of the new javax.microedition.io package, defines interfaces for the different kinds of I/O that are possible. • The CLDC does not actually define any I/O implementations these are left to the profiles and/or the device vendor to define.

25. GCF - example import java.io.*; import javax.microedition.io.*; StreamConnection conn = null; InputStream is = null; String url = "socket://somewhere.com:8909"; try { conn = (StreamConnection) Connector.open( url ); is = conn.openInputStream(); .... // etc. etc. } …

26. Handling I/O in CDC • Since the CDC is a superset of the CLDC, it includes the GCF. • CDC also requires GCF support for two specific connection types: files and datagrams. • The reason: CDC includes the relevant classes from java.io and java.net packages.

27. J2ME Core Concepts J2ME is based on 3 core concepts: • Configurations • Profiles • Optional packages

28. Profiles • Adds domain-specific classes to a configuration: • To fill in missing functionality • To support specific uses of a device • Most profiles define user interface classes for building interactive applications. • To use a profile, the device must meet the minimum requirements of the underlying configuration and of the profile.

29. Profiles Mobile Information Device Profile Personal Digital Assistant Profile Foundation Profile Personal Basis Profile Personal Profile

30. MIDP – MID Profile • MIDP is targeted at a class of devices known as mobile information devices (MIDs). • Minimal characteristics of MIDs: • Enough memory to run MIDP applications • Display of at least 96 X 56 pixels, either monochrome or color • A keypad, keyboard, or touch screen • Two-way wireless networking capability

31. MIDP - Specification • There are two versions of the MIDP: • MIDP 1.0 - released in September 2000. Many devices currently on the market support it. • MIDP 2.0 - currently in proposed final draft form. No devices yet support it.

32. MIDP - Specification • The MIDP adds APIs to the basic APIs defined by the CLDC. The new features include: • Support for application lifecycle management similar to the way applets are defined in J2SE. • Persistent storage of data. • HTTP-based network connectivity based on the CLDC's GCF. • Simple user interface support, with enough flexibility to build games or business applications.

33. MIDP - Specification • The MIDP specification is silent about a number of things: • No standard way to interface to the device's phonebook, in order to initiate voice calls. • How MIDP applications are loaded onto a device and how they are activated or deactivated.

34. MIDP Applications restrictions • Memory is a particularly scarce resource. • The early Motorola J2ME-enabled phones limited the size of an application to 50K. Some Nokia phones limit them to even less, about 30K. • MIDP 1.0 applications cannot share classes. • Placing part of the application in a web or application server (as a servlet, typically) that the MIDP application calls is almost a requirement for anything serious.

35. J2ME Core Concepts J2ME is based on 3 core concepts: • Configurations • Profiles • Optional packages

36. Optional Packages • Set of APIs in support of additional, common behaviors. • Have specific dependencies on a particular configuration and/or one or more profiles. • Examples of optional packages : • RMI Optional Package • Bluetooth Optional Package • JDBC Optional Package

37. What it all means • "J2ME application" is an ambiguous term. • Configuration, profile and optional packages should be chosen. • CDC-based profiles make development simpler due to J2SE-like APIs, but don’t suit the low-end devices. • CLDC-based profiles makes the development task harder, especially when trying to shrink the size of the application to run on many of the small devices.

38. Start working...

39. MIDlets – The heart of J2ME… • MIDP does not support the running of applications that use a static main method as their entry point, nor calling the System.exit method in order to terminate. • Instead, we use a MIDlet, which is a MID Profile application.

40. MIDlets – The heart of J2ME… • Every application must extend javax.microedition.midlet.MIDletclass to allow the application management software to: • control the MIDlet • be able to retrieve properties from the application descriptor • notify and request state changes

41. MIDlets – The heart of J2ME… • The extending class is the main class of the application. • The MIDlet class defines abstract methods that the main class implements (for example: startApp(), destroyApp(), notifyDestroyed()).

42. MIDlet Suite • One or more MIDlets are packaged together into a MIDlet suite, composed of: • JAR (Java archive) file • JAD (Java Application Descriptor) file • All the user-defined classes and resources required by the suite's MIDlets must be in the JAR file.

43. MIDlet Suite • The JAR file must also include a manifest that describe the MIDlets in the suite. • The application descriptor (JAD) contains similar information, and is used by devices to obtain information about a MIDlet suite without having to download and install the MIDlet suite first.

44. Creating a MIDlet

45. Creating a MIDlet Importing MIDP specific packages import javax.microedition.lcdui.*; import javax.microedition.midlet.*;

46. Creating a MIDlet Extends MIDlet Implements CommandListener public class HelloMIDlet extends MIDlet implements CommandListener {

47. Creating a MIDlet Creating the form, adding the Commands public HelloMIDlet() { mMainForm = new Form("HelloMIDlet"); mMainForm.append(new StringItem(null, "Hello, Seminar Software Design!")); mMainForm.addCommand(new Command("Exit", Command.EXIT, 0)); mMainForm.setCommandListener(this); }

48. Sample MIDP classes API • MIDlet • Form • Command • CommandListener • ItemCommandListener • Item

49. Sample classes API • MIDlet – Base class • Form • Command • CommandListener • ItemCommandListener • Item

50. MIDlet class API • protected abstract void startApp() • protected abstract void pauseApp() • protected abstract void destroyApp(boolean unconditional) • public final String getAppProperty(String key) • public final void notifyDestroyed()