Let the mobile games begin, Part 1

A comparison of the philosophies, approaches, and features of J2ME and the upcoming .Net CF

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):

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 Compact Framework J2ME Connected Device Configuration J2ME Connected Limited Device Configuration
Device requirementPowerful, expensivePowerful, expensiveCheap, pervasive
CostHighHighMedium
Market focusEnterpriseEnterpriseConsumer and enterprise
Language supportC#, VB.NetJavaJava
PlatformsPocket PC, Windows CEMajor mobile platforms except Palm OSAll mobile platforms
Byte code compatibilityStandard .Net CLRStandard Java 2Not compatible with J2SE or CDC
API compatibilitySubset of .NetSubset of J2SE plus standard optional packagesPartial compatibility with CDC with additional standard optional packages
Native APIsP/Invoke; consistent across supported devicesJNI; device- and OS-specificN/A
Development toolsVS.Net 2003Command line, vendor SDKs, CodeWarrior, and WebSphereCommand line, vendor SDKs, all major Java IDEs
Specification processSingle companyCommunityCommunity
Service gatewayN/ARun gateways as OSGi servlets; run gateway clients via vendor-specific SDKsRun gateway clients via vendor-specific SDKs
Security modelSimplified .Net modelFull Java security managerLimited Java 2 model supplemented by OTA specification
Client installationActiveSync, Internet Explorer downloadSync, downloadFormal OTA specification
Life cycle managementN/AOSGi for gateway apps, J2EE Client Provisioning Specification for generic clientsIncluded in OTA spec, works with J2EE Client Provisioning Specification

Multiple 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.

Multiple languages?

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.

Consumer 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

 .Net Compact Framework J2ME Connected Device Configuration J2ME Connected Limited Device Configuration
User interfaceRich subset of Windows FormsRich subset of AWT (Abstract Windowing Toolkit), vendor-specific UI librariesMIDP liquid crystal display UI, PDA Profile subset of AWT, vendor-specific UI libraries
Database APISubset of ADO.Net, DataGridRich subset of JDBCVendor-specific JDBC-like APIs
Mobile databaseSQL Server CE, Sybase iAnywhere Solutions(coming soon)IBM DB2 Everyplace, iAnywhere Solutions, PointBase, Oracle9i LiteVendor-specific relational implementation over RMS, Oracle SODA
Remote databaseAny ADO.Net compatibleAny JDBC compatibleVendor-specific JDBC-like API bridge
Database synchronizationVendor specificVendor specificVendor specific
XML APIBuild into ADO.Net and other standard APIsThird-party tools (standards coming soon)Third-party tools (standards coming soon)
Web servicesBuilt-inThird party (standards coming soon)Third party (standards coming soon)
Web services toolsIntegrated with VS.NetkSOAP plug-ins for leading IDEskSOAP plug-ins for leading IDEs
Direct RPCNot recommendedRich subset of RMI (remote method invocation)N/A
Email and PIM (personal information manager)P/Invoke Outlook APIsJavaPhone and third-party APIsUpcoming PDA Profile and third party
SMSP/Invoke device SMS stackWireless Messaging APIWireless Messaging API
Instant messengerP/Invoke MSN (Microsoft Network) and other IM client APIsThird-party APIs for most IM clients including Jabber and JxtaThird-party APIs for most IM clients including Jabber and Jxta
Enterprise messagingP/Invoke MSMQProprietary JMS (Java Message Service) APIsJMS via third-party toolkits (e.g., WebSphere MQ Everyplace, iBus Mobile)
CryptographyThird-party APIsJCE (Java Cryptography Extension) and third-party librariesThird-party libraries
MultimediaP/Invoke Windows Media Player APIsSubset of JMFBuilt into MIDP plus J2ME multimedia APIs
GameIncluded Windows Forms UIDirect draw on Canvas GameCanvas support in MIDP
Location APIAPIs provided by carriersThird party (standards coming soon)Third party (standards coming soon)

Enterprise databases

