As more applications are built for wireless devices, competing technologies start to bump heads. This article explores the similarities and key differences between Sun's Java Micro Edition and Qualcomm's Binary Runtime Environment for Wireless.
Wireless Internet is more than just “wireless access to the Internet.” It's about different types of small mobile devices and the ability to provide anytime, anywhere access to information in an easy and effective way. So far, WAP has been more or less the only standard providing basic access to Web-based services using a microbrowser on the mobile device. However, next-generation wireless devices, such as smart phones, raise application functionality expectations. Two vendors, Sun and Qualcomm, are attempting to meet this challenge by offering a new model for online access to wireless applications.
Sun Microsystems’s Java 2 Micro Edition (J2ME) and Qualcomm’s Binary Runtime Environment for Wireless (BREW) are two emerging technologies that provide a new model for online access by allowing applications to be downloaded from the Web. The apps can then take care of fetching more data from the Web or be executed offline.
These technologies provide the developer community with enormous opportunity for building and distributing feature-rich mobile and wireless applications. The key benefits of J2ME and BREW include an enhanced user interface, improved application usability on small screens, and the ability to download and store new applications that can be run offline, thereby eliminating the need for constant network connection. Let's look at the similarities and differences of these competing technologies.
J2ME: “Special Edition Java”
J2ME is Java technology specially customized for small consumer and embedded devices with limited processor, memory, display, and input capabilities. J2ME architecture is based on families and categories of devices and has the following structure.
Java Virtual Machine (JVM) runs on top of the device’s operating system and is customized for a specific operating system. The size and complexity of JVM depends on the particular J2ME configuration it supports.
The configuration layer should be of interest to you if you are involved in developing J2ME profiles. This layer specifies the minimum set of features and Java class libraries that the JVM should support, thereby specifying the Java functionality available for a particular category of devices.
J2ME defines two configurations. Connected Limited Device Configuration (CLDC) is meant for devices with limited power, memory, and network connectivity capabilities. JVM corresponding to this configuration is the highly optimized K Virtual Machine. (KVM can run in around 130 KB of memory.) Connected Device Configuration (CDC) is for more advanced devices with 32-bit processors and with more than 2 MB of memory. The corresponding VM is the full-featured Java C Virtual Machine (CVM).
The profile layer may be the most relevant to application developers. It defines a set of APIs for a particular category of devices. An application written for a particular profile can run on any other device that supports that profile. Mobile Information Device Profile (MIDP) is relevant to mobile wireless devices like mobile phones and PDAs. It includes a set of APIs related to user interface, storage, and networking (HTTP) capabilities. Also of interest is the J2ME Bluetooth profile, which provides standardized APIs for including Bluetooth capability.
The alternative: BREW
BREW is an application execution platform that runs at the firmware level (CDMA chipset) and specially targets wireless applications that can be downloaded and executed on mobile devices. BREW runtime environment is available free of cost to CDMA device manufacturers. This runtime environment is much like the VM in Java, except that BREW runtime environment is not designed to provide portability from one device to another. BREW is currently available only to CDMA-based wireless devices sporting Qualcomm processors. The platform boasts enhanced capabilities that include GPS, VOIP, Bluetooth 1.1, MP3, and MIDI. The fact that BREW runtime platform runs at chipset level enables it to leverage the communication and multimedia capabilities of mobile devices more than J2ME.
The BREW suite of services includes TCP/UDP socket communications, HTTP support, SMS messaging, advanced telephony services, and support for file system access. BREW provides C/C++ software development, and the BREW C/C++ SDK easily integrates with Microsoft’s Visual C++ development environment. As part of the BREW application platform, Qualcomm offers a BREW porting kit, a BREW SDK that provides development tools, documentation, APIs, etc., and a BREW distribution system, which we'll look at next.
The BREW distribution system
Qualcomm's BREW distribution system (BDS) allows carriers to manage download of BREW applications by the devices running in their network. The solution manages all the distribution and billing issues, and developers receive their share of revenue for the applications downloaded by users. Each application available for download has to be certified by Qualcomm before it is deployed. Certification achieves two objectives: It adds an extra layer of security for the end user, and it ensures that the developers are known, in case an application needs to be recalled over the network.
You can now run J2ME applications on BREW, thanks to the implementation of the J2ME virtual machine over BREW. With BREW conceptually acting as a layer below the JVM, it is possible to develop Java applications that can be downloaded and executed on BREW-enabled devices using the BDS. As mentioned above, BDS 2002 allows for downloading Java midlets and even a JVM—which, in this case, is just another BREW application. Although no concrete evaluation about performance of J2ME running on top of BREW is available, there will certainly be extra processing requirements because of another layer (BREW) in the execution of J2ME applications. Sources from Qualcomm maintain that this should not be a problem, though, as its new line of chips will have enough processing power.
Which way should the developer go?
All in all, BREW doesn’t sound much different from Java. To a user, it presents a similar kind of application experience and to a developer, a more or less similar development model. However, some distinctions need to be made between the two:
- The J2ME philosophy is essentially the Java philosophy, which is to enable developers to write applications that can run unaltered on different devices. J2ME therefore targets general consumer and embedded devices. BREW, on the other hand, targets wireless devices exclusively (specifically CDMA phones). As a result, it's more versatile when it comes to wireless phones—and by the same token, lacks portability.
- J2ME doesn’t consist of a specific distribution system corresponding to the BREW BDS. This may be an advantage as well as a shortcoming. Although it enables free distribution of Java applications, some developers may find the managed revenue distribution system that BREW provides more attractive.
- BREW currently lacks the extent of development tools that Java developers have access to.
- Since J2ME is an interpreted language, it should be slower (at least theoretically) than BREW, which is closer to the processor.
- Java garbage collection can be very effective when it comes to memory issues. These issues can sometime be a serious problem with BREW, with its severe memory limitations.
Which way to go
Both J2ME and BREW present developers with exciting opportunities for taking advantage of the convergence of wireless and the Internet. While Java developers may find that J2ME is the right choice for a range of small consumer devices, BREW has its own advantages when targeting wireless phones. In many cases, of course, the choice of one technology over the other will be dictated by the platform that the network operator decides to support.
J2ME or Brew
Do you prefer J2ME or BREW? Post a comment below or tell us about it.