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), such 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 formally 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 primarily 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 bytecode 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 J2EE. 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 Edition
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 limited 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.
Learning 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 you 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 computer 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 devices.
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 processor 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'll 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 packages 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 the 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 virtual 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, configurations 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 amounts
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 packages, 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 superset 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 example, 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 formal 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 small 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 of 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 extends
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 profiles, 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 covering 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 require? 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 profiles, 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 trying 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 important.
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 configurations. 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 in 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 (application 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 applications 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 additional 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 weak 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 these 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 verifier, 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 and 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.
The 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. Configurations 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 java.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 not 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 using 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(); } catch( 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 profiles 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 GCF'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, which 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 Studio, 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 the 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 VM.
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 if 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-featured, 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 included 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.zip
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 more 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 classes 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 start 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";
OutputConnection 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 support 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 user
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 pixels 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. Personal
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 capabilities 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 support
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 arena, 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 effort 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 basic 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 the 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-specific 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 deactivated. 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 lifecycle 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 applications 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 class 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 activated 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.developer.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.println( "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 void 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 ){
exitMIDlet();
}
// 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(){
super( "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 archive) 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-Configuration: 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/MyMIDlet.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 released 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-enabled 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 limits 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 developer 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.