J2ME

J2ME

Now that we have investigated a popular wireless markup language, we will look at a more robust language designed to run applications on limited devices without regard to operating system. Java is a versatile programming language. Sun's Java 2 Programming Language consists of three versions:

1.       Java 2 Enterprise Edition

2.       Java 2 Standard Edition

3.       Java 2 Micro Edition

The version we focus on in this text is, of course, Java 2 Micro Edition (J2ME). By way of introduction, we take a brief look at the overall structure of Java. For various reasons, Java is a highly utilized language for many applications. It is object-oriented, has automatic garbage collection and exception handling, and allows multithreading. For those familiar with C++, it has similar syntax and is also object-oriented.

We mentioned that Java is designed to run without regard to the operating system. In wireless programming, this is not necessarily an advantage. In the wireless world today, application development is device-specific and operating system specific more often than not. The ability to port one application across operating systems is not often seen. J2ME is not available on all devices or platforms. Thus, porting and device-specific code are a viable way of implementing wireless applications. This is rapidly changing with the release of Motorola phones that support J2ME and personal Java.

Components of Java

For those of you not acquainted with Java, this section provides a high-level overview so that you can gain a basic level of familiarity with Java terminology and functionality. The two major components of the Java Runtime Environment (JRE), the part of Java that makes a program run, are its execution engine and several runtime libraries. The Java Virtual Machine (VM or JVM) is the core of the execution engine. Virtual machines enable coders to run a program on any architecture just by porting the VM. The capability to move a VM from one architecture to another to run a program on multiple physical or logical architectures is why Java is so portable. The VM alone does not provide complete portability. Portability is achieved through the assistance of the class file format and the standard runtime libraries.

The JVM gets its specifications from the Java Virtual Machine Specifications (JVMS), available from www.sun.com. The JVM is given instructions for operations termed bytecodes. Bytecodes can be separated into two categories:

1.       Bytecodes for operations that any machine architecture supports (for example, reading and writing memory, simple arithmetic operations)

2.       Bytecodes specific to the Java language

The javap tool, available as part of Sun's Java Development Kit (JDK), enables you to see how Java code is translated into bytecode.

The Java class file format is the required format for bytecode to be input into the VM. The class file format greatly aids in portability. The JVMS takes care of the differences in a class file from one architecture to another. If you input a class file to the VM compiled on architecture A, it can be moved to a machine of architecture B without modification.

The garbage collector is an important feature of Java. There is no Java keyword used for deallocating objects. Instead, the garbage collector is in charge of reclaiming unused memory. Certain pros and cons are associated with automatic garbage collection, rather than requiring programmers to deallocate objects explicitly. Java programmers have little control over garbage collection, but they can develop certain habits to make the process more efficient. For instruction on these habits, you can consult a well-respected Java programming resource. Especially when designing a wireless program, you will find this worth understanding and implementing correctly. Making applications efficient becomes increasingly important as the limitations on the device itself, due to architecture, become more stringent.

The class loader is the component that helps the VM locate the classes it needs for a given application. There are two categories of class loaders. System class loaders store the essential runtime classes and the application classes when necessary. The classes are put into memory so that the virtual machine can access them. User class loaders (nonsystem class loaders) help provide application-specific methods of finding class files. For example, a WAP browser could load a class loader that gets classes from Wireless Transport Protocol (WTP) from a WAP gateway and a Web server. Class loaders store loaded classes to save the costs associated with retrieving classes when they are referenced.

The class verifier processes a class after the class loader loads it. The verifier serves an important purpose: It checks the bytecode for illegalities (ensuring that classes are well formed and that the bytecode follows the Java-specified typing rules), checks that enough stack is allocated for each section of code, and so on. The verifier is one defense against malicious programs. It can prevent unwanted or unrecognized classes from being placed on a device without the intended application's prior consent.

The last component of the execution engine we will visit in this chapter is the native code interface. This last component ties Java to the architecture's operating system. It defines how the virtual machine calls native code and how native code makes calls back into the execution engine to create new objects, invoke methods, or set and get field values.

