Michael Yuan wrote several articles on this:
http://www.javaworld.com/javaworld/jw-02-2003/jw-0221-wireless.html?
http://www.javaworld.com/javaworld/jw-05-2003/jw-0516-wireless.html?
To begin, I was product manager for the .NET Compact Framework 1.0, so
understand that my opinions are biased
I'll add several points:
1. It looks like your paper asks when the .NET Compact Framework was
released. The answer is March 19th, 2003 at Microsoft's Mobile Developer
Conference.
2. You kind of lump all of the J2ME technologies into a single bucket. In
reality, CDC and CLDC are very different technologies and don't even have
bytecode compatibility (they use different compilers, class libraries, and
virtual machines). Referring to the CLDC stack as being a trimmed down
version of J2SE is misleading because it really doesn't have anything in
common besides the java language syntax. If your paper is talking about the
"successful" version of J2ME, you should limit it to the CLDC 1.0/MIDP 1.0
stack, which has been the only version adopted by anyone so far.
3. You state that one of the goals of this paper is about deciding which
programming "language" a success. I think you may be trying to ask which
programming "platform" will be a success. One of the key things about .NET
in development is that developers aren't limited to a single syntax. Today
it's VB and C# (and C++ if you go native), but more languages can be added
if the developer demand is there. Either way, I think both platforms will be
successful in their own places. The real question is which places will have
a greater impact on the mobile industry at large.
4. You state that C# is the main programming language of .NET. This is not
true, mostly because the .NET Framework is language agnostic. In fact, VB is
more widely used on both the desktop and device versions. This is largely
due to the 6+ million Visual Basic developers worldwide. Most developers
I've met who have come to the .NET Compact Framework from J2ME use C#
because it is more familiar to Java developers.
5. For a more detailed comparison of features between the two, there is a
review at builder.com at
http://builder.com.com/5100-6374-1049886.html.
6. Manufacturer-specific device extensions are not a long-term benefit in
J2ME. After all, if J2ME's goal is WORA, those features can't be used in
multi-device environments. For example, you won't have Nokia's non-standard
media specifics on a Motorola phone. The answer to this was to create new
JSRs that would standardize a new set of features (such as Siemen's mobile
messaging or Nokia's mobile media). Unfortunately, these take about two
years to get through the whole process, upon which you have to add
development and compatibility testing. After that, you can go through
deployment testing and hopefully have a device out with the new features
within 3 years. The initial JSR review ballot for MIDP 2.0, which adds some
critical things developers use for building games, was proposed on April 10,
2001. I've only started seeing devices that support it in the past few
months.
7. You say that you must use the Visual Studio IDE to compile .NET Compact
Framework applications. That isn't true, and it's certainly not a benefit
that Java doesn't have good IDE support for J2ME yet. The lack of good IDE
support is primarily due to the fact that the MIDP platform is very weak,
resulting in a considerably amount of effort to build tools that do anything
more than notepad could, such as for UI layout.
8. You're right about J2ME emulators not emulating hardware properly. That's
because they're not "emulators", they're "simulators". The emulator that
comes with the .NET Compact Framework, on the other hand, is a full-blown
x86 virtual machine, providing full fidelity support for the OS and apps
running. When the CE emulator runs, it loads a full CE OS image (which could
be Pocket PC, Smartphone, or custom build) and treats it as though it was a
completely separate machine.
9. You say that "some" of the MSDN library has been put online. Actually, it
is all online and is kept up-to-date. New articles and samples are
refgularly posted.
10. "Windows Mobile" is the new branding for "Pocket PC" and "Smartphone" as
of 2003. That means that devices released before 2003 are called Pocket PC,
Smartphone, Pocket PC Phone Edition, etc, and devices released after are
"Windows Mobile for X". This is just a clarification.
11. Regarding performance, MIDP apps are completely interpretted. .NET
Compact Framework apps are JIT-compiled, meaning that the first invoke takes
the compilation hit for moving IL to native code, but future calls to the
same code will use cached native code. Cached code is not held beyond the
lifetime of the app, so the process begins again on next invocation.
12. The "economic" section make a lot of assumptions that may not be
correct. For example, Java may be more mature than C#, but VB is more mature
than Java. VB's evolution has gone from its 1991 incarnation to its current
state. The cost decision is also assuming that a company doesn't already
have tools. In most .NET Compact Framework cases, a company already has an
MSDN subscription and realizes that they can build mobile apps with tools
they already own.
13. Device cost has many different considerations. If you're deploying to a
PDA, Pocket PCs give you the best flexibility because you can buy different
types of Pocket PCs from different vendors (there are over 35) with
different types of functionality for different purposes, such as some with
bluetooth and some with WiFI, others with GPRS. All of those devices can use
the same app without development changes. I'm not aware of companies that
are willing to put development effort into building apps for devices they
don't own (or put company info on them). There are Pocket PCs below $200,
even before volume discounts.
14. Regarding application provisioning, you make a huge assumption about how
games get deployed to devices. You seem to be familiar with a specific
vending system, but you should be aware that these systems aren't just
free--they require a lot of custom development. If you get a chance to talk
to a major game warehouse, ask them how many different devices they'll
support. I spoke with a VP from one of the mobile gaming warehouses in the
UK and he told me that they won't support more than two devices if the app
is J2ME becuase the support costs due to app imcompatibilities (such as
usability) are too high, even though they're just the warehouse.
15. Your sample application is very simple, which doesn't give good insight
into the world of J2ME. Why don't you write something a little more complex,
such as an app that gets your local coordinates from a GPS device and sends
them to a mapping Web service, such as MapPoint, to get directions to the
nearest Starbucks? The fact is that you wouldn't be able to write that
because of J2ME's weaknesses.
- You'd have to use a real device, so MIDP 1.0 would probably be the
choice
- You wouldn't easily be able to access the GPS device, unless the vendor
provided J2ME libraries
- MIDP 1.0 doesn't support floating point values, so your coordinates
would be very innaccurate
- Calling the Web service would be a ton of work because no J2ME devices
have good support for Web services, causing you to have to roll your own
stack
- Displaying the results would be a challenge, giving the fact that MIDP
doesn't really have any good UI support for tables or grids
16. Additional things you should consider:
- Local and remote database access
- Reading or writing data to a file (many people are surprised at how
MIDP can't do that)
- Reusing classes in binary form between the desktop, server, and device
- User interface controls, such as tab pages and datagirds
Hope this helps.
