As a programmer, you probably know that the first program you ever write when
you are learning a new language is displaying the famous words, 'Hello
World". This was the first program that the founders of the great C
language introduced when they introduced the C language to the world.
Here is the MIDP version of the inveterate "Hello
World" program. The following J2ME code sample shows the source code for the first version of the HelloWorld
//This is the MIDP version of the familiar HelloWorld
Creates the "Hello world" program in J2ME MIDP.
Note that the class must be public so that the device
application management software can instantiate it.
public class HelloWorld extends MIDlet
// The Displayable. This component is displayed on the
private Form form;
// The Display. This object manages all Displayable
private Display display;
// A public no-arg constructor is necessary, even though
// the system calls startApp()! The AMS calls the
// class's no-arg constructor to instantiate the class.
// Either create a public no-arg constructor, or declare
// no constructors, and let the compiler create a public
// no-arg constructor.
public void destroyApp(boolean destroy)
form = null;
public void pauseApp()
public void startApp()
// Create a Displayable widget.
form = new Form("Hello, World");
// Add a string to the form.
String msg = "My first MIDlet!";
// This app simply displays the single form created
display = Display.getDisplay(this);
First, notice that this application defines a class called
HelloWorld, which extends javax.microedition.midlet.MIDlet. All MIDlets must extend this
class. The HelloWorld class is the primary class of your application.
For this reason, it must be declared public. Moreover, you must declare a public no-argument
constructor, or ensure that there are no constructors, in which case the compiler will
define a no-argument constructor for you. Readers who are familiar with Java applets will recognize
the similarity between the applet and MIDlet lifecycle control models.
In the program above, the startApp(), pauseApp(), and destroyApp() methods override abstract declarations from the
MIDlet class. Notice that all the initialization code goes in the startApp() method rather
than in the constructor. You certainly can put some initialization code in your constructor;
it will be executed before the call to startApp(). However, the startApp() method is always called as
the entry point for your MIDlet.
What about a main() method? The Java language definition
requires all Java applications to have a main() method with the following signature:
public static void main(String  args)
If J2ME applications are real Java applications, then there must be a main method somewhere that is the real entry point used by the
VM to start the process of executing the application. In fact, there is such a method. It's
part of the MIDP implementation (not the application), and, typically, the AMS software calls
it. The AMS handles application invocation requests, for instance, by spawning a thread for each
MIDlet startup request and controlling the MIDlet from that thread. Actual details are
implementation dependent. In Sun's J2ME Wireless Toolkit, the class com.sun.midp.Main defines the
The startApp() method creates an object called a form and
passes a string to the constructor that represents the form's title. A form is an instance of the
class javax.microedition.lcdui.Form, which is a kind of screen that
you can see on your display. It's so named because it functions somewhat like an
HTML form—it contains one or more visual items, such as strings.
Next, the startApp() method creates a regular String object and
adds it to the form. It then gets a reference to an object called a display, and it
sets the form object as the currently displayed entity of the display.
After all this code executes, you see the screen.
When you click or press the handset
button that tells the device to hang up, the AMS invokes
destroyApp(), which simply eliminates all references to the form object previously created.
It's now subject to garbage collection. The AMS then terminates the MIDlet.
You're responsible for properly disposing of objects created by
your MIDlets. In this contrived case, it shouldn't matter whether or not you set the reference
to the form variable to null, because the MIDlet terminates. But in general, you need to properly
manage the references to your program's objects, just as you would in any Java program.