For more than five years, Java 2 Platform, Micro Edition (J2ME) and its predecessors, such as PersonalJava, have served as the only viable platforms for developing managed smart clients on mobile or embedded devices. But that will soon change. With the introduction of Visual Studio .Net (VS.Net) 2003 in the first half of 2003, Microsoft will make its managed environment, .Net, available on Windows-powered mobile devices with its new product, the .Net Compact Framework (.Net CF).
History has proven that Microsoft can effectively leverage its positions in existing markets to push its agendas in emerging markets. Given Windows' dominance in the desktop market and .Net's presence in the enterprise market, every mobile Java developer must be prepared for the coming challenge. As Java developers, we must learn the latest Java tools. Equally important, we must learn what is happening in the .Net camp. We cannot just pretend that .Net does not exist or believe that we are too smart to learn from "them."
In this two-part series, I analyze the new challenges posed by .Net CF and how J2ME stands up to the competition. In Part 1, I present a high-level comparison and discuss the directions the two platforms will head in the future. Concrete code examples and case studies will follow in Part 2.
Read the whole series: "Let the Mobile Games Begin," Michael Juntao Yuan (JavaWorld):
- Part 1: A comparison of the philosophies, approaches, and features of J2ME and the upcoming .Net Compact Framework
- Part 2: J2ME and .Net Compact Framework in action
J2ME vs. .Net CF
J2ME and .Net CF are platforms for managed smart mobile clients. They are critical new technologies for advanced mobile commerce. Compared with micro-browser technologies such as WAP (Wireless Application Protocol), smart clients support rich user interfaces (UIs), leverage device extensions (e.g., GPS (global positioning system) and bar-code scanners), and support more flexible integration and security schemes. Smart clients also reduce network traffic and improve transactional stability through on-device data storage. Compared with smart clients on native platforms (such as eMbedded Visual C++ or C++ SDKs for the Symbian OS), Java- or .Net-managed environments greatly improve developer productivity, application reliability, and mobile code security.
Designed for mobile computing, .Net CF is a lightweight version of Microsoft's .Net Framework. The .Net CF Common Language Runtime (CLR) runs standard .Net byte code applications. .Net CF contains a subset of standard .Net API libraries necessary for mobile application development. It runs only on Windows CE/Pocket PC-powered high-end PDAs.
In the Java camp, the situation is more complex. J2ME contains standardized configurations and profiles designed to provide the best compromise between portability and performance for a range of mobile devices. Configurations support the Java core APIs. Profiles are built on top of configurations to support device-specific features such as networking and UIs. Each valid combination of configuration and profile targets a specific type of device:
- Profiles on top of the Connected Device Configuration (CDC) target high-end networked devices. Those devices have similar hardware capabilities as .Net CF devices. The CDC includes a standard Java 2 Virtual Machine so it can run standard Java byte code and utilize Java 2 Platform, Standard Edition (J2SE) libraries if desired. The CDC Personal Profile has roughly the same functionality as the older PersonalJava environment.
- Profiles on top of the Connected Limited Device Configuration (CLDC) target low-end PDAs and small cell phones. The CLDC uses a small footprint VM that is not compatible with J2SE or the CDC.
In this article, I compare the philosophy, market position, industry support, and feature support of the .Net CF, J2ME/CDC, and J2ME/CLDC platforms. The table below summarizes the differences among those three platforms.
Table 1. Overview of the three platforms
.Net CF supports only one OS platform—Windows. One could argue that .Net CF is cross platform to some degree because of the CLR. Windows CE and Pocket PC operating systems run on more than 200 different devices. .Net CF applications are directly portable across those devices only.
However, Windows devices consist of only a small part of today's mobile device population. On cell phone devices, Motorola iDEN, Nokia Symbian OS, and Qualcomm Brew platforms are prevalent, and there are many vendor-specific OS platforms (e.g., Nokia Series 40). On low-end PDAs, Palm OS is the dominant player; on embedded or telematics devices, RTOS (real time OS) platforms such as QNX Software Systems and Wind River's VxWorks are the most widely used. Even on high-end PDAs, where Windows has the largest market share, devices based on the Symbian OS and different Linux flavors are growing more and more popular. More than 200 Linux PDAs are already available, and IBM has just recently announced a blueprint for high-end PDAs based on the PowerPC chip and Linux OS.
For many mobile developers, having their applications run on multiple platforms with minimum effort proves absolutely essential. This is where Java really shines. Many of the above-mentioned mobile platforms now have built-in Java support. Third-party J2ME runtimes from Insignia and IBM are available for all mobile platforms, including all Windows flavors. The Java approach allows developers to be productive across many mobile platforms.
However, Write Once, Run Anywhere is easier said than done. Given the variety of mobile devices, the lowest common denominator approach does not work. Quite a few standard J2ME extensions and optional packages support various features unavailable on every device (e.g., SMS (Short Message Service) and multimedia playback), which could confuse new developers. Device vendors also tend to add value to their solutions by providing proprietary J2ME extension packages. Even for well-defined standard J2ME platforms, such as MIDP (Mobile Information Device Profile), different vendors have slightly different implementations. Thus, for J2ME to keep its cross-platform promise, we must put more effort into the standardization process. I discuss that process in a later section.
A much-touted benefit of .Net is its ability to support multiple programming languages. That ensures that .Net CF can reach a variety of developers and reuse existing libraries. However, due to the object-oriented nature of the .Net CLR, developers must be familiar with object-oriented programming concepts before they can write effective .Net code. A good example is the Visual Basic .Net (VB.Net) language. A Visual Basic 6.0 developer will encounter some major learning curves before he can use VB.Net. It is yet to be seen whether Microsoft can successfully migrate those developers to .Net. The .Net CF development tool, VS.Net, currently supports only two major .Net languages: C# and VB.Net.
The specification process
.Net CF provides a homogeneous set of tools and APIs for development on all Microsoft-supported devices. When a new technology emerges, Microsoft can make it available on .Net CF quickly, with no lengthy debates and duplicated efforts. However, Microsoft, not the customers, decides the "important" features to put into .Net CF. This strategy's success depends on Microsoft's ability and willingness to listen to customer feedback.
|Note: It's different this time|
|Unlike most Microsoft developer products, the .Net CF specification has undergone a different type of beta process. Developers can actually influence what APIs Microsoft puts into the platform. An example is the DataGrid API, which maps relational data to Excel-type grids. It was omitted in the original beta specification, but was added upon the requests of enterprise customers. Though not a democratic process, this process is a step in the right direction for Microsoft.|
Since J2ME is designed to be cross-platform, the J2ME specification and implementation are two separate processes. Through the Java Community Process (JCP), a committee of mobile solution providers decides the new J2ME standard APIs. Sun has veto power on only Java language specifications. After the API specification is developed, each company can develop its own implementation. That ensures portability and minimizes developers' learning costs while preserving vendors' incentives to differentiate and innovate. Since all API specifications are reached by industry consensus, most likely they will be supported in the future. The JCP develops all current J2ME configurations, profiles, and optional packages. This democratic process has worked great so far; however, it has been criticized for being slow and inefficient (see Frank Sommers's and Sonali Shah's JavaWorld series on the JCP, "Effort on the Edge").
Use of native features
The standard frameworks cover only a limited set of important and frequently used mobile device features. Additional device-specific features are accessible via native methods. Compared with J2ME, .Net CF has better support for native methods because Microsoft is the sole company that controls both .Net CF and the Windows OS. We can assume that certainly native APIs exposed by standard applications, such as Internet Explorer, Windows Media Player, Pocket Outlook, and Pocket Word, will always be available to .Net CF developers. .Net CF programs invoke methods in specifically formatted Win32 native libraries (P/Invoke).
J2ME/CDC applications can access native methods through the JNI (Java Native Interface) framework. The CLDC does not support JNI. For security reasons, CLDC applications are not allowed to access native methods. For CLDC, device vendors must build any native features into the runtime.
Of course, for both platforms, you should minimize the use of native methods. Native methods prove cumbersome to write and maintain because they are mostly low-level C function calls. Making native methods work is difficult with reusable libraries written in Java and C#. In addition, native methods cannot leverage the robustness and fine-grained security of managed environments. In the case of J2ME, using device-specific native methods results in nonportable applications.
During the past several years, mobile developers have focused on consumer wireless applications. Mobile games available on the NTT DoCoMo networks and new camera phones with multimedia messaging service capabilities are hot topics.
Although .Net CF is not specifically marketed toward the consumer market, it supports direct draw on canvas, double buffering, and device button remapping through its rich Windows Forms UI library. Using the native APIs from Windows Media Player on Pocket PC, .Net CF applications can support multimedia playback.
The J2ME platforms have strong support for consumer applications. MIDP 2.0 includes animation and game controls in the
javax.microedition.lcdui.game package. Multimedia playback is supported via the Java Media Framework (JMF) on the CDC or the multimedia optional package for the CLDC/MIDP. The Java Game Profile (Java Specification Request (JSR) 134) could enable 3D games on CDC devices, but it has been inactive for a long time.
Due to the lack of direct hardware access, neither .Net CF nor J2ME proves suitable for high-performance video game applications. Both platforms' futures lie in enterprise mobile applications. Microsoft's "depth-but-not-breath" approach allows it to pack many enterprise-oriented features in .Net CF. In the J2ME camp, support for enterprise applications is also going strong with the backings of enterprise IT giants such as IBM and Oracle. In the next several sections, I will focus on features essential to enterprise mobile applications. Table 2 summarizes features supported on each platform.
Table 2. The feature matrix