This is the first module of a guide about MIDP programming with the J2ME environment. In this first part we’ll introduce configuration and profile, fundamental concepts that are very important for understanding MIDP. After that we’ll install the WTK 2.5 that is the toolkit for creating, developing and testing your application to be used on real MIDP 2.0 devices.
From J2SE to J2ME
Java was created with an idea in mind: “Write once, run everywhere” but not all evironments are the same. A desktop application is very different from a set-top box application which, in turn, is very different from an application running on a small device. Differences lie in the hardware capabilities, GUI widgets and usage. A PC doesn’t have the same power issues that a mobile phone has. A PC is always connected to the net while a mobile phone may have issues about network reachability. A PC often has ha a mouse that a mobile phone doesn’t have.
Differences are also about features in the application that devices have to execute. A client application is different from a server application.
Client applications should have good usability, simple GUI and must connect to the server in a reliable way. A server application must be reliable, scalable, must manage transaction and maybe talk to legacy systems. This is a demonstration of the need of a different environment for different kinds of applications and platforms. This is the reason for the different Java environments available for developing, compiling, testing and executing Java application.
So, what about the “Write once, run everywhere”? Well, the answer is the possibility of using the same language, the same IDE, the same compiler plus some tools for code optimization. The one we’ll see is, for instance, the pre-compiler that delegates part of the interpreter job, to the compiler reducing JVM or KVM work.
Sun provides three environments:
- Java 2 Standard Edition (J2SE)
- Java 2 Enterprise Edition (J2EE)
- Java 2 Micro Edition (J2ME)
J2SE is made for desktop application, J2EE for Enterprise application while J2ME is for devices with reduced hardware and software capabilities. There are number of tools and API that J2SE has that are not useful on mobile devices. For instance, a mobile device doesn’t need an API for the AWT widgets because a phone GUI is very different from a desktop application GUI. Also, a small device doesn’t need any CORBA or RMI. Reduced APIs mean reduced JVM capability so Sun creates a smaller version of its JVM which is called KVM. The K is about its size which is a few Kbytes. As we’ll see in the development process, the KVM doesn’t need security management tools whose function is preformed by pre-compiler in the compilation phase. So the KVM is a kind of JVM for small devices which focuses on a particular set of APIs.
Configuration and Profile
As we mentioned before, J2ME is the Java environment for devices with limited hardware and software capability. This definition is not enough to describe each category of devices. There are many devices with low capability but many differences between them – we refer to mobile phones, PDAs, WebTV and so on – so, we need a further level of classification about specific hardware and software capabilities. Figure 1_1 describes the J2ME architecture. We can see that the Operating System is the first layer on which others layer work. Every device has its own Operating System which makes us of specific hardware capabilities. The JVM,or the KVM in the J2ME case, is built on top the OS layer and translates Java Bytecode operations into OS-specific operations. This is the same role the JVM has in other more powerful environments. On top of the KVM layer we have Configuration and then Profile layers that are two different and orthogonal ways of classifying different types of J2ME devices.
A Configuration describes a complete Java runtime environment for a set of devices with the same hardware capability.
The Configuration usually contains:
- The KVM able to execute Java bytecode
- Some OS- specific native implementation of KVM operation
- A set of device independent API that are linked to the hardware capability (for instance I/O management)
At the moment there are two main Configuration which are:
- Connected Device Configuration (CDC)
- 32 bit CPU
- 512Kb of ROM
- 256Kb of RAM
- Power not limited
- Always connected on the network
- Complete JVM implementation
- GUI for user interaction
- Connected Limited Device Configuration (CLDC)
- 16 or 32 bit CPU with slow clock (8-32 Hz)
- Limited power
- 192Kb total memory (volatile and not)
- Limited network connection
- Very limited GUI for user interaction (numeric keypad)
Devices in the CDC category are WebTV or Set-Top Boxes. In the CLDC category we find mobile phones and PDAs. Figure 1_2 shows the relationship between J2SE, CDC and CLDC Configuration. We can see that the CDC is a subset of J2SE API plus some specific API. CLDC is a subset of CDC. This means that a CLDC application must be able to run also in a CDC environment. The same is not true for J2SE.
CLDC Configuration available at the moment are about version 1.0 and 1.1 (JSR-139). Their main difference is the floating point availability. MIDP 2.0 is built on CLDC Configuration 1.0 at minimum.
It’s easy to notice that devices with similar hardware capabilities can be very different between them so we’ll need another classification which we’ll call Profile. Devices with the same hardware capabilities can differ because of screen size, keyboard and way of interacting with the user therefore the APIs that we use to create application are also different. From this we understand that we need a furthers classification of other capabilities which leads us to different APIs for different devices. This is the definition of Profile. If we create an application for a particular J2ME profile, we must be able to execute the same application on every device compatible with the that Profile because it must support the APIs that the Profile describes. MIDP 2.0 is a Profile built on top of CLDC which provides a set of tools that the developer can use to create applications for MIDP 2.0 compliant devices. It is not important the type of device as long as it claims to be MIDP 2.0 compatible. Another very important concept in real life application developing is the Optional Packages we’ll describe later.
What we are interested in is MIDP 2.0 development because we know that most mobile phones are compatible with that but we also know that not all devices supports every feature like, say, bluetooth and GPS. There is a set of API that every device MIDP 2.0 must support but theres is also a set of APIs that are optional. These are APIs that a device might have but they are not mandatory for MIDP 2.0 compatibility. For this reason they are called Optional Packages. Be very careful that these kind of API are optional in devices but are adherent to particular standard API described by some JSR specification. So if a device has the BlueTooth Optional Package it has API that are adherent to JSR-82. Optional Packages are very useful in MIDP2.0 applications in particular for Location Based and BlueTooth applications that we will cover in a future module of this course.
The MIDlet development process
Before creating our first MIDlet, we talk a little about the MIDP 2.0 development process (Fig 1_3). As you can see, the development process can be split in two parts: the development part and the execution part. The first step to do is to code the MIDlet and other related classes using the API that the application needs.
The application must have a target mobile device with specific MIDP version, the 2.0 in our case, and specific optional packages. We’ll cover the coding process in depth in future modules. After coding we have the compilation, done using the javac compiler. Please note that this is the same compiler we use with desktop and J2SE applications, what is different is the API set which must be the one with MIDP 2.0 and optional packages jar. This is usually responsibility of the development tools used. We should not be able to compile a class of the package java.awt.Button for instance. After a successful code compilation we have the related class bytecode and we need to do a step which is J2ME specific: preverification. To do this we use a tool called preverifier.
Why do we need this? Since we’re talking about small devices application with limited resource, runtime security checks are very expensive, so the choice was to delegate part of the verifying process to the development phase after compilation. After this step we’re sure the code has the requirements we need for secure MIDlet. This tool insert into the bytecode a kind of report of the execution environment check. The execution environment doesn’t need to run expensive operations but just a comparison or little more. An other optimization is about the time the device does this check. It doesn’t repeat the check during every execution but only during the application installation phase. In this phase, the mobile device is also able to do some more optimizations that depend on the specific operating system.
To develop MIDP 2.0 application we need the Wireless Toolkit 2.5 that can be downloaded for free from the Sun website  . After installation you can run the tool you should see what we have in Fig1_4.
The first thing to do is to create a new project. Selecting the proper menu button the WTK prompt for the project name and the main MIDlet class name. For our first MIDlet we choose the information shown in Fig1_5.
After this we confirm and the WTK presents a window for MIDlet settings (Fig1_6). As we can see, the WTK gives us a lot of configuration we’ll see in more depth in future modules. What we can see is the possibility of choosing a target which is a set of APIs available in different kind of devices. If we choose JTWI, we choose the Java for Telephony and Wireless Industry, a standard that describes some specific device capabilities. In this window we can see that JTWI is a standard regarding MIDP 2.0 devices built on top of CLDC 1.0 or CLDC 1.1 that has some optional packages which are mandatory (for the JTWI) and some not.
For the moment we leave all as it is and press ok, creating the project. This first step changes depending on the development tool you have chosen. Now we delve into the first step which is coding. The WTK created a specific directory structure for the project (Fig1_7) starting from WTK_HOME/apps/MyFirstProject directory. The code must be placed in the src following the java conventions about directory and packages. Libraries must be placed into the lib directory while in the the res directory we’ll places resource like images, sounds and similar. The bin directory we’ll contain our MIDlet composed of a jar file with the relative jad that is the MIDlet descriptor. We’ll use the next module to describe in depth all about JAD files and the WTK.
Start by typing the code in List1_1. What we’ll do now is the compliation and preverification steps bye pressing the WTK 2.5 “build” menu button. You should end up with something similar to Fig1_8.
Some errors will be eventually shown by the tool as well. We note that during the build phase, the WTK shows a progress toolbar showing that it’s compiling first and then pre-verifying. If compilation is succesfull we can try to create the MIDlet jar. We can do this with the menu option you can see in Fig 1_9.
There are two ways of doing this: a normal package and an obfuscated one. We’ll talk about obfuscation in a future module. For the moment you just need to know that obfuscating is the process of hiding code and also reducing the size which is a good practice in small devices applications. We choose the first option and we got what we see in Fig1_10.
Now our MIDlet is ready to be executed within the WTK emulator. Also in this case, we can do that in two different ways depending of the installation mode of the application. We can execute the MIDlet as local application or we can emulate the downloading process from the network. This second case is called Over The Air installation process. To do that we can use the related menu option in the same menu we saw for building. We can execute the MIDlet either with the run option or with the “Run with OTA” option. We’ll chose the second option.
Run MIDlet with Over The Air
We describe this option because is the main we’ll use in real devices application. Usually a user receives a SMS or visits a Wap page containing a link to the JAD MIDlet application. As we’ll see in detail in the next module, the JAD contains information about security option, MIDlet execution requirement and MIDlet jar location. The device has an application which is called Java Application Manager (JAM) which is responsible of MIDlet management. The MIDlet installation process is a JAM responsibility. We can see the emulator JAM application if we choose to execute our MIDlet via OTA (Fig 1_11).
After a splash image we choose apps option and we see the list of MIDlet the JAM installed. Now we can use menu option to manage a particular MIDlet (Fig1_12).
The JAM gives us the option to execute the MIDlet, obtain info about that, remove or update that. In our case the MIDlet is very simple but, ad we’ll see about I/O management, the JAM will ask the user permission about every sensible operation the MIDlet declares to do within its JAD file.
Our first MIDlet shortly
As we said before we’ll treat the MIDlet class and its lifecycle in details in the next module. Here we’d like to describe some important things about MIDlet class and its analogy with the Applet class. We remember that an Applet is a particular Java application running into the browser sandbox or, better, a JVM implementation with limited power for security reasons. An applet is a specific implementation of the Applet class which describes all the callback methods the browser environment can call to interact with it. We can say the same for MIDlet. It’s a java application running inside a sandbox given by a particular device with limited resources. Like an Applet, a MIDlet ha a set of callback method which are called from the application we talked about before which is called Java Application Manager. By calling these methods, the JAM can interact with the MIDlet starting it, pausing and stopping it as a consequence of particular events which can be external (receiving a call) or generated by users (explicitly stopping of the MIDlet). So, our simple MIDlet is a particular realization of the MIDlet class from the javax.microedition.midlet package.
We did a very simple realization of these methods:
public void startApp();
public void pauseApp();
public void destroyApp(boolean unconditional)
that, as we’ll see in the next module, permits us an accurate MIDlet state management.
In this first module we introduced fundamental concepts about J2ME Configuration, Profile and Optional packages. We talked about MIDlet development process and WTK 2.5 which is the tool we’ll use during this course for MIDlet development. We’ll close with a description of the execution of the MIDlet in OTA mode. In next module we’ll start dive into MIDlet code studying execution lifecycle.
About the author
Massimo Carli (http://www.massimocarli.it/site) is a Java Architect working as Software Consulting in Italy. He has over 12 years of experience in Java and Internet application. One of the founders of Mokabyte (http://www.mokabyte.it), he has written more than 100 articles about Java, Perl and UML for italian magazines. Certified also as J2ME programmer he has written a book about MIDP 2.0 (in
italian) you can read at his personal site.
 Wireless ToolKit 2.5
Related Download: MyFirstProject.zip