What is Java 2 Micro Edition?

grapedraughtSoftware and s/w Development

Dec 2, 2013 (3 years and 4 months ago)

174 views

http://www.developer.com/java/j2me/article.php/1443961


What is Java 2 Micro Edition?

By Eric Giguère


Java is known primarily as a server
-
side programming environment, centered around the technologies that make
up the Java 2 Enterprise Edition (J2EE), suc
h as Enterprise JavaBeans (EJBs), servlets, and JavaServer pages
(JSPs). Early adopters of Java, however, will recall that it was originally promoted as a client
-
side application
environment. In fact, Java was originally designed as a programming language
for consumer appliances. Now
Java is returning to its roots with Java 2 Micro Edition, or J2ME for short. This article, the first in a series on
J2ME programming, explains what J2ME is.

The Java 2 Platform


What we commonly refer to as "Java" is more forma
lly known as the Java 2 Platform. The Java 2 Platform is
split into three editions: Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition (J2EE), and Java 2 Micro
Edition (J2ME). Each edition of the platform provides a complete environment for running
Java
-
based
applications, including the Java virtual machine (VM) and runtime classes.


The three editions all target different kinds of applications running on different kinds of devices. Desktop
-
based
applications are developed using J2SE, which provides
the necessary user interface classes. Server
-
based
applications are developed using J2EE, which emphasizes component
-
based programming and deployment.
Handheld and embedded devices are targeted by J2ME.


What separates one edition from another, then, is pr
imarily the set of class libraries that each edition defines.
Loosely speaking, you can think of J2ME as a subset of J2SE and J2SE as a subset of J2EE. It is possible to run
the same Java bytecode in each edition, providing the classes referred to by the b
ytecode are available in all three
editions. The catch, of course, is that J2ME
-
based devices have fewer classes than what J2SE and J2EE provide,
especially the smaller devices. After all, there are several thousand core J2SE runtime classes, taking up ten

to
twenty megabytes of space, which is simply too big for the majority of devices out there today and in the near
future.


The various specifications that comprise J2ME are all defined through the Java Community Process (JCP), as is
done with J2SE and J2E
E. Today, there are close to forty separate Java Specification Requests (JSRs) dealing
with J2ME: Small device programming is definitely a hot topic within the Java community. (For more
information, see the main JCP Web site at www.jcp.org.)

Java 2 Micro E
dition


In J2ME, the Java runtime environment is adapted for constrained devices
-

devices that have limitations on
what they can do when compared to standard desktop or server computers. For low
-
end devices, the constraints
are fairly obvious: extremely l
imited memory, small screen sizes, alternative input methods, and slow
processors. High
-
end devices have few, if any, of these constraints, but they can still benefit from the optimized
environments and new programming interfaces that J2ME defines.


Learni
ng about J2ME is not hard: Once you understand the new terminology, it's mostly about learning new
APIs (application programming interfaces) and learning how to work in constrained environments. (If you think
writing an applet is challenging, wait until yo
u try to fit an application into the 30K of memory some cellphones
provide!) You can use most of the same tools you already use in your code development, and with careful coding
you can develop libraries of classes that are portable to any device or comput
er with a Java virtual machine.

PersonalJava and EmbeddedJava


J2ME is not the first attempt at adapting Java for constrained environments. Two other technologies,
PersonalJava and EmbeddedJava, made it possible to run Java 1.1.x applications on high
-
end d
evices.


PersonalJava uses the basic Java 1.1 runtime classes and throws in a few features from Java 2. Support for some
of the runtime classes is optional, but a PersonalJava implementation still requires a couple of of megabytes of
memory and a fast proc
essor to run, so it's not a practical solution for truly constrained devices like cellphones
and many personal digital assistants.


EmbeddedJava makes every behavior of both the Java VM and the runtime classes optional
-

the implementor
can choose exactly
which classes and methods are required. There is one limitation, however: The Java runtime
environment can only be used by the implementor and cannot be exposed to third parties. In other words, you
can use it to write Java code that runs inside a device,
usually as part of the software to control the device, but no
one else can write applications for the device. This is done to preserve the "write once, run anywhere" nature of
Java, since an EmbeddedJava environment can do away with fundamental things like