The last component in our brief Java tutorial is the Java runtime libraries. We mentioned earlier that these libraries aid the VM and the class file format in establishing Java's hallmark portability. Java depends on these libraries for interacting with the system and to provide useful shortcuts to standard programming tasks. This veritable shorthand saves programming time and allows for standardization across developers' implementations. There are various groups of runtime libraries, and the functions of some blur the lines between Java and the libraries themselves. The core of the Java runtime library is the java.lang package. Some of its classes are referred to directly by the JVM. They are usually initialized as defaults, along with other core classes, at start-up:

         Object. Is the root of all class and interface hierarchies

         Class. Defines information about a class

         ClassLoader. Loads classes

         String. Stores string constants

         Throwable. Declares and throws exception information

Flavors of Java

Over the past several years, Java has unfolded into many different flavors. Figure 5.1 illustrates the relationship among some. Early versions of Java focus on different kinds of programming. Java 1.2, the current version (familiarly called Java 2 as a marketing ploy more than a version control number), was designed for Enterprise programming. Java 1.02, the first public version, focuses on client programming; Java 1.1 focuses on server programming.

Figure 5.1. Different flavors of Java

graphics/05fig01.gif

Java 2 has a unique naming convention from Java 1.x. Recognizing the need for different sizes and functions of Java, Java 2 is available in several flavors. Within the Java 2 version are several groups of core APIs, which make up the different editions. The veritable plethora of programming interfaces is overwhelming. Many of these APIs are defined and controlled by entities outside Sun's realm. Sun recognized that it could not develop APIs fast enough to keep up with demand, so it enabled these external groups to do so by developing the Java Community Process. External groups develop APIs that are publicly available as long as they comply with Sun's Java API requirements. Sun does not, however, include every API in its core. Sun decided to formalize the usage of its extra APIs by defining standard extensions. Some extra sets of APIs that are useful only to subsets of the Java community are available as extensions to the core APIs at an extra charge. Java 2 is also divided into three editions:

         Java 2 Standard Edition

         Java 2 Enterprise Edition

         Java 2 Micro Edition

Java 2 Standard Edition

