J2ME platform key to wireless handsets

The inherent complexities of integrating local and remote services in wireless handsets is no longer just "a simple matter of programming." Local services for barcode scanning, scalable vector graphics, full-motion video, and voice navigation are growing. In addition remote services such as location (GPS) based services, transactional and messaging services are becoming very popular. To do it all faster requires two things; the right platform, and the right tools.

While the role of Java is hidden from the end-user, it will play an important role for developers-especially in 3G / 2.5G terminals and infrastructure. With the right tools, integration of an RTOS and J2ME certified runtimes can be optimized for the wireless handset market. And, selecting the best J2ME implementation is important, as is the implementation of the "platform", the underlying RTOS and virtual machine.

One of the largest costs in a 3G handset is the memory. Designing a device with loads of expensive RAM and high-performance flash is not an option for many manufacturers. The RTOS plays an important role in saving memory and so this should not be left entirely as a burden for the J2ME developer. The right RTOS needs not only to provide a scalable small footprint solution, but also should implement memory conserving features.

Memory methods include limiting the amount of RAM consumed during execution; preventing memory fragmentation; supporting persistent memory types and enabling flash memory to function as the work memory. Those methods are enhanced by execute-in-place (XIP) features and dynamic re-mapping of applications' memory pages between RAM and flash.

Building on a strong RTOS, J2ME platforms, at the simplest level, will assist in reducing the memory footprint for small devices by specifying the set of services available to an application on a compliant platform. This allows these services to be implemented once and then shared by each application.

In the wireless domain this also means improved performance, as only the application, not the core services, need to be deployed over the wireless connection.

At a deeper level, developers also need to look at the overall memory of an application as it runs on the device. Some virtual machines grab small amounts of memory up front to reduce the initial footprint, and incrementally grab memory, as it is needed. Others grab more memory up front, but less over time. The ideal solution is a virtual machine that is customizable and tunable.

Once the application has been designed and optimized, there are benefits to be realized in how it is deployed to the device. Depending on the type of application and the characteristics of the device, it may be more beneficial to execute the application out of flash rather than RAM. This technique could minimize RAM requirements or provide the application with an "instant-on" capability.

The execution speed of applications on these consumer handsets will continue to be an important success factor. Java applications have previously suffered a bad reputation because of their interpretive nature. While it's true that interpreters will generally run slower than compiled applications, the difference at the application level is not necessarily noticeable. In situations where it is noticeable, there are optimized runtime options such as Ahead-of-time (AOT) and Just-in-Time (JIT) compilation.

For example, a virtual machine implementation such as J9 in the WebSphere Micro Environment, even in software form, interprets byte code quickly. Complementing it with AOT and JIT provides the application developer with options for managing the speed versus memory cost trade-off. The significance of this flexibility is considerable given that the J9 virtual machine can execute applications deployed as byte codes, AOT or JIT compiled machine code, and most importantly, any combination of the three.

While ensuring reliability of standalone software applications, it is equally important to design a device with system robustness in mind. Downloaded applications and services cannot be allowed to corrupt the system. Separation of system critical and non-critical software is essential and the operating system in the device should provide isolation mechanisms and memory protection for this purpose.

For example, in the case of OSE's dynamic loading / unloading capabilities of native software (C/C++), protection mechanisms are used to ensure that loaded modules will be memory protected when taking advantage of the hardware memory management unit.

Introducing a Java runtime environment in a 3G handset — that takes advantage of an RTOS' inherent security — has the great benefit of providing a secure and protected environment for application software, which is often written in Java, adding to code size and affecting performance.

The handset's native environment (C/C++) which controls the device itself, will be protected from the Java application environment. In system architectures that would benefit from greater separation, multiple virtual machines could exist on the handset and could be started and stopped independently of each other. Additionally, when the RTOS supports native runtime downloads, even new, updated Java virtual machines can be dynamically installed after a handset is produced and deployed.

Deterministic real-time behavior is a requirement in today's 2G mobile phones. The baseband and radio, coding and decoding of voice, the air interface, connection of a call - all must be capable of delivering voice to any location in the world within fractions of a second. Moving to 3G handsets will not change the requirement for deterministic real-time behavior. Users will not accept calls suddenly being disconnected or the other party's voice sounding slow and distorted.

The challenge will be to keep today's excellent performance and reliability, while introducing the new services that high-speed packed-based data transmission enables. For multiple Java applications to co-exist in a resource-limited device, the Java runtime environment needs deterministic real-time behavior.

The first step in the delivery of real-time deterministic Java applications is the Java Community Process publication of the real time specification for Java (RTSJ) JSR 01. The specification defines classes and APIs that extend deterministic, performance tuning and memory-access related capabilities typical to real-time development. The design of the virtual machines has also moved forward to allow for deterministic execution. One specific area is in the area of garbage collection.

Real time systems need to recover memory efficiently. So in the selection of a JVM it is important to look for features such as precise garbage collection (GC) as opposed to conservative garbage collection. GC should also be incremental, so that the virtual machine is not locked during GC. In the most serious of deterministic cases, GC should also allow interrupts. This stops GC immediately for critical events to be processed at the highest possible priority. An example of this would be receiving an incoming phone call while gaming.

Having a virtual machine implement deterministic functions has limited value if the underlying RTOS does not implement real time elements, such as pre-emptive scheduling, lightweight processes, efficient interrupt handling with short interrupt latency, and scalability on a tens-of-kbyte level.

Beyond these classical features, there are other things to look for such as the use of a message based architecture to ensure ease-of-use, high performance, advanced debug capabilities, transparent IPC in distributed systems and memory protected systems. Another is the use of memory management techniques focused on performance even when using low-performance memory types.

Additional factors are efficient prevention of memory fragmentation through the use of multiple memory pools to allow robust system design, as well as automatic error handling with a multi-layered error handler approach. Because the net-centric Web Services environment will be multilingual for sometime to come, it will be important to integrate the Java and native C/C++ and assembler tooling environments effectively.

Being able to switch between task-aware freeze mode and run mode debugging is important in real-time systems as certain bugs cannot be found unless parts of the system can execute while others are frozen. Traditional source code debugging needs a complement in system level debugging where events can be traced, analyzed and design flaws can be found. Advanced system level debugging is possible when the system design is based on a message passing architecture with automatic resource cleaning. Profiling of the CPU and memory usage as well as post mortem debugging are other important tools.