runtime class verification
and change the public interfaces of core classes. EmbeddedJava is really a way to build a "private" Java runtime
environment.


Both PersonalJava and EmbeddedJava are being phased out. There is a migration path from PersonalJava
to
J2ME, as we'll see later in this series, though the current version of PersonalJava continues to be supported.
EmbeddedJava is no longer supported because J2ME defines suitable small
-
footprint runtime environments.

What's Next


In the next article, we'l
l examine the core concepts of J2ME
-

configurations, profiles, and optional packages
-

and some other terms like KVM and CVM. You can't write a J2ME application without knowing which
configuration and profile you're targeting, or knowing which optional pa
ckages are required, so it's important to
understand the terminology before you attempt your first application.


If you can't wait to get started with J2ME, download Sun's J2ME Wireless Toolkit and read through some of the
extensive J2ME documentation on t
he Sun Web site.


J2ME Core Concepts


At the heart of Java 2 Micro Edition (J2ME) are three core concepts: configurations, profiles, and optional
packages. You can't write a J2ME application without understanding these concepts, because they determine the
features of Java that you can use, which application programming interfaces (APIs) are available, and how your
applications are packaged.

Configurations


A configuration is a complete Java runtime environment, consisting of three things:



* A Java virt
ual machine (VM) to execute Java bytecode.


* Native code to interface to the underlying system.


* A set of core Java runtime classes.


To use a configuration, a device must meet certain minimum requirements as defined in the configuration's
formal

specification. Although a configuration does provide a complete Java environment, the set of core classes
is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by
configuration implementor. In particular, config
urations do not define any user interface classes.


J2ME defines two configurations, the Connected Limited Device Configuration (CLDC) and the Connected
Device Configuration (CDC). The CLDC is for very constrained (limited) devices
--

devices with small am
ounts
of memory and/or slow processors. The VM used by the CLDC omits important features like finalization, while
the set of core runtime classes is a tiny fraction of the J2SE core classes, just the basics from the java.lang,
java.io and java.util package
s, with a few additional classes from the new javax.microedition.io package. The
CDC, on the other hand, includes a full Java VM and a much larger set of core classes, so it requires more
memory than the CLDC and a faster processor. The CDC is in fact a su
perset of the CLDC. We'll discuss the
configurations in detail in the next two articles in this series.

Profiles


A profile adds domain
-
specific classes to a configuration to fill in missing functionality and to support specific
uses of a device. For examp
le, most profiles define user interface classes for building interactive applications.


To use a profile, the device must meet all the minimum requirements of the underlying configuration as well as
any additional requirements mandated by the profile's for
mal specification.


There are several profiles in various stages of development. The first profile to be released was the Mobile
Information Device Profile (MIDP), a CLDC
-
based profile for running applications on cellphones and
interactive pagers with smal
l screens, wireless HTTP connectivity, and limited memory. Another CLDC
-
based
profile under development is the Personal Digital Assistant Profile (PDAP), which extends MIDP with additional
classes and features for more powerful handheld devices. In terms o
f CDC
-
based profiles, the Foundation Profile
(FP) extends the CDC with additional J2SE classes, the Personal Basis Profile (PBP) extends the FP with
lightweight (AWT
-
derived) user interface classes and a new application model, and the Personal Profile exte
nds
the PBP with applet support and heavyweight UI classes. We'll also be discussing these profiles later on in this
series.


Optional Packages


An optional package is a set of APIs in support of additional, common behaviors that don't really belong in one

specific configuration or profile. Bluetooth support, for example, is defined as an optional package. Making it
part of a profile wouldn't work, because none of the behaviors of a profile can be optional
--

if a device supports
a profile, it must support
the entire profile
--

and that would limit the profile to Bluetooth
-
enabled devices.


Optional packages have their own minimum requirements, of course, just like configurations and profiles.
Optional packages also have specific dependencies on a particular

configuration and/or one or more profiles
--

they do not define a complete runtime environment, just sets of related APIs.