J2SE targets much the same programs as earlier versions: basic client or server applications that do not require special APIs or interoperability with other object models or languages. J2SE is much too large for limited-capability devices such as wireless clients. One noteworthy feature of J2SE is its HotSpot execution engine (see http://java.sun.com/products/hotspot for a detailed description), designed to make Java more expedient. HotSpot is more discriminating in optimizing code than its predecessors and includes an improved garbage collector. Two versions of this new addition are available, HotSpot Client VM, geared towards use on clients where applications start easily, and HotSpot Server VM, geared towards use where applications are likely to be more intensive and taxing on a machine and are therefore server-side, where more optimization at start-up is possible.

Java 2 Enterprise Edition

J2EE subsumes J2SE. It is designed to meet the needs of enterprisewide programming and applications. J2EE is ideal for applications that must be available to thousands of clients, are largely server-based, and must be capable of interacting with legacy systems. J2EE allows large-scale applications to be deployed more easily than J2SE and with increased security. At the risk of blatancy, J2EE is also far too large for use on wireless clients. For more information on J2EE, consult its home page at http://java.sun.com/j2ee.

Java 2 Micro Edition

Finally, the Java 2 Edition important to wireless developers: Java 2 Micro Edition. J2ME selectively rewrites and removes integral components of the core runtime environment to make it easily portable to smaller constrained devices. Sun Microsystems' J2ME made its debut in June 1999. Almost shadowing this announcement was the introduction of its counterpart, a new virtual machine that could run simple Java programs on Palm OS devices. The specifications were not quite ironed out at this point, so the actual debut (and availability to the public) was not until the summer of 2000 after the specifications were finalized.

The new virtual machine, called the KVM, is optimized for small devices and makes possible much of the wireless development that occurs today. We will investigate the KVM shortly. The KVM (an abbreviation for an early name, Kuaui VM) runs well in a constrained environment. You can use the JVM in J2ME, and you would choose to do so when working in a 32-bit environment with a generous amount of memory. The KVM is used in a J2ME architecture where the architectures are either 16-bit or 32-bit and have limited memory.

Class Differences

J2ME is not a new form of Java. If an application is developed for J2ME, it is compatible with J2SE or J2EE, provided that the environments include the same extra APIs. J2ME works (mostly) seamlessly on a variety of devices. A big factor in being able to use this edition of Java on smaller platforms is to reduce the number of classes used. Some classes are left out by default, and others are reduced through a process that eliminates redundancies in methods. This constructs an actual subset of the J2SE runtime classes. The differences do not end in merely a reduction in size, however. If necessary, any classes that are part of the classic runtime environment can be stored in the VM's internal format instead of the normal class file format. Note, however, that user-defined classes must be readable in the normal class file format. Some of the classes that are eliminated at the start in J2ME provide ways of interacting with the external devices. J2ME therefore includes new classes tailored to meet the needs of the smaller devices for which it is selected.

Beyond the new and changed set of classes, we will discuss three components of J2ME:

         The virtual machine (KVM)

         Configurations

- Connection Limited Device Configuration (CLDC)

- Connected Device Configuration (CDC)

         Profiles

- Mobile Information Device Profile (MIDP)

- Others under development (PDA, Foundation, Personal)

Each item listed here contributes to enabling portability across a variety of limited resource devices.

K Virtual Machine

Our perusal of the smallest of the Java 2 versions begins with the KVM. The KVM is a small-footprint virtual machine for resource-constrained devices. It accepts almost the exact same set of bytecodes and class file format that the regular VM does. The goals in designing the KVM were that it be easy to understand and maintain, highly portable, and limited in size without sacrificing essential Java features. The KVM is a less fancy version of the JVM. It does not boast dynamic compilation or other more advanced performance optimization techniques. The KVM only runs at roughly half the speed of JDK 1.1 software without an improved compiler. The KVM does boast portability. Its release includes three choices of ports:

         Win32

         PalmOS (3.01 and up)

- Solaris

Sun's external partners have ported it to still other platforms, totaling just fewer than 30. Unlike some other limited Java implementations, the KVM supports dynamic class loading and regular class files, as well as a full Java technology bytecode set and JAR file formats.

As far as compatibility with the JVM, KVM's general goal is that it be fully compatible with the JVMS and Java Language Specifications. The main differences are found in the language levels. No hardware floating-point support exists on most resource-constrained devices because of space limitations, so the Connection Limited Device Configuration (CLDC) (which runs on top of the KVM and is discussed in detail in the next section), does not include floating-point support. The exceptions to total compatibility also include the fact that limitations prevent the use of the full J2SE platform security model and that the libraries included with CLDC are limited. For those of you more familiar with full-blown Java, the implementation differences of the VMs are that no JNI, reflection, thread groups, weak references, and finalization are included, as well as limited error handling support and a new implementation of bytecode verification.

The KVM garbage collector component is small and simple. It is nonmoving, nonincremental, single-space, designed to limit recursion, and optimized for small heaps (32 512K). Sun intends to release an alternative, more advanced garbage collector in the future. The advantages of the KVM garbage collector are that it does not move objects, allowing for a simple and clean code base, and that it uses less memory. The disadvantages inherent to the KVM are that object allocation is slower, memory fragmentation can cause it to run out of heap, and it induces latency when using large heaps in garbage collection, because it is nonincremental.

Configurations

To conceptualize the logical organization of J2ME, you have to understand more than just its virtual machine. You must understand the J2ME concepts of Configurations and Profiles. A configuration is composed of a virtual machine, core libraries, classes, and APIs. It specifies a general runtime environment for consumer electronic and embedded devices and acts as the Java platform on the device. A profile is an industry-defined specification of the Java APIs used by manufacturers and developers to address specific types of devices.

Configurations define the minimum capabilities and libraries for a virtual machine for the Java platform that will be available on all devices belonging to a family. All these devices will possess similar memory requirements and processing power. There are currently two specified configurations in J2ME: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). Both configurations are the results of Java Community Process efforts.

Connected Limited Device Configuration (CLDC)

