Introduction - Beginning J2ME: From Novice to Professional - page 9

MIDP applications do offer one important security promise: they can never escape from
the confines of the JVM. This means that, barring bugs, a MIDP application will never be able
to write to device memory that doesn't belong to the JVM. A MIDP application will never mess
up another application on the same device or the device OS itself. 2 This is the killer feature of
MIDP. It allows manufacturers and carriers to open up application development to the world,
more or less free from certification and verification programs, without the fear that rogue coders
will write applications that crash phones.
In MIDP 2.0, MIDlet suites can be cryptographically signed, and then verified on the device,
which gives users some security about executing downloaded code. A new permissions archi-
tecture also allows the user to deny untrusted code access to certain API features. For example,
if you install a suspicious-looking MIDlet suite on your phone, it will only be able to make network
connections if you explicitly allow it to do so.

MIDP Vendors
Several large players have thrown their weight behind MIDP. A quick browse of the JSR page for
MIDP exposes the most important companies.
Two Asian companies led the charge to provide network services for Java-enabled mobile
phones. In Korea, LG TeleCom deployed a service called ez-i in mid-2000. Later that same year,
NTT DoCoMo deployed their wildly popular i-mode. The APIs developed for LG TeleCom
(KittyHawk) and NTT DoCoMo (i-Appli) are similar to MIDP but were completed before the
MIDP 1.0 specification.
In the United States, Motorola was the first manufacturer to produce a MIDP telephone.
The i50sx and i85s were released on April 2, 2001, with service provided by Nextel. Motorola has
since expanded its offerings with a handful of new devices.
Nokia has also made serious commitments to MIDP, and the expert group that created the
MIDP specification includes an impressive list of manufacturers—Ericsson, Hitachi, Nokia, Sony,
Symbian, and many more. You can go read the industry predictions if you wish—a gazillion MIDP
phones sold in the next three years, and so on. It's a safe bet that your MIDP application will have a
large market. For a comprehensive listing of MIDP devices, visit http://wireless.java.sun.com/
device/ .

Fragmentation
Platform fragmentation is a serious concern in the MIDP community. Many devices that imple-
ment MIDP 1.0 also include device-specific APIs. These APIs access device-specific features or
provide functionality that wasn't addressed in MIDP 1.0's least-common-denominator specifica-
tion. Current software vendors, particularly game developers, sometimes create and distribute
multiple versions of an application, each tailored to a specific platform. Obviously this is a
concern: part of the point of using MIDP in the first place is the ability to write one set of code
and deploy it on multiple platforms.

2. A MIDP application could conceivably launch a denial-of-service attack (that is, sucking up all the

processor's time or bringing the device OS to a standstill). It's widely acknowledged that there's not
much defense against denial-of-service attacks. Applications and applets in J2SE suffer from the
same vulnerability.