Created By Bob Mussar

            While not necessarily mutually exclusive to the WAP architecture, Java does offer some alternatives to the WAP protocol stack. Java can be used to run applications called MIDlets on wireless devices or can be used with WAP to produce WML on backend servers using JSP and Servlets. This article will deal mainly with creating and deploying MIDlets on small wireless devices.

             In order for Java to run on the limited resources of a typical cell phone, the Java Mico Edition (J2ME) platform was created. This platform consists of a Connected Limited Device Configuration (CLDC), Mobile Information Device Profile and a striped down Java Virtual Machine (the KVM). We will examine each of these components below and the give a commented example of some simple code that can be run on a Java enabled phone.

 

                                             

                               Fig.1 Targeted device type for each platform.                                                                             (http://java.sun.com/products/cldc/wp/KVMwp.pdf )

 

Kilobyte Virtual Machine or KVM

 

            The KVM  was developed as a functional but smaller version of the JVM to run on mobile devices such as cell phones, pagers and organizers. It was written in C and will compile to a memory footprint of 40 to 80 KB.  (hence the name) depending on compiler options and the intended device. It was originally design for Palm Organizers but Sun claims it can run on 25 different platforms including phones by Motorola, Nokia, LG Electronics, Nextel and NTT DoCoMo. The illustration above demonstrates the target devices for the KVM and CLDC and relative sizes of the JVM/KVM memory requirements. [Source: http://java.sun.com/products/cldc/wp/KVMwp.pdf ]

 

 

Connected Limited Device Configuration (CLDC)

 

            Configurations are aimed at a similar set of devices. Currently there are two standard configurations the CDC and the CLDC. The CDC is intended for slightly larger devices such as Internet TVs set-top boxes, and car navigation systems.

 

            The CLDC defines what Java libraries, API’s and Java language features are supported by the KVM. CLDC libraries consists of classes and interfaces inherited from standard J2SE libraries such as java.lang, java.io, and java.util, and also CLDC specific classes and interfaces such as the javax.microedition package which deals mostly with networking and security.

            Because of resource limitations, the CLDC does not support the following standard J2SE features: [Source: http://java.sun.com/products/cldc/wp/KVMwp.pdf]

·    No floating point support:

·    No finalization:

·    Limited error handling

·    No Java Native Interface (JNI):

·    No user-defined class loaders: 

·    No support for reflection, hence no RMI or object serialization.:

·    No thread groups or daemon threads (although multithreading is supported just not thread groups): 

·    No weak references: 

          To further reduce the responsibilities of the KVM the CLDC also implements the idea of a class preverifier.  This design calls for the expensive standard Java class verification process to be done on the server before the class files are download to the device which now will simply check that the class files have been verified.

                                               

            Further information on the KVM and CLDC can be found on the web at Sun’s http://java.sun.com/products/cldc / site and at http://java.sun.com/products/cldc/wp/KVMwp.pdf for the white paper.

 

Mobile Information Device Profile (MIDP)

·                A profile is a set of domain-specific classes. Specifically the MIDP classes provide the programmer with the ability to create or change behavior on the device.  The MID profile consists consist of the following packages: [Source: http://java.sun.com/products/midp/#finalspec ]

·          javax.microedition.rms: (for Record Storage System) This package contains of class methods that can persist data between MIDP application runs. Data is saved by unique primary keys in device specific locations called record stores. The record store can be access through the RecordStore class. This class provides methods to save, delete, compare and enumerate through the records. Examples can be found on the web at: http://developer.java.sun.com/developer/technicalArticles/wireless/midpdatabase

·          javax.microedition.io.HttpConnection: This package extends the CLDC  javax.microedition.io GenericConnection framework and provides an interface for creating HTTP connections. This will allow MIDlets to set HTTP request methods such as POST, or GET and also to set HTTP properties such as the User-Agent or Content-Language. In the case of downloading another MIDlet  setRequestProperty("User-Agent", "Profile/MIDP-1.0 Configuration/CLDC-1.0") would be used.  More can be found on MIDP HTTP connections at http://developer.java.sun.com/developer/technicalArticles/wireless/midpnetwork/index.html

·          javax.microedition.lcdui: This package consists of over twenty classes that define the GUI interface. The J2SE graphic packages AWT and Swing are not used in this implementation because of the limited resource of a mobile device and also because of the vast differences between a phone user interface and a desktop interfaces. More can be found on this package at http://developer.java.sun.com/developer/technicalArticles/wireless/midpui

·          javax.microedition.midlet: MIDlets provide the interface between the device environment and the MIDP applications, that is an application must extend the MIDlet interface in order to be run by the device’s application management software. MIDlets can be compared to Applets in that they both have standard lifecycles defined by state methods such as Paused, Active and Destroyed.

            Since it is usually best to see an example I’ve include a sample MIDlets below to illustrate how MIDlets are coded. This is the classic HelloWorld example in MIDlets form with my comments. [Source: http://developer.java.sun.com/developer/technicalArticles/wireless/midp/index.html]

 

// MIDlet.* needs to be included for the lifecycle methods.

import javax.microedition.midlet.*;   

import javax.microedition.lcdui.*;     // gui package containingTextBox

 

/* All MIDP applications must extend MIDlet.

    CommandListener is implemented so that this MIDlet can respond to command events    as defined by the addCommand method */

public class HelloWorld extends MIDlet   

                                 implements CommandListener {

 

// Instance Variables.

  private Command exitCommand;

  private Display display;

  private TextBox t = null;

 

// Constructor.

 public HelloWorld() {

 

/* Create a Display object, this object has methods to gather device specific information and make a lcdui component visible  */

    display = Display.getDisplay(this);

 

/* Create a TextBox which is a lcdgui component patterned after the AWT components TextArea and TextField .   */

    exitCommand = new Command("Exit", Command.EXIT, 2);

    t = new TextBox("Hello MIDlet",

                            "Test string",

                            256, 0);

 

/* Add the Exit command to the TextBox area and finally create a listener for the ExitCommand to create a callback when the exit command is clicked. */

    t.addCommand(exitCommand);

    t.setCommandListener(this);

  }

 

  /* The startApp method is initially invoked by the application management software.

       We simply call our Display object’s setCurrent method to display the TextBox created in the constructor  */

 public void startApp() {

    display.setCurrent(t);

  }

 

  /* The pauseApp method is not implemented here but can be called to temporarily release resources. */

  public void pauseApp() {

  }

 

 /* Also not implemented here, but destroyApp always called when a MIDlet is terminated. This can be used to do any final cleanup. */   

  public void destroyApp(boolean unconditional) {

  }

 

/* commandAction is called when any command is invoked. The code below is need to determine which command was selected. The notifyDestroyed() command lets the application management software know the MIDlet is in the destroyed state. */

  public void commandAction(Command c, Displayable s) {

    if (c == exitCommand) {

      destroyApp(false);

      notifyDestroyed();

    }

  }

}

 

Testing MIDlets

            In order to compile and test a MIDlet you will need to install the MIDP and CLDC environment on the host machine. Downloads and instructions can be found at this site:

http://developer.java.sun.com/developer/technicalArticles/wireless/midpsetup/index.html .

 

            Once this environment has been installed the MIDlet is first compiled into a .class file like any other Java source code with the javac command.

i.e. c:> javac HelloWorld.java

            Next the output from the javac command, the .class files will need to be preverified, remember that this is the step designed to make less work for the KVM on the mobile device by doing the byte code verification on the host machine. The preverifier command looks like this:

c:>preverify HelloWorld.class

This command will create a preverified .class file with the same name into a default directory of “\output” under the current directory unless overridden with the ‘pathTO’ command.

The preverified .class file can now be used as input into the midp executable with the following  command:

c:> midp HelloWorld

This command will launch the midp test application and create a sample display like the one below.

                                                  

                                               Fig 2.Output of sample code.

      http://developer.java.sun.com/developer/technicalArticles/wireless/midp/index.html

 

 Notice that the position of our test messages is dependent on the order in which they were entered when we created our TextBox. The “Hello MIDlet” string is placed in the Title area of the TextBox, while “Test String” is in the main body. The command area is always at the bottom where “Exit” is displayed.

 

Distributing MIDlets

 

            Once a MIDlet, or more typically a group of MIDlets, has been debugged they should be packaged in the compressed JAR format to make distribution more efficient. As with any JAR file, a text Manifest file also needs to be created to describes the contents of the JAR file. However in the MIDlet environment all Manifest attributes begin with  the string “MIDlet” and the file extension must be .jad (Java Application Descriptor).

Below is a sample .jad file for our HelloWorld example.

 

MIDlet-Name: HelloWorld

MIDlet-Version: 1.0.0

MIDlet-Vendor: Sun Microsystems, Inc.

MIDlet-Description: Hello World MIDlet

MIDlet-Info-URL: http://java.sun.com/j2me/

MIDlet-Jar-URL: HelloWorld.jar

MIDlet-Jar-Size:    1063

MicroEdition-Profile: MIDP-1.0

MicroEdition-Configuration: CLDC-1.0

MIDlet-1: HelloWorld,, HelloWorld

 

            If more than one MIDlet is to packaged together then the additional MIDlets can be named with additional MIDlet-1: attributes which would now read MIDlet-2: or -3 depending on the number of MIDlets added. Specific details for Manifest requirements and options can be found in the Mobile Information Device Profile, which can be downloaded from http://java.sun.com/products/midp/index.html .

            Once a .jad file has been created it can be tested with the midp command the same as a preverified MIDlet can . In this case however the ‘-descriptor’ parameter must be used as shown below.

c:> midp -descriptor HelloWorld.jad

            The .jad file can now be deployed onto a HTTP web server. If the server is configured with the correct mime-type (text/vnd.sun.j2me.app-descriptor jad) then the .jar can be downloaded and run from any device that can create a HTTP connection and run a MIDlet application.

            Since the HTTP connection is implemented with the MID profile, MIDlets can download other MIDlets or text files without using any intermediaries, such as in the WAP environment, a WAP gateway. (illustrated below.)

 

 

 

            

Fig 3. Typical Wap/I-mode vs. Java connections.

(http://developer.java.sun.com/developer/technicalArticles/wireless/midpnetwork)

 

References:

 

·        http://java.sun.com/products/cldc/wp/KVMwp.pdf : KVM White Paper.

·        http://java.sun.com/products/cldc : Overview of  CLDC specifications.

·        http://java.sun.com/products/midp/#finalspec : Downloadable version of MIDP specifications.

·        http://developer.java.sun.com/developer/technicalArticles/wireless/midpdatabase : Specifically dealing with J2ME RMS

·        http://developer.java.sun.com/developer/technicalArticles/wireless/midpnetwork: Networking and the HTTP connection framework.

·        http://developer.java.sun.com/developer/technicalArticles/wireless/midpui : Information on GUI programming with the J2ME.

·        http://developer.java.sun.com/developer/technicalArticles/wireless/midpgetstart/index.html : Overview of MIDlet programming.

·        http://developer.java.sun.com/developer/technicalArticles/wireless/midpsetup/index.html : Specific instructions on how to setup the MIDP environment.

·        http://developer.java.sun.com/developer/technicalArticles/wireless/midp/index.html

·        http://java.sun.com/products/midp/index.html : Overview of  MIDP specifications

 

 

Other Resources:

 

·        http://java.sun.com/products/j2mewtoolkit : Site to download the JavaTM 2 Platform Micro Edition, Wireless Toolkit. This is a set of software tools to help create and debug MIDlets. It includes a wireless emulator, the Forte Java IDE, the MIDP and the CLDC. 

·        http://www.kvmworld.com : Recently changed its name to the “Micro Java Network”. Owned by the MicroDevGroup, this site features articles and news relating to Java and the wireless world in general.

·        http://java.oreilly.com/bite-size/java_0300.html : Good non-Sun overview of building J2ME applications for the PalmOS. In the Palm environment Spotlets are used instead of MIDlets.

·        http://www.javaworld.com/javaworld/jw-09-1999/jw-09-kvm.html : Review and overview of J2ME as demonstrated at demonstrated at the JavaOne conference using the Palm Spotlets model as an example.

·        http://www.jguru.com/jguru/faq/faqindexbytopic.jsp?faq=J2ME : FAQ covering MIDlet and Palm applications.

·        http://www.javaworld.com/javaworld/jw-01-2001/jw-0105-midp.html: Example of creating a HelloWorld MIDlet using the J2ME Wireless Toolkit.

·        http://java.sun.com/features/2001/01/motorola.html : Future development for game applications using J2ME

·        http://www.javaonthebrain.com/java/midpman : A not so optimistic view of J2ME’s gaming possibilities.