There are many optional packages in development, including the RMI Optional Package, which adds RMI
support to CDC/FP
-
based profile
s, the Java APIs for Bluetooth, which adds Bluetooth support to CLDC
-
based
profiles, and the JDBC Optional Package for CDC/Foundation Profile, which defines a subset of JDBC (database
access APIs) for use with CDC/FP
-
based profiles. Again, we'll be coverin
g these later on in the series as the
need arises.


The KVM and CVM


Two other terms you'll see mentioned in J2ME literature are KVM and CVM. These are the names of Java
virtual machines for the CLDC (KVM) and the CDC (CVM), written specifically to work in

the constrained
environment of a handheld or embedded device and to be easily ported to different platforms. It should be noted,
however, that the CLDC and CDC specifications do not require the use of the KVM or the CVM, only the use of
a VM that adheres
to the requirements of the specification in question. While many device manufacturers license
the KVM or CVM from Sun Microsystems to serve as the core of their J2ME implementation, they are not
required for J2ME compliance. It is a mistake, therefore, to
consider the CLDC and KVM as synonymous, and
similarly for the CDC and the CVM.


What It All Means


It should now be apparent that "J2ME application" is an ambiguous term. For what profile is the application
intended? Which optional packages does it requir
e? How much memory does it take? These are the questions
you must ask yourself before you start application development, because they determine which language features
and which classes your application can use. If you limit your application to CDC
-
based p
rofiles, for example,
you make development simpler of the many familiar J2SE APIs, but you cut out the low
-
end devices from your
potential install base. Targeting CLDC
-
based profiles, on the other hand, makes your development task harder,
especially when t
rying to shrink the size of your application to run on as many of the smaller devices as possible.
These are the kinds of tradeoffs you'll have to make as you begin to work with J2ME. The information in this
series will help you decide what's really import
ant.


The Connected Limited Device Configuration (CLDC)


At the core of Java 2 Micro Edition (J2ME) are the configurations, the specifications that define the minimal
feature set of a complete Java runtime environment. J2ME currently defines two configurat
ions. In this article
we look at the first of these, the Connected Limited Device Configuration, or CLDC for short.

The CLDC Specification


Like all J2ME technology, the CLDC is defined by a specification that has passed through the Java Community
Process
(JCP). At this time, there are two versions of the CLDC. Version 1.0, released in May of 2000, is known
as Java Specification Request (JSR) 30. Version 1.1, currently in public review, is JSR 139. Because version 1.0
is the one that is currently shipping i
n devices, we'll concentrate on it.


The CLDC specification defines three things:



1. The capabilities of the Java virtual machine (VM), which is not a full
-
featured Java VM.


2. A very small subset of the J2SE 1.3 classes.


3. A new set of APIs (ap
plication programming interfaces) for input/output called the Generic Connection
Framework.


It's also important to understand what the CLDC does not define. The CLDC does not define any APIs related to
user interfaces. The CLDC does not define how applica
tions are loaded onto a device or how they are activated
or deactivated. These and other things are defined by the J2ME profiles that use the CLDC as their base. So
while it's true that the CLDC does define a complete Java runtime environment, the addition
al APIs defined by a
profile or supplied by the vendor are really necessary to build useful applications.

The Virtual Machine


The Java VM used in the CLDC is restricted in certain important ways when compared to a full
-
featured J2SE
VM. These restrictions

allow the VM to fit the memory and power constraints of the small devices that the
CLDC target: the CLDC VM and classes can fit in 128K of memory.


The primary restrictions on the VM are:



* No floating point types.


* No object finalization or wea
k references.


* No JNI or reflection (hence no object serialization).


* No thread groups or daemon threads (note that threads are supported, just not thread groups).


* No application
-
defined class loaders.


Note that CLDC 1.1 relaxes some of th
ese restrictions, in particular reenabling support for floating point types
and weak references.


In addition to the above restrictions, the CLDC also requires class verification to be done differently. Class files
are processed by an off
-
device class veri
fier, a process called preverification. At runtime, the VM uses
information inserted into the class files by the preverifier to perform the final verification steps. Files that have
not been processed by the preverifier are not loaded since they cannot be
verified.

The J2SE Subset