To fully leverage smart clients' offline capabilities, an on-device mobile database is crucial. .Net CF supports a substantial subset of ADO.Net (Active Data Objects). The standard relational database access API on the Java platform is Java DataBase Connectivity (JDBC). The J2ME JDBC optional package supports most JDBC 3.0 APIs on the CDC platform. PersonalJava supports the JDBC 2.x API. On the CLDC platform, several vendors have devised proprietary database implementations over the record management system (RMS). Those implementations support limited JDBC-like methods.

Isolated mobile databases by themselves are hardly useful. They must be synchronized and consolidated with enterprise backend databases. Currently, no standard API for database synchronization exists in either .Net CF or J2ME. Each vendor's mobile database can synchronize only through its own synchronization engine. Mobile database vendors differentiate themselves by offering special optimization and additional features. In this section, you look at solutions provided by several leading mobile database vendors:

  • Microsoft SQL Server CE: The SQL Server CE provides full ADO.Net support for the .Net CF platform. Since the SQL Server CE is bundled with VS.Net, it is pervasive on .Net CF. However, SQL Server CE has a rather large (1.5 MB) memory footprint. Also, SQL Server CE only synchronizes with SQL enterprise databases, requiring the backend environment to be Microsoft only too.
  • Sybase iAnywhere Solutions: iAnywhere's SQL Anywhere Studio is currently the most popular mobile database. According to a 2002 Gartner survey, its market share is 78 percent. A core innovation of SQL Anywhere Studio is to automatically generate custom-built UltraLite databases that only contain the exact functionality your application requires. That drastically slashes the memory footprint without compromising features. SQL Anywhere Studio can currently generate UltraLite databases for CDC and PersonalJava. UltraLite support for .Net CF will surface in early 2003. Auto-generated UltraLite databases contain APIs to synchronize with Sybase and third-party enterprise databases through iAnywhere Solutions' MobiLink synchronization engine.
  • PointBase Micro: PointBase provides pure Java embedded databases that run on both the CDC and CLDC/MIDP platforms. SQL support on MIDP is impressive. PointBase UniSync synchronization engine synchronizes with any JDBC backend database with special optimization for Oracle and PointBase Embedded databases.
  • IBM DB2 Everyplace: DB2 Everyplace is a stripped-down version of DB2 Enterprise database. It supports JDBC and ODBC (Open Database Connectivity) APIs. DB2 Everyplace also contains a product called FastRecordStore, which provides a relational layer over the MIDP RMS. Through the IBM Sync, DB2 Everyplace databases synchronize with most popular backend databases.
  • Oracle9i Lite: Oracle9i Lite databases have footprints of 50 KB to 1 MB depending on their edition. Oracle9i Lite supports the JDBC and ODBC APIs. On MIDP, Oracle provides a mobile database implementation over RMS. Oracle's MIDP database is completely object oriented using the SODA (Simple Object Database Access) technology. For remote data access from MIDP, the Oracle J2ME SDK has a package that enables simple SQL access to backend databases through the Oracle9i wireless application server. Oracle9i Lite databases only synchronize with Oracle enterprise back ends.

Web services

XML Web services is the key to future enterprise integration. SOAP (Simple Object Access Protocol) is becoming the ubiquitous protocol for accessing componentized enterprise back ends. Being an early adopter and promoter of SOAP Web services, Microsoft has a head start on Web services integration with mobile devices. With the support from VS.Net, consuming Web services in .Net CF applications is easy. In many cases, developers do not need to write any code and can just treat the remote service as a local object.

On J2ME, SOAP client support is currently not standardized. We must rely on third-party J2ME SOAP libraries, such as the open source kSOAP, to build mobile SOAP clients. Popular J2ME IDEs such as Sun ONE Studio, CodeWarrior Wireless Studio, and WebSphere Studio Device Developer have recently added SOAP client stub generators for kSOAP. Oracle supports J2ME Web services clients through its upcoming 9i wireless application server. The server communicates with J2ME clients using a proprietary RPC (remote procedure call) protocol and relays SOAP messages. In the future, the J2ME Web Services Specification (JSR 172, available in third quarter 2003) will likely standardize J2ME Web services client APIs.

