Development Tools and Integrated Development Environments (IDEs)
Java ME SDKs and basic tools are free from Sun. However, given the multiple Java ME environments and APIs, there are multiple SDKs and toolkits. Plenty of open source and commercial IDEs exist for creating Java ME applications. Eclipse and Sun's NetBeans are the two most popular open source IDEs. Commercial products like Rational Application Developer from IBM are also available and popular. As indicated earlier, device vendors like Motorola also offer their own SDKs. If anything, the Java ME environment suffers from having too many development choices rather than too few. The complexity of Java ME's architecture allows for its adaptation to a great number of platforms, but also can make finding or assembling a proper development environment more of a challenge.
In this area, .NET Compact Framework development shines. While it is possible to write applications without it, few developers would write applications for the .NET Compact Framework (or .NET for that matter) without Microsoft's Visual Studio. Visual Studio is not free. The latest version is Visual Studio 2008 and it can cost, depending on where purchased, $150 and up. Without question, this tool greatly simplifies mobile development for the .NET Compact Framework and has a low learning curve for those already familiar with .NET and C#/VB development.
BREW's SDK is free and can be obtained by Qualcomm. However, developers also need an IDE. If writing BREW with C++, this means having a copy of Visual Studio 6.0, Visual Studio 2003 .NET, or Visual Studio 2005. Again, don't forget the cost to be authenticated and have your application tested before deployment. This can be a significant hit to total cost of development.
Through its SDKs and IDEs, Java ME environments offer a host of generic emulators for a number of devices. The Sun IDEs provide generic emulators that have "skins" that give the device emulator the appearance of a type of device with certain buttons, screen size, color depth, fonts, device controls, etc. Additionally, device vendors (Nokia, Motorola, etc.) provide SDKs that often offer more precise emulation for a particular device or set of devices. Some are able to be integrated with IDEs while others are stand alone.
The generic emulators don't test vendor specific APIs. Additionally, as these emulators are generic in nature, they do not always accurately reflect specific device issues and capabilities. Testing on the actual target devices is always recommended, especially when it comes to Java ME applications.
The Device Emulator 2.0 is part of the Windows Mobile 6 SDK. This emulator does a great job of representing Windows OS devices and can be considered one of the strengths of developing mobile applications to the .NET platform. This emulator provides fake GPS, low battery emulation, and even goes to some length to provide an emulator that tests the behavior of your application with cellular communications state changes (incoming call, hang up, busy signal, and so on). This emulator is a true Advanced RISC Machine (ARM) emulator, which means the emulator runs the same code as real devices.
BREW's emulator comes with the BREW SDK. However, it only runs on Windows. The testing and debugging of BREW applications is not easy and requires a lot of outside assistance. First, the BREW Emulator (called a Simulator) does not truly emulate the handset's hardware. Instead, BREW applications are compiled to native code and linked with an x86-compatible BREW runtime library. "Simulation" hides issues related to the actual hardware. In order to avoid these issues, developers should test their applications on real BREW handsets. For this, an application must first be compiled and linked into ARM binary form to run in BREW handset. The compiler/linker is available from Qualcomm. The application must then be digitally signed. Again, another tool from Qualcomm is required. Finally, the application can be uploaded to a BREW handset for testing via another tool (and USB or serial cable) called the AppLoader that is available from, you guessed it, Qualcomm. After the application has tested out, it can then be submitted to Qualcomm for its "TRUE BREW" testing. By the way, once an application has been tested and ready for deployment, the operator that owns the relationship with the handset customer must be convinced to offer your application. They may choose to do more testing of your application before offering it to the customer.
Device Feature Access
Java ME's access to a device's fundamental capabilities (like camera for instance) typically requires them to be included in the configuration, profile, and/or optional API for that device. This varies greatly according to platform. Only one of the configurations (CDC) allows native interface access (JNI), so accessing the device's feature even outside of Java may not be possible.
The .NET Compact Framework is written to the Windows Mobile OS, and so it has access to the same device capabilities as the OS. Which means the .NET Compact Framework application has access to just about everything and the device has and there is usually a convenient API to access it.
BREW allows direct access to the features of the device like the screen buffer, which is important for graphics intensive applications like games. At the discretion of the handset provider, BREW extension modules can add access to non-standard device functions.
Java ME runs on a virtual machine and its performance can be an issue especially on limited power/processing mobile devices. Like the Java virtual machine, the .NET Compact Framework requires applications to ride atop a runtime environment so performance of .NET apps is considered average by most accounts.
BREW applications, on the other hand, typically have very good performance. This is because the BREW applications run closer to the hardware layer than Java ME or .NET Compact Framework applications.