The subset of J2SE 1.3 included in the CLDC consists of classes from these three packages:



* java.lang


* java.io


* java.util


Only selected classes from each package are included: for example, the java.util.Vector an
d java.util.Hashtable
classes are included, but none of the collection classes are. The largest package is the java.lang package, which
defines the classes that are fundamental to any java application, classes like java.lang.Object or java.lang.Integer.
Th
e java.io subset only includes abstract and memory
-
based classes and interfaces like java.io.DataInput or
java.io.ByteArrayInputStream. The java.util subset only includes a few utility classes.


Some of the classes are subsets of their J2SE equivalents. Co
nfigurations are allowed to remove unnecessary
methods or fields, but they cannot add new public or protected methods or fields.


The Generic Connection Framework


J2SE includes many classes for performing input and output, classes that are found in the ja
va.io and the java.net
packages. Unfortunately, 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 no
t universal, either.


What the CLDC has done, then, is to define a new set of APIs for I/O called the Generic Connection Framework.
The GFC, part of the new javax.microedition.io package, defines interfaces for the different kinds of I/O that are
possible
and a factory class for creating objects that implement those interfaces. The type of object to create is
specified in the protocol part of the URL (universal resource locator) passed to the factory class.


For example, a socket connection can be made usin
g code like this:


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.

}

catch( ConnectionNotFoundException cnfe ){


// handle it

}

catch( IOException e ){


// handle it

}

finally {


if( is != null ) try { is.close(); } catch( Exception e ){}


if( conn != null ) try { conn.close(); } cat
ch( Exception e ){}

}


The code above assumes that the device knows how to map the "socket" protocol in the URL to an object that
implements the GCF's StreamConnection interface, which defines methods for obtaining the input and output
streams of a socket
connection. It should be noted, however, that the CLDC does not actually define any I/O
implementations. In other words, the CLDC defines the interfaces of the GCF, but the implementation classes
--

the ones that do the actual I/O
--

are left to the profil
es and/or the device vendor to define. For example, the
Mobile Information Device Profile (MIDP)
--

a CLDC
-
based profile
--

requires support for a subset of HTTP 1.1
and so it recognizes the "http" protocol in URLs and returns objects that implement the GC
F's
ContentConnection interface.

Using the CLDC


By itself, the CLDC is a limited programming platform. Because it does not define any user interface classes or
implement any I/O models, about all you can do for output is write to the System.out stream, wh
ich may or may
not be captured to a console or file. You really need the extra classes defined by a J2ME profile (like those of the
MIDP) or device
-
specific classes (like those on the RIM BlackBerry devices or certain Japanese i
-
Mode phones)
to do anything

interactive.


If you're still interested in trying out the CLDC, Sun has a reference implementation hosted on Windows or
Solaris available for download from its website. This reference implementation includes the preverify offline
verification utility as
well as a CLDC VM and the CLDC runtime classes. See Sun's main CLDC page for links
to it and to the CLDC specification. You can also use toolkits or integrated development environments like Sun's
J2ME Wireless Toolkit, Metrowerks' CodeWarrior Wireless Stud
io, or Borland's JBuilder MobileSet to explore
CLDC programming.


Understanding The Connected Device Configuration (CDC)


The second configuration at the core of Java 2 Micro Edition (J2ME) is the Connected Device Configuration, or
CDC for short.The CDC is

a superset of the Connected Limited Device Configuration (CLDC). It provides a
much more conventional Java 2 runtime environment.

The CDC Specification


Like the CLDC (see my previous article, The Connected Limited Device Configuration (CLDC)), the CDC is

defined by a specification that has passed through the Java Community Process (JCP). The CDC, known as Java
Specification Request (JSR) 36, was released in March 2002.


The CDC specification is a much smaller document than the CLDC specification because t
he CDC is much
closer to a Java 2 Standard Edition (J2SE) runtime environment than the CLDC. The CDC specification defines
four things in particular:



1. The capabilities of the Java virtual machine (VM). Unlike the CLDC, the CDC VM is a full
-
featured V
M.


2. A subset, much larger than the CLDC's, of the J2SE 1.3 classes.


