This tutorial aims in teaching you Java ME technology in the simplest possible way. Please send your feedback to anoopengineer[at]gmail[dot]com.

Prerequisites

  1. Good knowledge on Core Java a.k.a Java SE.
  2. Sun Java Wireless Toolkit 2.5.1. See installation for details.
  3. A Little grey matter.


What we are going to learn

Java ME (earlier known as J2ME) is for creating java programs for mobile phones (I'm lying here a bit, but it will help you). You use an ordinary Windows/Linux desktop computer to write your program, emulate its working using the toolkit, and then transfer it to a mobile phone for installing.

For this, you need to install "Sun Java Wireless Toolkit" in your desktop. The current version of the toolkit as of writing this is 2.5.1. How to get the toolkit and install it is specified in the installation section. After going through this tutorial, you should be able to create all sorts of applications on your mobile.

Installation

Prior to installing Java Wireless Toolkit (here forth called WTK), you should have Java Runtime Environment installed in your computer. The download page for WTK gives more information on these.

After installing WTK, you should get a start menu entry as shown below.


Figure 1: Start Menu entry after installing WTK

Select the option ‘Wireless Toolkit 2.5’ (in older version it is called ktoolbar) and you should see the following windows coming up:

OK, now we have everything we need to get some Java ME gyan. Let’s start.

Java ME Basics

By saying Java ME, we refer to a number of classes, interfaces and a JVM that is needed to run a Java application on mobiles. To make things simple and to bring little peace to this chaotic world, these classes, interfaces and JVM are put into two layers: Configuration and Profile. Memorize these two jargon words; you will not regret doing it when you become ‘the el33t Java ME guru’.

Configuration

This is the most underlying layer of Java ME and not surprisingly, it contains the “special” JVM also. Now why do we need a special JVM? Why can’t we reuse the existing JVM that we use in our desktops? The reason is simple: your mobile phone has less computational muscle as compared to a desktop computer. So it simply can’t run the bulky and mighty JVM from the desktop world.

I said I was lying when I defined Java ME in the introduction. I said that Java ME is for creating java programs for mobile phones. Sure you can use Java ME technology to develop application for mobile phones, but its scope is not just limited to mobile phones. Java ME is currently used on a multitude device like pagers, set-top boxes, car navigation systems and a number of embedded systems. The only requirement to use Java ME is that the device should have some sort of connectivity: a powerful Ethernet connection or a weak wireless connection.

There are two types of configuration:

  • CDC and
  • CLDC

CDC stands for ‘Connected Device Configuration’ and CLDC for ‘Connected Limited Device Configuration’.

CDC aims at devices that are a little bit more powerful than a mobile phone; devices like a Set-top box or a Car Navigation system. I have mentioned that configuration contained the JVM. The virtual machine in CDC is called CVM (Compact Virtual Machine).

Mobile phones use CLDC as the configuration. The VM used in CLDC is termed KVM (K because it runs on Kilobytes of memory).

CVM

This VM is a complete clone of the desktop Java JVM. It contains all the power, all the abilities of the former. Only difference is that it can run in a much-restricted environment: restricted memory, restricted computational power, restricted storage facility.

KVM

This is a stripped down version of the desktop VM. It is designed for smaller device like a mobile phone and for a smaller memory footprint. It doesn’t support all features of conventional JVM like the object serialization, finalization etc.

In addition to the JVM the configuration also contains all the classes, interfaces and exceptions that Java ME subsets from Java SE. A list of all classes contained in CLDC can be obtained here.

The configuration used in mobile phones is CLDC, and hence this will be our area of interest.

CLDC

Some of the limitations of the CLDC are given below. A programmer need to be aware of such limitations to avoid serious trouble later on.

  • No floating point support.
  • No object finalization.
  • No JNI support.
  • No reflection.
  • No thread groups and daemon threads.
  • No application defined class loaders.
  • Implementation defined error handling.
  • Different form of class verification.

Profile

A profile extends the configuration. It adds domain specific classes to the core. It is geared towards a specific use of the device. For example, not every device need to have a screen. For devices that have one, the APIs to manage the screen is included in a profile.

There are different types of profiles like MIDP, Foundation Profile, Personal Profile, Personal Basis Profile etc. The profile used in mobile phones is MIDP, and hence this will be our area of interest.

MIDP

Mobile Information Device Profile extends the CLDC configuration. JSR 37 introduced MIDP 1.0, while JSR 118 introduced MIDP 2.0.

MIDP 1.0 contained APIs for UI creation, local persistence mechanism, networking and MIDlet life-cycle management. (An application written using MIDP APIs is called a MIDlet). In addition to these, MIDP 2.0 added APIs for a robust security policy, APIS for sound and gaming and extended the networking APIs to include TCP socket streams, UDP datagrams, serial, push-initiated and secure connections.

You may not know a lot of things said above. Don’t worry just read along. You will catch up in no time.