The CLDC has standardized a portable, minimum-footprint Java chunk for resource-constrained devices. The CLDC configuration provides for a virtual machine and a set of core libraries for use in certain profiles that define requirements for given devices. One such profile, the Mobile Information Device Specification's Profile (MIDP), uses this configuration in designing applications for wireless or handheld devices. Accord-ing to Sun's community Web site describing the CLDC, the devices generally targeted with CLDC are characterized as follows:

         160 512K total memory (including both RAM and flash or ROM) is available for the Java platform.

         Power is limited (often powered by battery).

         Connectivity to a network is often intermittent (and/or wireless).

         Bandwidth is expected to be limited, 9600bps or less.

         User interfaces are primitive, with variable degrees of usability.

The most recent CLDC version includes several improvements over its immediate predecessor. It has a faster bytecode interpreter, an exact, compacting garbage collector, Java-level debugging APIs, and preverifier improvements, among others. This release also includes an implementation of CLDC for the Linux operating system. The static size of the CLDC platform, including both the VM and the libraries, is usually less than 128K. In addition to virtual machine and language features, CLDC specifications cover input/output, networking support, internalization, and a security model. Several components that you might expect to be there are intentionally omitted: application installation, user interface support, event handling, a high-level application model, and database support. These features are, instead, defined in a profile.

CLDC security is different from traditional Java security. CLDC defines low-level virtual machine security that protects the device from harm and guarantees a certain level of security by the class file verifier. Because the size of the J2SE class file verifier is larger than the entire KVM, CLDC/KVM has its own class file verifier. This class file verifier introduces a two-pass method. To save time and processing cycles, the verification is done on a desktop or server computer where the class files are compiled, rather than on the device. This off-device verification is termed preverification. The device performs some simple operations to confirm that the class file was verified and that it is still valid. The CLDC class file verification does not require code signing.

CLDC security also defines a sandbox model similar to that of other Java editions that creates application security. The sandbox model defined in J2SE is far too large for limited devices. The sandbox security in CLDC does serve similar functions, though. It requires that class files be properly verified and affirmed valid Java applications. Only the predefined set of Java APIs used in CLDC is allowed to execute. In the sandbox model, only the device can download and install applications. Applications are not allowed to download individual classes.

The classes CLDC inherits from J2SE are in three packages: java.lang.*, java.io.*, and java.util.*. They are listed in Table 5.2. All new classes introduced are parts of javax.microedition.io.*.

Standard J2SE networking, I/O, and storage libraries are too large for CLDC devices. Original classes assume that TCP/IP is available and are not easy to extend to support new protocols (for example, Bluetooth). Instead, CLDC introduces a new generic connection framework. It allows for better ease in supporting different types of networking protocols, is more easily extensible, and is upwards compatible with standard Java class libraries. A general connection, for example, would take the form of

Table 5.2. Inherited Classes

Package

Class

java.lang

Boolean, Byte, Character, Class, Integer, Long, Math, Object, Runnable, Runtime, Short, String, StringBuffer, System, Thread, Throwable

java.io

ByteArrayInputStream, ByteArrayOutputStream, DataInput, DataInputStream, DataOutput, DataOutputStream, InputStream, InputStreamReader, OutputStream, OutputStreamWriter, PrintStream, Reader, Writer

java.util

Calendar, Date, Enumeration, Hashtable, Random, Stack, TimeZone, Vector

Connector.open("<protocol>:<path>;<parameters>"); 

A connector used in HTTP would take the form of

Connector.open("http://www.usa.com"); 

A connector used in opening a serial port would take the form of

Connector.open("comm:0;baudrate=9600"); 

CLDC does not define any network protocols, just the framework for their interaction. Profiles define the specific protocols that device categories support.

Connected Device Configuration (CDC)

The CDC defines a set of items that compose a portable Java chunk for consumer electronic and embedded devices. The CDC configuration provides for a virtual machine and a set of core libraries appropriate for use with industry-defined profiles for less limited devices, such as the Foundation Profile. According to the Sun community Web site describing the CDC, target devices are characterized as follows:

         They are powered by a 32-bit processor.

         They have 2MB or more of total memory (including both RAM and flash or ROM) available for the Java platform.

         They require the full functionality of the classic JVM.

         Connectivity to a network is often intermittent (and/or wireless).

         Bandwidth is expected to be limited, 9600bps or less.

         User interfaces are primitive, with variable degrees of usability.