Support for the service gateway paradigm

Service gateway is not a part of either .Net CF or J2ME. But it is an important component in today's smart home or enterprise networks. In this section, I first give an overview of the service gateway architecture and then discuss options available from third-party vendors.

A service gateway integrates with backend servers, stores application data, and facilitates messaging on behalf of its thin or lightweight smart mobile clients. The service gateway architecture allows us to use small and pervasive devices while still leveraging rich functionalities. Asynchronous and cache-enabled messaging middleware in the gateway prove essential to ensuring mobile applications' quality of service. The gateway architecture also allows more efficient application designs. For example, the Model-View-Controller (MVC) design pattern can be easily applied.

Mobile gateways

Mobile gateways implemented on mobile platforms are very attractive. For example, a mobile gateway could be a set-top box for a home network, an auto-mounted device for a car network, or a Bluetooth PDA for a personal network.

Since .Net CF is brand-new, few gateway products are specifically designed for it. In addition, .Net CF presents some technical difficulties. .Net CF was not designed to run lightweight application servers required in mobile gateways. It does not directly support MSMQ (Microsoft Message Queuing) either.

On the more mature J2ME, the primary mobile service gateway product is from IBM: the WebSphere Everyplace Embedded Software Suite that runs on IBM's J2ME runtime known as the WebSphere Micro Environment (formally known as J9). WebSphere Everyplace Embedded Software Suite contains the IBM Service Management Framework (SMF), which is a lightweight server framework that runs on top of the CDC and the Foundation Profile. SMF is an implementation of the OSGi (Open Service Gateway Initiative) specification. OSGi defines a Java framework that runs managed service modules (bundles). One type of service OSGi provides is an HTTP service based on J2EE servlets. The SMF bundles interact with middleware components like IBM DB2 Everyplace and WebSphere MQ Everyplace.

Fixed gateways

Of course, service gateways can reside on fixed server computers too. In this scenario, the gateway computer runs a full-blown server framework such as ASP.Net (Active Server Pages) or J2EE. This architecture is suitable for heavy-duty gateways serving devices in a limited range (e.g., a factory floor or an office). .Net CF or J2ME devices are gateway clients in this scenario.

In the Microsoft camp, the Microsoft Mobile Information Server (MIS) is a powerful gateway, messaging, and synchronization server for Pocket PC as well as thin client devices. However, .Net CF lacks built-in APIs to interact with Microsoft MIS. I expect third-party vendors will provide such support soon after .Net CF 1.0 is released

In the Java world, Oracle has a complete line of gateway application server products running on top of J2EE. Together with Oracle J2ME SDKs, the upcoming Oracle9i wireless application server provides gateway integration points for mobile devices to many other Oracle or third-party application servers.

Client provisioning and life cycle management

Device management is one of the most costly parts of today's mobile enterprise solutions. Ensuring that the right users get the right software and that the software is updated promptly is important. For general public mobile applications, wireless network carriers must build walled gardens to protect customers as well as revenue sources.

On .Net CF, applications are installed over ActiveSync or over the air (OTA) through the Pocket PC Internet Explorer. There is no standard way for the back end to control the client once the client deploys.

On J2ME, an application can be managed from the back end throughout its life cycle. For MIDP applications, a well-defined OTA provisioning specification mandates how a MIDlet suite is installed and updated. For mobile service gateway applications, the OSGi framework handles bundle life cycle management. On the server side, the J2EE Client Provisioning Specification defines a complete server framework that matches and deploys smart clients to a variety of devices. The J2EE client provisioning server integrates with customer relationship management modules to enable custom tracking, billing, and upgrading logics.

Developer is king

One of the most compelling reasons for choosing .Net CF or J2ME is to leverage existing developer skills. The list below summarizes available mobile application platforms and developer groups most likely to adopt them:

  • .Net CF: .Net desktop application developers; VB developers.
  • J2ME/CDC: J2SE client application developers; Java Web applet developers; J2EE server application developers for OSGi gateways.
  • J2ME/CLDC: All J2SE developers. To become familiar with javax.microedition APIs, especially the UI features, some learning is required.

