J2ME vs. .Net Compact Framework

 

The J2ME and .Net Compact Framework cannot be easily compared feature-to-feature because the analysis must include non-technology dimensions such as viability, market acceptance, development and testing tools, reach, standardization and coherence of the platform.

 

Besides, J2ME's Mobile Information Device Profile (MIDP) variant is in production, and the other two leading platforms, PDA Profile and Personal Profile, are in the final stages of standardization. On the other hand, .Net CF is in the final stages of its beta tests.

 

However, it can still be useful to compare the features of the two alternatives.

 

Virtual machine

Languages

Mulitple platforms

The specification process

Use of native features

Consumer applications

Enterprise databases

Web services

Mobile gateways

Fixed gateways

Development tools

Summary of Comparison .NET CF and J2ME (CDC and CLDC)

 

 

Virtual machine

 

.NET Compact Framework

The Common Language Runtime (CLR) environment executes .Net's Microsoft Intermediate Language code. The CLR also offers support services, such as code verification, memory management through garbage collection, and code security. In .Net, managed code always translates into native machine code rather than interpreted. Besides, .Net is able to run multiple applications within a single process. CLR offers support for both interfaces as in Java, as well as, pointers. When C# code is executing in an unsafe context, a lot of runtime checking is disabled. Hence, the program must have full trust in the machine it is running on [1].

 

J2ME

Java source code is compiled into machine-independent byte code, which is then interpreted by  Java Virtual Machine (JVM)  at runtime [1]. Although JVM supports interfaces, it does not support pointers. Java does not support the use of unsafe code in which you can manipulate pointers. However, it is possible to do this in Java by using the Java Native Interface (JNI).

 

 

Languages

 

.NET Compact Framework

.Net is able to support multiple programming languages. Hence, .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. The .Net CF development tool, VS.Net, currently supports only two major .Net languages: C# and VB.Net [3]. C# and VB.Net  are standardized by EMCA and ISO/IEC. Hence, Microsoft has long been criticized for tightly controlling its technologies [1].

 

J2ME

J2ME, on the other hand, only supports one language, which is Java [3]. Java is not standardized. Anyone can propose a JSR for a new platform extension, and the Java Community Process (JCP) keeps Java technology open with input from IBM, HP, BEA Systems, and many other participants. [1].

 

 

Multiple platforms


.NET Compact Framework

.Net CF supports only the Windows CE and Pocket PC platform. However, whether the identical framework will one day be implemented on other operating systems remains an open question [12]. 

Windows devices consist of only a small part of today's mobile device population. In cell phone devices, Motorola iDEN, Nokia Symbian OS, and Qualcomm Brew platforms are common. In low-end PDAs, Palm OS, RTOS (real time OS) platforms such as QNX Software Systems and Wind River's VxWorks are widely used. On high-end PDAs, where Windows has the largest market, devices based on the Symbian OS and different Linux flavors are becoming popular.

 

J2ME

Many of the above-mentioned mobile platforms have built-in Java support because Java allows developers to be productive across many mobile platforms. Hence, game developers prefer J2ME, because it is supported by Symbian proprietary mobile operating systems. However, a few standard J2ME extensions and optional packages support various features unavailable on every device (e.g. Short Message Service and multimedia playback), which could confuse new developers. Hence, more effort must be put into the standardization process for J2ME to keep its cross-platform promise.

 

 

The specification process

.NET Compact Framework

When a new technology emerges, Microsoft has the veto power to make decisions and make them available on .Net CF quickly, with no lengthy debates and duplicated efforts [3].

 

J2ME

The Java Community Process (JCP) decides the new J2ME standard APIs. Sun has veto power only on Java language specifications. After the API specification is developed, each company can develop its own implementation. The JCP develops all current J2ME configurations, profiles, and optional packages. Although this approach has worked well so far, it has been criticized for being slow and inefficient [3].

 

 

Use of native features
กก

.NET Compact Framework

The standard frameworks cover only a limited set of important and frequently used mobile device features. Other features are accessible via native methods. Compared with J2ME, .Net CF has better support for native methods because Microsoft is the only company that controls both .Net CF and the Windows OS [3].

 

J2ME

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 [3].

 

 

Consumer applications

 

.NET Compact Framework

.Net CF supports direct draw on canvas, double buffering, and device button remapping through its rich Windows Forms User Interface library. Besides, by using the native APIs from Windows Media Player on Pocket PC, .Net CF applications can support multimedia playback [3].

 

J2ME

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 could enable 3D games on CDC devices, but it has been inactive for a long time [3].

 

 

Enterprise databases
กก

.NET Compact Framework

.Net CF supports a substantial subset of ADO.Net (Active Data Objects).

 

J2ME

The standard relational database access API on the Java platform is Java DataBase Connectivity (JDBC) [3].

 

 

Web services

 

.NET Compact Framework

Microsoft has a head start on Web services integration with mobile devices with the support from VS.Net.  

 

J2ME

SOAP client support is currently not standardized. Third-party such as the open source kSOAP is required [3].

 

 

Mobile gateways

.NET Compact Framework

Since .Net CF is brand-new, few gateway products are specifically designed for it. In addition, .Net CF presents some technical difficulties because it was not designed to run lightweight application servers required in mobile gateways [3].

 

J2ME