As you can see from this list, the differences in the target devices for CLDC and CDC are that CDC target devices are powered by more powerful processors, have more total memory, and make use of the full-blown JVM. The CDC contains the full JVM, the CVM virtual machine, and the class libraries and APIs necessary to get the system up and running. For an application to be meaningful, this configuration requires the help of a profile. At this time, only one profile, the Foundation Profile, is used in CDC. Because CDC subsumes CLDC, any CLDC-compliant profile can be used in CDC.

The CDC class library contains the following packages from J2SE:

         java.lang

         java.util

         java.net

         java.io

         java.text

         java.security

CDC uses a subset of the J2SE APIs, eliminating nonessential ones to conserve space and performance cycles. CVM combines minimalist features inherent to the KVM with more enhanced features of the JVM, such as a precise memory system, an advanced garbage collector, and better Java synchronization. CVM supports multiple porting and is implemented in C. CVM can run with mostly preloaded classes concurrently with dynamically loaded classes. This allows for quicker start-up time, less latency, and the capability to execute bytecodes out of ROM. CVM provides interfaces between garbage collection, the type system, and the interpreter. These interfaces are clearly defined and well separated.

Now that you have learned about configurations, it is appropriate to introduce two profiles that give these configurations specificity and increased ease of portability.

Profiles

A profile is more application-oriented, whereas a configuration is more device-oriented. As mentioned earlier, a profile is an industry-defined specification of the Java APIs used by manufacturers and developers to address specific types of devices. A profile supplements a configuration to provide capabilities common to a certain device category. Currently, two profiles have completed the Java Suggested Revision (JSR) process that is part of the J2ME-approved specifications. The Mobile Information Device Profile (MIDP) is used with CLDC, and the Foundation Profile is used with CDC.

Mobile Information Device Profile (MIDP)

The CLDC does not define any user interaction parameters in its specifications. This is left to profile definitions. The MIDP is designed to run on Mobile Information Devices (MID). A MID is defined as having the following features: a display that is at least 96 pixels by 64 pixels; a touch screen, keypad, or keyboard; a wireless network connection (either always on or intermittent); 128K of nonvolatile memory for MIDP, 8K of nonvolatile memory for persistent data, and 32K of volatile memory for the Java runtime; and the capability to run the VM and low-level APIs for obtaining user input. The MIDP adds APIs to the CLDC for the following functions:

         Displaying text and graphics

         Responding to user events

         Defining and controlling applications

         Storing data in simple databases

         Network connectivity via a subset of HTTP

         Timer notifications

The MIDP necessarily excludes details for

         Downloading applications

         Installing applications

         Network security

The Foundation Profile

According to its specifications, the Foundation Profile is simply a set of Java APIs tailored to complement the CVM in the CDC. Together, these provide a complete J2ME runtime environment for devices that are limited but have 2MB or more memory and a 32-bit processor. The profile tweaks some of the packages in J2SE to provide necessary support for critical functions on limited devices.

The Future of J2ME

J2ME targets a wide range of uses and devices that differ greatly from one another. Currently, profiles are developed for specific categories of devices. The MIDP targets devices such as cell phones. The intention behind profiles is that J2ME application developers utilize certain profiles so that their applications can port easily across any device that implements the profile. The proposed inclusion of building blocks will define an API derived from J2SE or J2EE APIs for use in J2ME. According to the Java Community Process Java Specification Request for this change, a building block might define a specific set of classes from java.io. The building blocks will then be available for Profile Expert Groups to use in developing new profiles. The more far-sighted intent for building blocks is that they will eventually cause configurations to fall into extinction. At the time of the writing of this text, both configurations discussed here are standard operating procedures for J2ME, as are several profiles, but Sun is in the process of visiting the proposal for building blocks. Several profiles are currently in various stages of approval. There are proposals for a PDA profile, a Personal profile, an RMI profile, and a Java TV profile. Refer to Sun's J2ME Web site for updates on these proposed profiles, at http://www.sun.com/software/communitysource/j2me.

 



Wireless Security and Privacy(c) Best Practices and Design Techniques
Wireless Security and Privacy: Best Practices and Design Techniques
ISBN: 0201760347
EAN: 2147483647
Year: 2002
Pages: 73

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net