3. The same APIs (application programming interfaces) that are new to the CLDC
--

in other words, the
Generic Connection Framework (GCF).


4. Support for file
-

and datagram
-
based

input/output using both the GCF and the familiar java.io and java.net
classes.


Note that, just like the CLDC, the CDC does not define any user interface classes or how applications are loaded
and activated: these are left for the profiles to define.

The

Virtual Machine


The CDC supports a complete, full
-
featured Java 2 virtual machine (VM) as defined in The Java Virtual
Machine Specification. The low
-
level interfaces for calling native code, connecting to debuggers, and profiling
code are optional, but i
f supported they must be the standard interfaces
--

Java Native Interface (JNI), Java
Virtual Machine Debugging Interface (JVMDI), and Java Virtual Machine Profiling Interface (JMVPI)
--

used in
Java 1.3.


Note that the CDC does not require preverification

of classes, as full class verification is done on the device by
the VM. Classes that have been preverified can also be used, of course, since the additional information added to
the class files by the preverifier is ignored.


Because the VM is full
-
featur
ed, and there are more classes, the minimum memory footprint for the CDC is
larger than the CLDC's: the device needs at least 512K for the runtime environment, plus at least 256K to hold
and run applications.

The J2SE Subset


The subset of J2SE 1.3 include
d in the CDC consists of classes from these packages:



* java.io


* java.lang


* java.lang.ref


* java.lang.math


* java.net


* java.security


* java.security.cert


* java.text


* java.util


* java.util.jar


* java.util.zi
p


As you can see, the CDC includes many more packages than the CLDC, and many more classes even in the
shared packages. For example, the CDC includes the collections classes from the java.util package, while the
CLDC does not. This makes the CDC a much mo
re J2SE
-
like environment than the CLDC. There are still
classes missing, of course. For example, the java.net package as defined by the CDC only includes the classes
related to datagram sockets, not stream sockets.



The Generic Connection Framework


Since

the CDC is a superset of the CLDC, it includes the Generic Connection Framework (GCF). Unlike the
CLDC, however, the CDC also requires GCF support for two specific connection types: files and datagrams.
This makes sense because the CDC includes the file c
lasses from the java.io package and the datagram classes
from the java.net package. It is therefore straightforward for the device manufacturer to write GCF
implementation classes that simply map GCF requests (using the file or datagram protocol at the sta
rt of a URL)
into their java.io and java.net equivalents.

File and Datagram Support


Here is an example of opening a file for writing using the GCF:


import java.io.*;

import javax.microedition.io.*;


try {


String url = "file:/logs/mylog.txt";


Outp
utConnection conn =


(OutputConnection) Connector.open( url,


Connector.WRITE );


OutputStream out = conn.openOutputStream();


..... // write to the output stream


out.close();


conn.close();

}

catch( IOException e ){


// handle error

}


Datagram support is a bit more complex, but quite similar.


Why not just use the java.io and java.net classes directly? The GCF provides a consistent I/O model that works
across all J2ME platforms that suppo
rt the required protocols. If you don't need interoperability with J2SE, use
the GCF whenever possible to open your I/O connections.

Using the CDC


Like the CLDC, the CDC is by itself a limited programming platform. Again, because it does not define any us
er
interface classes or implement any I/O models, about all you can do for output is write to the System.out stream,
which may or may not be captured to a console or file. The extra classes defined by one or more J2ME profiles
are really required to write
interactive applications.


Sun has a reference implementation of the CDC hosted on Linux available for download from its website. See
Sun's main CDC page for links to it and to the CDC specification.


The Importance of the Mobile Information Device Profile

(MIDP)

By Eric Giguère


Although configurations are at the heart of Java 2 Micro Edition (J2ME), it's the profiles that are of real interest.
Profiles define the application programming interfaces (APIs) that are required to write useful applications for
a
particular group or family of J2ME devices. The Mobile Information Device Profile (MIDP) defines a Java
runtime environment for cellphones, interactive pagers, and similar mass
-
produced, resource
-
constrained
handheld devices.

Mobile Information Devices


MIDP is targeted at a class of devices known as mobile information devices (MIDs). These are devices that have
the following minimal characteristics:



