In 1997 I started my first Windows CE project in Java. Java was the big new thing at the time, and MS had promised a virtual machine with Windows CE 2.0 when it was released. Well, when we got our first CE 2.0 device in early 98 (actually when we upgraded our 1.0 device) there was no indication of Java support. I searched all over MS, and found only the original document stating that CE 2.0 would support it. That was right around the time of Sun's lawsuit against MS. So I had to rewrite everything in C++. Since then I have vowed that I will only go with what is tried and true, and is the lowest common denominator (assembly not being a common denominator among device models). I wouldn't touch C# with a 100 foot pole for the same reason (not being tried and true). I don't think MS has discovered that software is written for operating systems besides Windows XP. Heck, I can't even use C# with MS's other products (Windows CE), so I wouldn't begin to bother wasting my time learning the first thing about C#? Besides, the thought of the whole .NET thing sends shivers down my spine.<br><br>Other reasons why not to use Java with portable devices:<br><br>* The JVM is large (several megs), portable devices have little storage, so unless Java is in ROM you will waste a HUGE amount of space with the VM.<br><br>* Portable devices are relatively slow (compared to their desktop counterparts). The JVM adds in a great deal of overhead. Most programmers can't afford to waste precious processing power, especially with palms, cell phones, etc. Same thing with RAM. <br><br>* Very, very few mobile applications are daemons / services (ie, they have a GUI). The display metrics and depths vary tremendously between devices. One of the greatest areas of work a programmer faces porting a GUI-intensive app is how to fit the GUI into the display. Java provides automatic control layout, but that doesn't come close to being able to adapt to such varied displays, and usually a programmer needs more explicit control over layout in the first place. This problem is amplified with devices that have terribly crippled displays, like palms and cell-phones. Many times an app will have to have its GUI reinvented and implemented in a totally different way to fit the display (ie, breaking up a single dialog into tabbed pages, using different types of controls to display information differently, etc). No programming language / library can save a programmer that type of work.<br><br>* As has already been said, the consistency between VMs is poor. Parts of my app worked perfectly under MS's VM but not Sun's and vice versa. Even simple examples included in the JDK exhibited such inconsistencies. That was even running on the exact same hardware. I can't imagine how poorly apps would look / behave / run on completely different hardware.<br><br>* To my knowledge, the promised CPU whose instruction set is that of Java has never been produced. The Java-enabled toaster falls in the same mythical category as Bluetooth actually working and being "cheap". What a laugh. A CF Bluetooth card costs $200+, and probably can't communicate with 80%+ of the other Bluetooth hardware.<br><br>* My personal "code of programming" is that a piece of software is written once, and executed millions of times. Time spent writing optimized, low-level, efficient code is time saved millions of times over in its execution. Long after you have written you code and gone on to other things people will still be using your software, and paying the price you took in taking shortcuts or using inferior programming languages. That is why I initially shun languages whose purpose it is to make programming simpler, or make it more accessible to non-programmers, or require less work for a program to run on other platforms. I would rather create software that runs very well on a few platforms than software that runs mediocre on many.<br><br>* Most importantly, Quake was not written in Java.<br><br>That pretty much sums it up in 3,234 characters or less.
<br><br>Dan East