Wednesday, August 09, 2006
J2ME for beginers
Configurations
A configuration specifies a JVM and some set of core APIs for a specific family of devices. Currently there are two: the Connected Device Configuration (CDC) and the Connected, Limited Device Configuration (CLDC).
Connected Device Configuration
A connected device has, at a minimum, 512KB of read-only memory (ROM), 256KB of random access memory (RAM), and some kind of network connection. The CDC is designed for devices like television set-top boxes, car navigation systems, and high end PDAs. The CDC specifies that a full JVM (as defined in the Java Virtual Machine Specification, 2nd edition) must be supported.
The configurations and profiles of J2ME are generally described in terms of their memory capacity. Usually a minimum amount of ROM and RAM is specified. For small devices, it makes sense to think in terms of volatile and non-volatile memory. The non-volatile memory is capable of keeping its contents intact as the device is turned on and off. ROM is one type, but non-volatile memory could also be flash memory or battery-backed RAM. Volatile memory is essentially workspace and does not maintain its contents when the device is turned off.
The CDC is being developed under the Java Community Process. For more information on the CDC, see http://java.sun.com/products/cdc/. A Linux reference implementation is available.
The CDC is the basis of the Personal Profile stack. The Personal Profile is the next generation of PersonalJava, a Java application environment that is similar to JDK 1.1.8.
Connected, Limited Device Configuration
CLDC is the configuration that interests us, because it encompasses mobile phones, pagers, PDAs, and other devices of similar size. CLDC is aimed at smaller devices than the CDC. The name is a little misleading; really, the CLDC is designed for a small device with a limited network connection—"Limited Connection Device Configuration" might have been more accurate.
The CLDC is designed for devices with 160KB to 512KB of memory available for the Java platform. If you've ever watched J2SE gobble up tens of megabytes of memory on your desktop computer, you'll appreciate the challenge of J2ME. The "limited connection" simply refers to a network connection that is intermittent and probably not very fast. (Most mobile telephones, for example, typically achieve data rates of 9.6Kbps.) Between the small screen size, limited memory, and slow network connection, applications designed in the CLDC space should be very sparing with the use of the network connection.
The CLDC is based around a small JVM called the KVM. Its name comes from the fact that it is a JVM whose size is measured in kilobytes rather than megabytes. While the CLDC is a specifications document, the KVM refers to a specific piece of software. [1] Because of its small size, the KVM can't do everything a JVM does in the J2SE world.
Native methods cannot be added at runtime. All native functionality is built into the KVM.
The KVM only includes a subset of the standard bytecode verifier. This means that the task of verifying classes is split between the CLDC device and some external mechanism. This has serious security implications, as we'll discuss later.
You can find more information at the CLDC home page, http://java.sun.com/products/cldc/. Most deployed devices implement CLDC 1.0, but CLDC 1.1 is almost complete as this is written. CLDC 1.1 includes enhancements to CLDC 1.0, including support for floating-point data types.
Platform Standardization
Given the profusion of configurations, profiles, and especially optional APIs, how do you know what APIs are likely to be available on typical devices? Sun's answer to this question is JSR 185 (http://jcp.org/jsr/detail/185.jsp), impressively titled Java Technology for the Wireless Industry. This specification aims to standardize software stacks to bring coherence to the J2ME world.
In the next generation of J2ME, a concept called Building Blocks is supposed to replace configurations and profiles. A Building Block is just some subset of a J2SE API. For example, one Building Block might be created from a subset of the J2SE java.io package. Conceptually, a Building Block represents a smaller chunk of information than a configuration. Profiles, then, will be built on top of a set of Building Blocks rather than a configuration.
The definition of Building Blocks is a JSR, which is briefly described here: http://jcp.org/jsr/detail/68.jsp. Progress on JSR 68 has been extremely slow since its creation in June 2000. I suggest keeping your eyes on JSR 185 instead.
[1]The KVM was originally part of the Spotless system, a Sun research project. See http://www.sun.com/research/spotless/.
A profile is layered on top of a configuration (and someday, perhaps, on Building Blocks), adding the APIs and specifications necessary to develop applications for a specific family of devices.
Current Profiles
Several different profiles are being developed under the Java Community Process. The Foundation Profile is a specification for devices that can support a rich networked J2ME environment. It does not support a user interface; other profiles can be layered on top of the Foundation Profile to add user interface support and other functionality.
Layered on top of the Foundation Profile are the Personal Basis Profile and the Personal Profile. The combination of CDC + Foundation Profile + Personal Basis Profile + Personal Profile is designed as the next generation of the PersonalJava application runtime environment (see http://java.sun.com/products/personaljava/). As such, the Personal Profile has the specific goal of backward compatibility with previous versions of PersonalJava.
The PDA Profile (PDAP), which is built on CLDC, is designed for palmtop devices with a minimum of 512KB combined ROM and RAM (and a maximum of 16MB). It sits midway between the Mobile Information Device Profile (MIDP) and the Personal Profile. It includes an application model based on MIDlets but uses a subset of the J2SE Abstract Windowing Toolkit (AWT) for graphic user interface. Although the PDAP specification is nearly finished, to my knowledge no hardware manufacturer has announced that it will be implementing PDAP. The J2ME world currently is covered by MIDP on the small end and Personal Profile on the higher end.
Mobile Information Device Profile
The focus of this book is the Mobile Information Device Profile (MIDP). According to the specification, a Mobile Information Device has the following characteristics:
128KB of non-volatile memory for the MIDP implementation
32KB of volatile memory for the runtime heap
8KB of non-volatile memory for persistent data
A screen of at least 96 × 54 pixels
Some capacity for input, either by keypad, keyboard, or touch screen
Two-way network connection, possibly intermittent
Try to imagine a device that might be a MIDP device: mobile telephones and advanced pagers are right in the groove, but entry-level PDAs could also fit this description.
More information about MIDP, including a link to the official specification document, is at http://java.sun.com/products/midp/.
This book covers both MIDP 1.0 and MIDP 2.0. MIDP 2.0 features numerous enhancements, including support for multimedia, a new game user interface API, support for HTTPS connection, and other features. It is fully backward compatible with MIDP 1.0. I will indicate features that are specific to MIDP 2.0 throughout the rest of the book.
Given the spectrum of configurations and profiles, why is this book about MIDP? First, MIDP comes at a critical time, a time when MIDP devices, like mobile phones, are an exploding market. Simultaneously, MIDP devices are achieving the kind of processing power, memory consumption, and Internet connectivity that makes them an attractive platform for distributed applications. MIDP 1.0 is already deployed on millions of handsets all over the world, and MIDP 2.0 holds much promise for the future.
Second, of course, MIDP is the first J2ME profile that is ready for prime time. If you read into the next chapter, you can write MIDP applications today.
Portability
The advantage of using Java over using other tools for small device application development is portability. You could write device applications with C or C++, but the result would be specific to a single platform. An application written using the MIDP APIs will be directly portable to any MIDP device.
If you've been following Java's development for any time, this should sound familiar. It's the same "Write Once, Run Anywhere" (WORA) mantra that Sun's been repeating since 1995. Unfortunately, WORA is a bit of a four-letter word for developers who struggled with cross-platform issues in JDK 1.0 and JDK 1.1 (particularly the browser implementations). While Java's cross-platform capabilities in Java 2 are generally successful, WORA still has the taint of an unfulfilled promise.
Does MIDP deliver painless cross-platform functionality? Yes. There will always be platform-specific bugs in MIDP implementations, but I believe MIDP works as advertised because it is so much smaller than desktop Java. Less code means fewer bugs when porting to multiple platforms. Most of the cross-platform incompatibilities of JDK 1.0 and JDK 1.1 were caused by the nightmare of trying to fit disparate windowing systems into the AWT's peer-based component architecture. MIDP has nothing approaching the complexity of AWT, which means there's an excellent possibility that MIDP applications will seamlessly run on multiple platforms right out of the starting gate. Furthermore, while the JDK 1.0 test suite only included a few dozen tests, the MIDP compatibility test suite includes several thousand tests.
Security
A second compelling reason for using Java for small device development is security. Java is well known for its ability to safely run downloaded code like applets. This is a perfect fit—it's easy to imagine nifty applications dynamically downloading to your mobile phone.
But it's not quite such a rosy picture. For one thing, the KVM used in the CLDC only implements a partial bytecode verifier, which means that part of the important task of bytecode verification is performed off the MIDP device.
Second, the CLDC does not allow for application-defined classloaders. This means that any kind of dynamic application delivery is dependent on device-specific mechanisms. As you'll see, application deployment is not specifically defined in the CLDC or MIDP.
MIDP applications do offer one important security promise: they can never escape from the confines of the KVM. This means that, barring bugs, a MIDP application will never be able to write to device memory that doesn't belong to the KVM. 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, then verified on the device, which gives users some security about executing downloaded code. A new permissions architecture 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, you can prevent it from making network connections.
[2]A MIDP application could conceivably launch a denial-of-service attack, (i.e., 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.
Tooling Up
MIDlets are developed on regular desktop computers, although the MIDlet itself is designed to run on a small device. To develop MIDlets, you'll need some kind of development kit, either from Sun or another vendor. Remember, MIDP is only a specification; vendors are free to develop their own implementations.
The world is full of MIDlet development tools if you know where to look. Furthermore, many of these tools are freely available.
The bare bones set of tools is Sun's MIDP reference implementation. This includes the preverify tool (more on this later), a MIDP device emulator, source code, and documentation. You can download the MIDP reference implementation by following the links from http://java.sun.com/products/midp/. However, I don't recommend using the reference implementation unless you really enjoy being in the middle of the gritty details of building and packaging MIDlets. (You should also investigate the reference implementation if you are interested in porting the MIDP runtime to a new device or platform.)
A much better tool for beginners is Sun's J2ME Wireless Toolkit, available from http://java.sun.com/products/j2mewtoolkit/. The J2ME Wireless Toolkit (or J2MEWTK, as it's affectionately known) includes a GUI tool that automates some of the tedious details of building and packaging MIDlets, providing a simple path from source code to running MIDlets. At the same time, the J2ME Wireless Toolkit is a relatively lightweight solution, almost a miniature IDE, not something that will choke your machine.
Larger IDEs are available in abundance, from device manufacturers, wireless carriers, and IDE vendors, including the following:
Borland JBuilder MobileSet: http://www.borland.com/jbuilder/mobileset/
IBM WebSphere Studio Device Developer: http://www-3.ibm.com/software/pervasive/products/wsdd/
Metrowerks CodeWarrior Wireless Studio: http://www.metrowerks.com/MW/Develop/Wi ... efault.htm
Research In Motion BlackBerry Java Development Environment: http://www.blackberry.net/developers/na ... load.shtml
Sun ONE Studio, Mobile Edition: http://wwws.sun.com/software/sundev/jde ... tures.html
Zucotto Wireless WHITEboard SDK: http://www.zucotto.com/products/wb/whiteboard.html
You can use whatever development kit you wish. I suggest you start with the J2ME Wireless Toolkit, which is easy to use and authoritative. I'll be using the J2ME Wireless Toolkit throughout the rest of the book. Other development environments generally use the J2ME Wireless Toolkit as a plugin anyhow, so your experiences are likely to be similar no matter what tool you use. You'll notice details about the development environment most in this chapter, where I'll go into detail about the build tools and the emulators. For much of the remainder of this book, I'll be describing the MIDP APIs, so it won't really matter which development kit you use.
A configuration specifies a JVM and some set of core APIs for a specific family of devices. Currently there are two: the Connected Device Configuration (CDC) and the Connected, Limited Device Configuration (CLDC).
Connected Device Configuration
A connected device has, at a minimum, 512KB of read-only memory (ROM), 256KB of random access memory (RAM), and some kind of network connection. The CDC is designed for devices like television set-top boxes, car navigation systems, and high end PDAs. The CDC specifies that a full JVM (as defined in the Java Virtual Machine Specification, 2nd edition) must be supported.
The configurations and profiles of J2ME are generally described in terms of their memory capacity. Usually a minimum amount of ROM and RAM is specified. For small devices, it makes sense to think in terms of volatile and non-volatile memory. The non-volatile memory is capable of keeping its contents intact as the device is turned on and off. ROM is one type, but non-volatile memory could also be flash memory or battery-backed RAM. Volatile memory is essentially workspace and does not maintain its contents when the device is turned off.
The CDC is being developed under the Java Community Process. For more information on the CDC, see http://java.sun.com/products/cdc/. A Linux reference implementation is available.
The CDC is the basis of the Personal Profile stack. The Personal Profile is the next generation of PersonalJava, a Java application environment that is similar to JDK 1.1.8.
Connected, Limited Device Configuration
CLDC is the configuration that interests us, because it encompasses mobile phones, pagers, PDAs, and other devices of similar size. CLDC is aimed at smaller devices than the CDC. The name is a little misleading; really, the CLDC is designed for a small device with a limited network connection—"Limited Connection Device Configuration" might have been more accurate.
The CLDC is designed for devices with 160KB to 512KB of memory available for the Java platform. If you've ever watched J2SE gobble up tens of megabytes of memory on your desktop computer, you'll appreciate the challenge of J2ME. The "limited connection" simply refers to a network connection that is intermittent and probably not very fast. (Most mobile telephones, for example, typically achieve data rates of 9.6Kbps.) Between the small screen size, limited memory, and slow network connection, applications designed in the CLDC space should be very sparing with the use of the network connection.
The CLDC is based around a small JVM called the KVM. Its name comes from the fact that it is a JVM whose size is measured in kilobytes rather than megabytes. While the CLDC is a specifications document, the KVM refers to a specific piece of software. [1] Because of its small size, the KVM can't do everything a JVM does in the J2SE world.
Native methods cannot be added at runtime. All native functionality is built into the KVM.
The KVM only includes a subset of the standard bytecode verifier. This means that the task of verifying classes is split between the CLDC device and some external mechanism. This has serious security implications, as we'll discuss later.
You can find more information at the CLDC home page, http://java.sun.com/products/cldc/. Most deployed devices implement CLDC 1.0, but CLDC 1.1 is almost complete as this is written. CLDC 1.1 includes enhancements to CLDC 1.0, including support for floating-point data types.
Platform Standardization
Given the profusion of configurations, profiles, and especially optional APIs, how do you know what APIs are likely to be available on typical devices? Sun's answer to this question is JSR 185 (http://jcp.org/jsr/detail/185.jsp), impressively titled Java Technology for the Wireless Industry. This specification aims to standardize software stacks to bring coherence to the J2ME world.
In the next generation of J2ME, a concept called Building Blocks is supposed to replace configurations and profiles. A Building Block is just some subset of a J2SE API. For example, one Building Block might be created from a subset of the J2SE java.io package. Conceptually, a Building Block represents a smaller chunk of information than a configuration. Profiles, then, will be built on top of a set of Building Blocks rather than a configuration.
The definition of Building Blocks is a JSR, which is briefly described here: http://jcp.org/jsr/detail/68.jsp. Progress on JSR 68 has been extremely slow since its creation in June 2000. I suggest keeping your eyes on JSR 185 instead.
[1]The KVM was originally part of the Spotless system, a Sun research project. See http://www.sun.com/research/spotless/.
A profile is layered on top of a configuration (and someday, perhaps, on Building Blocks), adding the APIs and specifications necessary to develop applications for a specific family of devices.
Current Profiles
Several different profiles are being developed under the Java Community Process. The Foundation Profile is a specification for devices that can support a rich networked J2ME environment. It does not support a user interface; other profiles can be layered on top of the Foundation Profile to add user interface support and other functionality.
Layered on top of the Foundation Profile are the Personal Basis Profile and the Personal Profile. The combination of CDC + Foundation Profile + Personal Basis Profile + Personal Profile is designed as the next generation of the PersonalJava application runtime environment (see http://java.sun.com/products/personaljava/). As such, the Personal Profile has the specific goal of backward compatibility with previous versions of PersonalJava.
The PDA Profile (PDAP), which is built on CLDC, is designed for palmtop devices with a minimum of 512KB combined ROM and RAM (and a maximum of 16MB). It sits midway between the Mobile Information Device Profile (MIDP) and the Personal Profile. It includes an application model based on MIDlets but uses a subset of the J2SE Abstract Windowing Toolkit (AWT) for graphic user interface. Although the PDAP specification is nearly finished, to my knowledge no hardware manufacturer has announced that it will be implementing PDAP. The J2ME world currently is covered by MIDP on the small end and Personal Profile on the higher end.
Mobile Information Device Profile
The focus of this book is the Mobile Information Device Profile (MIDP). According to the specification, a Mobile Information Device has the following characteristics:
128KB of non-volatile memory for the MIDP implementation
32KB of volatile memory for the runtime heap
8KB of non-volatile memory for persistent data
A screen of at least 96 × 54 pixels
Some capacity for input, either by keypad, keyboard, or touch screen
Two-way network connection, possibly intermittent
Try to imagine a device that might be a MIDP device: mobile telephones and advanced pagers are right in the groove, but entry-level PDAs could also fit this description.
More information about MIDP, including a link to the official specification document, is at http://java.sun.com/products/midp/.
This book covers both MIDP 1.0 and MIDP 2.0. MIDP 2.0 features numerous enhancements, including support for multimedia, a new game user interface API, support for HTTPS connection, and other features. It is fully backward compatible with MIDP 1.0. I will indicate features that are specific to MIDP 2.0 throughout the rest of the book.
Given the spectrum of configurations and profiles, why is this book about MIDP? First, MIDP comes at a critical time, a time when MIDP devices, like mobile phones, are an exploding market. Simultaneously, MIDP devices are achieving the kind of processing power, memory consumption, and Internet connectivity that makes them an attractive platform for distributed applications. MIDP 1.0 is already deployed on millions of handsets all over the world, and MIDP 2.0 holds much promise for the future.
Second, of course, MIDP is the first J2ME profile that is ready for prime time. If you read into the next chapter, you can write MIDP applications today.
Portability
The advantage of using Java over using other tools for small device application development is portability. You could write device applications with C or C++, but the result would be specific to a single platform. An application written using the MIDP APIs will be directly portable to any MIDP device.
If you've been following Java's development for any time, this should sound familiar. It's the same "Write Once, Run Anywhere" (WORA) mantra that Sun's been repeating since 1995. Unfortunately, WORA is a bit of a four-letter word for developers who struggled with cross-platform issues in JDK 1.0 and JDK 1.1 (particularly the browser implementations). While Java's cross-platform capabilities in Java 2 are generally successful, WORA still has the taint of an unfulfilled promise.
Does MIDP deliver painless cross-platform functionality? Yes. There will always be platform-specific bugs in MIDP implementations, but I believe MIDP works as advertised because it is so much smaller than desktop Java. Less code means fewer bugs when porting to multiple platforms. Most of the cross-platform incompatibilities of JDK 1.0 and JDK 1.1 were caused by the nightmare of trying to fit disparate windowing systems into the AWT's peer-based component architecture. MIDP has nothing approaching the complexity of AWT, which means there's an excellent possibility that MIDP applications will seamlessly run on multiple platforms right out of the starting gate. Furthermore, while the JDK 1.0 test suite only included a few dozen tests, the MIDP compatibility test suite includes several thousand tests.
Security
A second compelling reason for using Java for small device development is security. Java is well known for its ability to safely run downloaded code like applets. This is a perfect fit—it's easy to imagine nifty applications dynamically downloading to your mobile phone.
But it's not quite such a rosy picture. For one thing, the KVM used in the CLDC only implements a partial bytecode verifier, which means that part of the important task of bytecode verification is performed off the MIDP device.
Second, the CLDC does not allow for application-defined classloaders. This means that any kind of dynamic application delivery is dependent on device-specific mechanisms. As you'll see, application deployment is not specifically defined in the CLDC or MIDP.
MIDP applications do offer one important security promise: they can never escape from the confines of the KVM. This means that, barring bugs, a MIDP application will never be able to write to device memory that doesn't belong to the KVM. 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, then verified on the device, which gives users some security about executing downloaded code. A new permissions architecture 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, you can prevent it from making network connections.
[2]A MIDP application could conceivably launch a denial-of-service attack, (i.e., 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.
Tooling Up
MIDlets are developed on regular desktop computers, although the MIDlet itself is designed to run on a small device. To develop MIDlets, you'll need some kind of development kit, either from Sun or another vendor. Remember, MIDP is only a specification; vendors are free to develop their own implementations.
The world is full of MIDlet development tools if you know where to look. Furthermore, many of these tools are freely available.
The bare bones set of tools is Sun's MIDP reference implementation. This includes the preverify tool (more on this later), a MIDP device emulator, source code, and documentation. You can download the MIDP reference implementation by following the links from http://java.sun.com/products/midp/. However, I don't recommend using the reference implementation unless you really enjoy being in the middle of the gritty details of building and packaging MIDlets. (You should also investigate the reference implementation if you are interested in porting the MIDP runtime to a new device or platform.)
A much better tool for beginners is Sun's J2ME Wireless Toolkit, available from http://java.sun.com/products/j2mewtoolkit/. The J2ME Wireless Toolkit (or J2MEWTK, as it's affectionately known) includes a GUI tool that automates some of the tedious details of building and packaging MIDlets, providing a simple path from source code to running MIDlets. At the same time, the J2ME Wireless Toolkit is a relatively lightweight solution, almost a miniature IDE, not something that will choke your machine.
Larger IDEs are available in abundance, from device manufacturers, wireless carriers, and IDE vendors, including the following:
Borland JBuilder MobileSet: http://www.borland.com/jbuilder/mobileset/
IBM WebSphere Studio Device Developer: http://www-3.ibm.com/software/pervasive/products/wsdd/
Metrowerks CodeWarrior Wireless Studio: http://www.metrowerks.com/MW/Develop/Wi ... efault.htm
Research In Motion BlackBerry Java Development Environment: http://www.blackberry.net/developers/na ... load.shtml
Sun ONE Studio, Mobile Edition: http://wwws.sun.com/software/sundev/jde ... tures.html
Zucotto Wireless WHITEboard SDK: http://www.zucotto.com/products/wb/whiteboard.html
You can use whatever development kit you wish. I suggest you start with the J2ME Wireless Toolkit, which is easy to use and authoritative. I'll be using the J2ME Wireless Toolkit throughout the rest of the book. Other development environments generally use the J2ME Wireless Toolkit as a plugin anyhow, so your experiences are likely to be similar no matter what tool you use. You'll notice details about the development environment most in this chapter, where I'll go into detail about the build tools and the emulators. For much of the remainder of this book, I'll be describing the MIDP APIs, so it won't really matter which development kit you use.
# posted by codetiger @ 6:55 AM 
