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