.Net CF development tools

Microsoft's flagship IDE Visual Studio .Net is an excellent product that provides similar design interfaces for desktop and mobile applications. For example, to migrate a desktop UI design to .Net CF, you merely copy and paste visual components to a new designer window. VS.Net also features strong support for Web services integration and relational database access. I found that most auto-generated code snippets are easy to read and modify by hand. VS.Net is tightly integrated with Visio Enterprise Network Tools edition, which can generate C# or VB.Net code from your UML (Unified Modeling Language) diagrams. VS.Net supports debugging on both high-fidelity emulators and real devices. However, VS.Net is not cheap. As of today, no free command-line tool exists for .Net CF development. Nor does any third-party IDE product support .Net CF. More tools will be available in the future when .Net CF matures.

J2ME development tools

On the J2ME front, command-line tools and vendor-specific toolkits are readily available. Sun's J2ME Wireless ToolKit is a widely used MIDP development tool. Antenna is an open source project that extends Java's de facto Ant build tool to J2ME. But of course, for most developers, IDEs are still essential. All major Java IDEs now have J2ME modules or plug-ins:

  • Sun ONE Studio Community Edition with wireless modules is free and has excellent support for enterprise features.
  • JBuilder with MobileSet has a great visual UI designer and good UML design support.
  • CodeWarrior Wireless Studio is bundled with many useful third-party tools. It supports development on both CLDC and CDC/PersonalJava.
  • IBM WebSphere Studio Device Developer is based on the popular Eclipse IDE platform. It supports both on-device and emulator debugging. If you choose one of IBM's smart mobile middleware solutions, WebSphere Studio Device Developer is naturally the best tool.
  • Oracle9i JDeveloper IDE helps integration between Oracle mobile servers and J2ME clients.
  • Data Representation's Simplicity IDE has visual designers not only for UI components, but also for end-to-end communication logic components, such as an XML-based transaction engine. Simplicity supports integration with legacy (mainframe) information servers through a visual screen reader.

A big challenge for all J2ME IDEs is vendor SDK integration. Every device vendor provides SDKs for their device emulators and proprietary J2ME extensions. The Unified Emulator Interface (UEI) is designed to standardize the interfaces between IDEs and device SDKs. But the UEI is available only through a Sun licensing program. An open standard is needed.

Conclusions

.Net CF and J2ME are both excellent platforms for developing smart clients for mobile commerce applications. The .Net CF platform focuses on enterprise applications with rich UI, database, and XML Web services support. VS.Net is an excellent tool for .Net CF development. But .Net CF runs only on Windows-powered high-end PDAs. As a young platform, it currently lacks support for gateway servers and choices for mobile databases. Application life cycle management is also weak.

J2ME sports a modular design and is portable across a variety of devices. The platform provides balanced support for both enterprise and consumer applications. Most important, J2ME APIs undergo rigorous standardization processes to ensure wide industry support and minimum learning for developers. J2ME vendors offer excellent selections of mobile databases and gateway application server products. However, keeping the J2ME platforms simple and avoiding fragmentation proves challenging. J2ME Web services tools still need improvements and standardization.

In Part 2 of this series, I will use some sample applications to demonstrate the differences between the two platforms.

Many individuals and companies have contributed helpful comments and provided testing software/hardware during the development of this article. In particular, I would like to thank Ed Kaim and Melissa Hovis from Microsoft; Angus McIntyre, Bryan Stevenson, Norbert Runge, and Lisette Kwong from IBM; Dick Heermance from Insignia; Steve Jones and Gina Milani from PointBase; Marty Mallick and Mark Dowd from Sybase iAnywhere Solutions; and Jacob Christfort and Kiersten Hollars from Oracle.

Michael Yuan is a PhD candidate at the University of Texas, where he is a research associate at the Center for Research in Electronic Commerce and an open source Java developer.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more