* Enough memory to run MIDP applications (see below)


* A bit addressable display at least 96 pixe
ls wide by 56 pixels high, either monochrome or color.


* A keypad, keyboard, or touch screen.


* Two
-
way wireless networking capability.


Almost any wireless device built these days fits the definition of a MID, including low
-
end cellphones. Persona
l
digital assistants (PDAs) can also be considered to be MIDs because wireless networking is now an option for
most PDAs, but MIDP doesn't target these devices specifically: PDAs have more memory, larger screens, and
interesting information management capa
bilities that are more effectively exploited using other profiles.

The MIDP Specification


There are two versions of the Mobile Information Device Profile, both defined using the Java Community
Process (JCP). MIDP 1.0, known as Java Specification Request (
JSR) 37, was released in September 2000.
MIDP 2.0, JSR 118, is currently in proposed final draft form, the final step before formal release as a final
specification. No devices yet support MIDP 2.0, but there are many devices currently on the market that s
upport
MIDP 1.0. We'll concentrate solely on MIDP 1.0 for now, deferring discussion of MIDP 2.0 until later in this
series.


The MIDP 1.0 specification was defined by an expert group consisting of all the major players in the wireless
and handheld device a
rena, including familiar names like Motorola, Nokia, Ericsson, Research in Motion, and
Symbian. It has a lot of support in the telecommunications industry, and handset manufacturers like Motorola
and Nokia in particular are devoting a lot of development ef
fort to supporting MIDP in a wide range of their
devices.


The configuration used by MIDP is the Connected Limited Device Configuration (CLDC), which we've already
discussed in a previous article in this series. The CLDC has the small footprint required to

run on low
-
end
devices. Devices that are capable of running the other configuration, the Connected Device Configuration
(CDC), can also run MIDP, of course, since the CDC is a superset of the CLDC.


The MIDP adds APIs in a number of areas to the very basi
c APIs defined by the CLDC. The new features
include:



* Support for application lifecycle management similar to the way applets are defined in Java 2 Standard
Edition.


* Persistent storage of data.


* HTTP
-
based network connectivity based on th
e CLDC's Generic Connection Framework.


* Simple user interface support, with enough flexibility to build games or business applications.


The MIDP specification is silent about a number of things, however. For example, in MIDP 1.0 there is no
standard
way to interface to the device's phonebook, if it has one, in order to initiate voice calls. There are no
standard facilities for data synchronization, even if the device supports the feature. Device manufacturers can
and do provide their own device
-
specif
ic APIs for these kinds of features, though, but using them limits your
application's portability.


Note that the MIDP specification is particularly silent in one area: how MIDP applications are loaded onto a
device and how they are activated or deactivate
d. As such, different devices will do these in different ways. The
MIDP specification basically concerns itself with what the application does once it's running, not how it's
activated.

MIDlets and MIDlet Suites


As mentioned, MIDP defines an application l
ifecycle model similar to the applet model. In fact, MIDP does not
support the running of traditional applications that use a static main method as their entry point. Nor can MIDP
applications call the System.exit method in order to terminate. MIDP applica
tions must follow specific
packaging rules.


A MIDP application is referred to as a MIDlet. Its entry point is a class that extends the
javax.microedition.midlet.MIDlet class, much in the same way that an applet extends the java.applet.Applet
class. This c
lass is referred to as the MIDlet's main class. The MIDlet class defines abstract methods that the
main class implements: these methods are called by the system to notify the MIDlet that its state is changing. For
example, whenever the MIDlet is being acti
vated its startApp method is called. Again, this is very similar to the
way applets behave.


Here is the code for a very basic MIDlet, drawn from Chapter 3 of Mobile Information Device Profile for Java 2
Micro Edition:


// A trivial MIDlet

package com.deve
loper.j2me;


import javax.microedition.lcdui.*;

import javax.microedition.midlet.*;


public class MyMIDlet extends MIDlet