On the more mature J2ME, the primary mobile service gateway product is from IBM [3].

 

 

Fixed gateways


.NET Compact Framework

Microsoft Mobile Information Server (MIS) is a powerful gateway, messaging, and synchronization server. However, .Net CF lacks built-in APIs to interact with Microsoft MIS  [3].

 

J2ME

The Oracle9i wireless application server, together with Oracle J2ME SDKs, provides gateway integration points for mobile devices to many other Oracle or third-party application servers [3].

 

 

Development tools

 

.NET Compact Framework

Microsoft's Visual Studio .Net is an excellent product that provides similar design interfaces for mobile applications. It features strong support for Web services integration and relational database access. Besides, VS.Net is tightly integrated with Visio Enterprise Network Tools edition, which can generate C# or VB.Net code from 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.

 

J2ME

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. However, IDEs are still important. All major Java IDEs now have J2ME modules or plug-ins. 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.

 

 

 

 Summary on Comparison between .NET CF and J2ME (CDC and CLDC)

 

 

.Net Compact Framework

J2ME Connected Device Configuration

J2ME Connected Limited Device Configuration

Virtual machine

Java Virtual Machine (JVM)

Common Language Runtime (CLR)

Portable code

Intermediate Language (IL)

Machine-independent byte code

Just-In-Time (JIT) Compiling

Yes

Yes

Garbage Collection

Yes

Yes

Security

Good

Good

Portability

No

Yes

Cross-language integration

Yes

No

Standardized (EMCA, ISO/IEC)

Yes

No

Device requirement

Powerful

Powerful

Pervasive

Cost

High

High

Medium

Market focus

Enterprise

Enterprise

Consumer and enterprise

Language support

C#, VB.Net

Java

Java

Platforms

Pocket PC, Windows CE

Major mobile platforms except Palm OS

All mobile platforms

Byte code compatibility

Standard .Net CLR

Standard Java 2

Not compatible with J2SE or CDC

API compatibility

Subset of .Net

Subset of J2SE plus standard optional packages

Partial compatibility with CDC with additional standard optional packages

Native APIs

P/Invoke; consistent across supported devices

JNI; device- and OS-specific

N/A

Development tools

VS.Net 2003

Command line, vendor SDKs, CodeWarrior, and WebSphere

Command line, vendor SDKs, all major Java IDEs

Specification process

Single company

Community

Community

Service gateway

N/A

Run gateways as OSGi servlets; run gateway clients via vendor-specific SDKs

Run gateway clients via vendor-specific SDKs

Security model

Simplified .Net model

Full Java security manager

Limited Java 2 model supplemented by OTA specification

Client installation

ActiveSync, Internet Explorer download

Sync, download

Formal OTA specification

Life cycle management

N/A

OSGi for gateway apps, J2EE Client Provisioning Specification for generic clients

Included in OTA spec, works with J2EE Client Provisioning Specification

User interface

Rich subset of Windows Forms

Rich subset of AWT (Abstract Windowing Toolkit), vendor-specific UI libraries

MIDP liquid crystal display UI, PDA Profile subset of AWT, vendor-specific UI libraries

Database API

Subset of ADO.Net, DataGrid

Rich subset of JDBC

Vendor-specific JDBC-like APIs

Mobile database

SQL Server CE, Sybase iAnywhere Solutions(coming soon)

IBM DB2 Everyplace, iAnywhere Solutions, PointBase, Oracle9i Lite

Vendor-specific relational implementation over RMS, Oracle SODA

Remote database

Any ADO.Net compatible

Any JDBC compatible

Vendor-specific JDBC-like API bridge

Database synchronization

Vendor specific

Vendor specific

Vendor specific

XML API

Build into ADO.Net and other standard APIs

Third party tools

Third party tools

 

Web services tools

Integrated with VS.Net

kSOAP plug-ins for leading IDEs

kSOAP plug-ins for leading IDEs

Direct RPC

Not recommended

Rich subset of Remote Method Invocation

N/A

Email and PIM (personal information manager)

P/Invoke Outlook APIs

JavaPhone and third-party APIs

Upcoming PDA Profile and third party

SMS

P/Invoke device SMS stack

Wireless Messaging API

Wireless Messaging API

Instant messenger

P/Invoke MSN (Microsoft Network) and other IM client APIs

Third-party APIs for most IM clients including Jabber and Jxta

Third-party APIs for most IM clients including Jabber and Jxta

Enterprise messaging

P/Invoke MSMQ

Proprietary Java Message Service APIs

Java Message Service via third-party toolkits (e.g., WebSphere MQ Everyplace, iBus Mobile)

Cryptography

Third-party APIs

Java Cryptography Extension and third-party libraries

Third-party libraries

Multimedia

P/Invoke Windows Media Player APIs

Subset of JMF

Built into MIDP plus J2ME multimedia APIs

Game

Included Windows Forms UI

Direct draw on Canvas

GameCanvas support in MIDP

Location API

APIs provided by carriers

Third party

Third party

 

 

My book Back to Mobile Programming main page

Thanks to Khoo Wei Ju for initial version of the page and compilation of resources

Click here to return to Daniel Wong's home page

click here to return to Daniel Wong's wireless resources page

Click here for info on the book Wireless Internet Telecommunications

Last modified 24-Jun-2005 01:28 PM