implements CommandListener {



private Display display;


private Command exitCommand = new Command( "Exit"
,


Command.EXIT, 1 );



// Constructor, doesn't do anything really



public MyMIDlet(){


System.out.println( "MyMIDlet constructed" );


}



// Called when the system is destroying the MIDlet.



protected void destroyApp( boolean unconditional )


throws MIDletStateChangeException {


exitMIDlet();


}




// Called when the system is pausing the MIDlet.



protected void pauseApp(){


System.out.pri
ntln( "MyMIDlet paused" );


}




// Called when the system is activating the MIDlet.



protected void startApp() throws MIDletStateChangeException {


if( display == null ){ // first time called...


initMIDlet();


}




System.out.println( "MyMIDlet started" );


}




// Called to initialize the MIDlet. Executes only


// once. Obtains the Display instance associated


// with this MIDlet and creates a simple


// user interface for it.



private vo
id initMIDlet(){


display = Display.getDisplay( this );


display.setCurrent( new TrivialForm() );


}




// Called to exit the MIDlet. Centralizes all the


// cleanup work.



public void exitMIDlet(){


notifyDestroyed();


System.out.println( "MyMIDlet destroyed" );


}



// Event handling. Called by the system when the


// user activates a command, normally by pressing


// a button.



public void commandAction( Command c, Displayable d ){


exitM
IDlet();


}



// A trivial UI screen. A titled blank screen


// to which a single command is associated. The system


// will map that command to a button or a menu item.



class TrivialForm extends Form {


TrivialForm(){


s
uper( "MyMIDlet" );


addCommand( exitCommand );


setCommandListener( MyMIDlet.this );


}


}

}


One or more MIDlets are packaged together into what is referred to as a MIDlet suite, which is basically a
standard JAR (Java arc
hive) file and a separate file called an application descriptor. All the user
-
defined classes
required by the suite's MIDlets must be in the JAR file, along with any other resources (such as images) that the
MIDlets require. The JAR file must also include
a manifest with a number of MIDP
-
specific entries that describe
the MIDlets in the suite. The application descriptor 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.


Here is an example of the manifest that goes along with the simple MIDlet shown above:


MIDlet
-
1: MyMIDlet, MyMIDlet.png, com.developer.j2me.MyMIDlet

MIDlet
-
Name: MyMIDlet

MIDlet
-
Vendor: Eric Giguere

MIDlet
-
Version: 1.0

MicroEdition
-
Co
nfiguration: CLDC
-
1.0

MicroEdition
-
Profile: MIDP
-
1.0


And here is an example of an application descriptor for the same MIDlet:


MIDlet
-
1: MyMIDlet, MyMIDlet.png, com.developer.j2me.MyMIDlet

MIDlet
-
Jar
-
Size: 4238

MIDlet
-
Jar
-
URL: http://somewhere.foo.com/MyM
IDlet.jar

MIDlet
-
Name: MyMIDlet

MIDlet
-
Vendor: Eric Giguere

MIDlet
-
Version: 1.0


These are only examples, of course, and we'll be discussing these in more detail as the series progresses.

Developing MIDP Applications


As the first J2ME profile to be releas
ed and to ship commercially, there are actually several MIDP programming
tools available, often as add
-
ins for your favorite Java development environment. A development environment is
not enough, however.


The reality of MIDP programming today is that the
applications you can write are constrained in many ways.
These constraints often require you to think about things that you wouldn't think of twice of with J2SE
programming. Memory is a particularly scarce resource, for example. The early Motorola J2ME
-
ena
bled phones
limited the size of a MIDlet suite to 50K (since raised to 100K on more recent models) and some Nokia phones
limit them to even less, about 30K. Because MIDP 1.0 applications cannot share classes between suites, this
really limits what you can
do on the device. You'll find that placing part of your application in a web or
application server (as a servlet, typically) that the MIDP application calls is almost a requirement for anything
serious. This will change over time, of course, as memory limi
ts are eased in newer devices.



Eric Giguère is the author of Java 2 Micro Edition, the first book about J2ME, and co
-
author of Mobile
Information Device Profile for Java 2 Micro Edition, both published by John Wiley & Sons. He works as a
software develop
er for iAnywhere Solutions, a subsidiary of Sybase. For more information about Eric, see his
web site or drop him a note at ericgiguere@ericgiguere.com.